What claude -p Trusts

When you run an AI coding agent with a human at the keyboard, a trust prompt gates the first run in an unfamiliar repo. When you wire the same agent into CI or an SDK with claude -p, that prompt is gone. Anthropic documents it plainly:

Trust verification is disabled when running non-interactively with the -p flag.

So an operator piping untrusted repositories through a headless agent needs a precise model of what a cloned repo can and cannot influence. I reported two behaviors in this area to Anthropic. Both came back informative. Both rulings are correct. The part worth writing down is why, because the reasoning is the actual security content.

A repo you clone can carry three things the agent reads: a CLAUDE.md, a .claude/settings.json with permission rules and hooks, and ordinary build files. Under an interactive session the trust dialog gates the capability-granting ones. Under -p there is no dialog. So what happens to each? Select a surface:

The two that matter

Read the ledger top to bottom and a pattern falls out. The surfaces split cleanly into layers.

Allow rules are gated, and that gate holds. The behavior I reported was allow-rule injection through project settings: a cloned repo adding its own allow rules and having them take effect under -p. The current build treats an allow rule as a capability grant and refuses to honor one from an untrusted workspace without the trust dialog, so under -p an injected rule is read and ignored. Whether that gate was always there or tightened since, the documented behavior today closes the path a malicious repo would reach for.

Deny rules restrict, so they run without trust, but they were never a hard wall. Anthropic says so on the permissions page: argument-scoped Bash rules are “fragile,” and they walk through the ways one is bypassed, from protocol swaps to redirects to variables. Process wrappers are a member of that same family. The permission engine strips a fixed set of wrappers before matching, and a wrapper outside that set is matched literally, so a rule written against a bare command name does not see the wrapped form. A deny rule cuts prompt fatigue and expresses a default, and a determined caller can work around it.

Why “informative” was the right call

Line those two up and the vendor’s rulings stop looking like dismissals and start looking like a deliberate choice of where the boundary sits. The design puts the security boundary at OS-level isolation and treats the permission list as guardrails: intent, defaults, and prompt-reduction. The docs are explicit that permissions and sandboxing are complementary layers, and that only the sandbox enforces at the OS level. Under that model, a project allow rule that fails to grant capability is working as intended, and a deny rule that a wrapper slips past is a guardrail behaving like a guardrail. The permission list was never the wall.

Closing both informative is the vendor being exact about where the line sits. Reading them as bugs means modeling the guardrail as the boundary, which is the operator’s error to avoid.

The gap that is still real

The model is coherent. The field deployment is where it bites. Operators do wire claude -p into CI runners and SDK integrations that process repositories of mixed provenance, and a good number of them read the absence of a trust prompt, or the presence of a deny list, as a containment guarantee they do not have. Nothing in a headless run stops an untrusted repo from trying things; what stops it from succeeding is the layer underneath.

So the operational rule for running a headless agent over code you do not control is short. Do not lean on permission rules for isolation. Put the run inside the OS sandbox with /sandbox, a dev container, or a VM, all of which Anthropic recommends for exactly this. Permission rules express what you want to happen. The sandbox decides what can.

The security work in agentic tooling is naming the boundary correctly, then building on the layer that enforces it. The trust dialog going quiet under -p is documented behavior. The value is in knowing what that does, and does not, change.