Claude Code Non Interactive — Claude Code Guide

Non-interactive mode is a bounded step

Non-interactive mode is useful for a single invocation from a shell script, local automation, or CI. Instead of a long exploratory session, define an explicit input, one narrow goal, and an output that can be saved and checked.

This mode fits a summary, log classification, release-note draft, or short diff analysis. It does not make Claude an unconditional approver: merge, release, and production deployment remain human and policy decisions.

claude --help

# Example: pass a narrow diff and save the result
claude -p "Write a short code-review summary" \
  --allowed-tools "Bash(git diff:*)" \
  > tmp/summary.md

Input and output contract

Structured output helps downstream processing, but valid JSON does not make a conclusion correct automatically. Compare it with the original diff or log.

Narrow delegation instead of full access

• Do not pass the whole repository when a diff or log is enough.
• Do not grant broad editing to a scripted run without a specific need.
• Do not put secrets in prompts, stdin, or saved artifacts.
• Do not permit commits, pushes, or destructive commands in the first version.

1. Name the exact file or command that is the input.
2. Describe what Claude must return and what it must not do.
3. Grant only the minimum tools and permissions.
4. Save the result in a temporary or dedicated evidence file.
5. Perform human review before any external action.

Example: analyze a build log

Name the format and forbid editing in the prompt. If a pipeline needs machine parsing, add JSON-schema validation and treat invalid output as a failure rather than an empty success.

cat build.log | claude -p \
  "Return JSON: category, cause, evidence, check, next_action" \
  > tmp/failure.json

# A script or person checks the file next,
# not an automatic merge step.

When to use an interactive session