[BUG] `claude -p` / `claude --print` has control-plane parity risks across hooks, permissions, skills, MCP, auth, and subagents

Parent tracking issue: https://github.com/anthropics/claude-code/issues/59105

Context note: This is a frontend/product-boundary parity issue, not a criticism
of any individual implementation. Since -p / --print behavior is already a
known pain point, and upcoming mid-June frontend-facing changes may depend on
predictable CLI/TUI parity, this should be evaluated as a user-facing parity
risk. The goal is to reduce verification time and avoid customer-facing
regressions with potential business impact.

Summary

There is a broad cluster of existing issues where claude -p or headless
execution behaves differently from interactive Claude Code. Our packet capture
shows a plausible shared substrate: -p is classified as sdk-cli and receives
a different request scaffold from TUI.

This ticket is a routing ticket for control-plane parity. The concern is not
only output formatting; it is whether frontend-facing print workflows run the
same product contract as manual TUI operation.

Local evidence

In Claude Code 2.1.141, compared to TUI main-thread traffic, claude -p sends:

• source=sdk
• User-Agent ... sdk-cli
• cc_entrypoint=sdk-cli
• SDK identity prompt
• beta header missing redact-thinking-2026-02-12
• different tool contract
• different default tool guidance

This means hooks, tools, permissions, skills, MCP, auth, and subagents may be
running under a different control-plane path.

Rediscovery track

Treat every print/headless control-plane report as a same-state capture problem
first. Keep Claude Code version, model, working directory, trust state, config,
prompt, and input format aligned, then compare print mode only against TUI
source=repl_main_thread.

Record the request source, User-Agent entrypoint segment, attribution
system block, identity system block, beta header set, tools[].name, user
and system block counts, and any hook/MCP/permission/skill logs for that same
invocation. When following the source, use topology: startup classification,
config/trust loading, hook lifecycle, permission selection, MCP/skill discovery,
tool filtering, request builder, HTTP client.

Related upstream issues

Security / permissions / hooks:

• #33343 - PreToolUse hooks and --allowedTools not enforced in headless -p
• #40506 - PreToolUse hooks do not fire in non-interactive mode
• #38651 - Stop hook causes empty result in print mode
• #48840 - request for --no-hooks in claude -p
• #47871 - claude -p from SessionEnd hook can recursively create child sessions

Skills:

• #36570 - claude -p does not trigger skills
• #44756 - skills silently fail in print mode with exit 0
• #32184 - skill auto-triggering recall is 0% in headless mode

MCP / plugins:

• #39271 - HTTP MCP bearer token regression in claude -p
• #50777 - claude -p hangs after completion because MCP servers are not cleaned up
• #51785 - MCP elicitation docs missing print and Agent SDK handling
• #50655 - plugin-manifest leak from claude -p in pre-commit hook

Auth / cost:

• #39453 - non-interactive -p cannot use existing Claude Pro login
• #51047 - claude --bare -p reports not logged in
• #46262 - claude -p gets 402 billing error through gateway
• #37686 - unintended API billing after claude -p recommendation
• #57096 - claude -p rejected for extra usage despite Max quota

Subagents / orchestration:

• #52917 - claude -p exits before background subagents complete
• #56540 - non-TTY -p hangs on parallel Task fan-out
• #56268 - claude -p silent-freeze from long-running orchestrator
• #55802 - many headless sdk-cli sessions launched on startup

Why this matters

Control-plane drift is serious for production users:

• --allowedTools and hooks are often treated as safety controls
• skills and MCP are often treated as capability controls
• auth and billing determine which account/product surface is used
• subagents and Task tools affect work decomposition and completion

If these differ between TUI and frontend-facing print workflows, then companies
cannot reliably audit, reproduce, or certify Claude Code behavior.

Expected

Claude Code should have a documented parity contract:

• which control-plane features are guaranteed to behave the same in TUI and

-p

• which features intentionally differ
• what happens when a TUI-only feature is requested in headless mode
• whether -p is a CLI output mode or an SDK/headless product mode

Silent divergence should be treated as a bug.

Suggested fix

1. Fix entrypoint classification so plain -p does not imply sdk-cli.
2. Add regression tests that compare request scaffold and control-plane behavior

between TUI and -p.

1. For any intentional differences, emit explicit warnings/errors and document

them.

1. Ensure security controls (--allowedTools, hooks) either work or fail closed

in headless mode.