A flag to make a `claude -p` run unreachable by peer-session messages

Summary

A headless claude -p run creates /tmp/cc-socks/<pid>.sock and appears in every other local session's agent list as a peer, even when every CLAUDE_CODE_* variable (including CLAUDE_CODE_MESSAGING_SOCKET) is scrubbed from its environment. Any other session on the machine can message it mid-run, and the run reacts. claude --help shows no flag that disables inbound messaging.

Why it matters

We use claude -p as an isolated "stranger" evaluator: a fresh container, a scrubbed environment, no colleagues, so the evaluation measures the product and not the room. On 2026-08-25 another session on the same host messaged the running evaluator about unrelated containers; the run investigated, replied through the socket, and its report then said the containers "were reported to me as leaked", which a first-time user with no colleagues cannot write. The evaluation was contaminated by a channel the harness had no way to close.

What we tried

Scrubbing the environment is not enough; the socket is created regardless. Removing discoverability (not listing the run as a peer) reduces accidental contact but does not prevent a deliberate send to a known socket path. Unlinking the socket from outside races the running process for its own file.

Ask

A first-class way to say "this run must not accept inbound messages", for example claude -p --no-peer-messages or CLAUDE_CODE_DISABLE_INBOUND_MESSAGING=1, honoured at startup so no socket is created (or the socket refuses inbound sends), and reflected in --help. A run started that way should also not appear in other sessions' agent lists.

Environment

Claude Code 2.1.245 on macOS 25.4 (Darwin), claude -p --output-format stream-json, drivers launched by a harness with the CLAUDE_CODE_* variables removed.