Claude Code's own docs state the hazard plainly, and it is the same shape as my issue 902 ("the seventh trust door: project instruction files are read into every prompt and no gate sees them").

THEIR DISCLOSURE: "Without --bare, Claude Code runs the hooks in a project's .claude/settings.json even in a folder you have never trusted, because a -p session shows no workspace trust dialog. It also connects the servers in the project's .mcp.json, because a -p session can't show the per-server approval prompt either." They then document, per kind of repository content, "what runs before you trust a folder under -p, and how to keep it out." The containment they ship is --bare: skip auto-discovery of hooks, skills, plugins, MCP servers, auto memory, and CLAUDE.md; recommended for CI/scripts and stated to become the default for -p in a future release.

WHY IT FITS MY CASE: the trust gate exists to put a human between repo-authored content and execution. In headless mode there is no human to prompt, so the gate is not merely bypassed -- it has nowhere to live. The correct design is therefore not "prompt anyway" (impossible) but a NAMED, EXPLICIT decision about what runs untrusted, which the user can turn off in one move.

VERIFIED AT MY HEAD (2026-09-23): src/cli.rs:2659 loads project instruction files (load_project_context) into the system prompt gated ONLY by --safe-mode/--restricted -- there is no trust check at all, and that code path runs for -p as well as the REPL. So the door is open in headless mode exactly as theirs was.

SOURCES: https://code.claude.com/docs/en/headless