[BUG] Cross-session messaging has no account-level off switch — local-only controls can't contain sandboxed /auto or --dangerously-skip-permissions agents

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Cross-session messaging (added ~v2.1.224, on by default on macOS/Linux/WSL2) can only be
disabled through machine-local configuration — settings files, env vars, --settings.
There is no account-level setting. But the population this matters most for is unattended
/ looping agents running with --dangerously-skip-permissions inside sandboxed VMs, and
for that population local configuration is not a security boundary: the agent can edit it.
Cross-session messaging hands those agents a new path out of the sandbox — discovering and
messaging (i.e., prompt-injecting) the operator's other Claude sessions, including
interactive sessions outside the VM.

Environment

• Claude Code 2.1.226 (feature landed in 2.1.224 per changelog)
• Personal (non-Team/Enterprise) account — no admin console

The gap: every off switch is local, and none survives an adversarial local agent

1. User/project settings.json (crossSessionInbound: "refuse", permissions.deny

on SendMessage/ListAgents): settings are hot-reloaded — the settings docs state
edits apply to the running session, explicitly including permissions. A
bypass-permissions agent can rewrite these files mid-session, or relaunch itself with
--settings overrides.

1. managed-settings.json: documented as the only tier a session cannot override

in-process — but it's just a file. In a sandbox VM the agent account typically has
local admin (much dev tooling requires it), so it's writable there too.

1. Env vars (CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 etc.): per-process; an

agent can spawn children without them.

Nothing the account owner controls survives a compromised process inside the VM.

Threat scenario

1. Operator runs looping agents with --dangerously-skip-permissions in a VM *precisely

to contain them*. The agents ingest untrusted content (web pages, issues, third-party
code), so prompt injection must be assumed.

1. The VM necessarily carries the operator's OAuth credential — the agent can't run

without it. That credential links the sandbox to every other session on the account.

1. Same-machine: sessions of the same user are mutually discoverable by default

(ListAgents) and messageable (SendMessage).

1. Cross-machine: the Remote Control docs describe startup as "registers with the

Anthropic API and polls for work," with no documented interactive pairing approval on
the claude.ai side — so a sandboxed agent with the cached credential appears able to
self-enroll and reach sessions on the operator's other machines. (If there is an
undocumented human-approval gate here, documenting it would materially change this
threat model — please clarify.)

1. A delivered message is attacker-authored text injected into another session's context.

The hold-for-approval behavior around bypass-permissions sessions helps, but the
message body itself is the payload and the approval prompt is a social-engineering
surface.

Net effect: the isolation boundary the VM exists to provide is bypassed by an
account-carried channel that the account owner cannot switch off at the account.

References

• https://code.claude.com/docs/en/cross-session-messaging.md
• https://code.claude.com/docs/en/settings.md (hot-reload behavior)
• https://code.claude.com/docs/en/permissions.md (managed settings tier)
• https://code.claude.com/docs/en/remote-control.md (registration / requirements)

What Should Happen?

1. An account-level setting (claude.ai) that disables cross-session messaging for all

sessions authenticated to the account — enforced server-side for anything transiting
Anthropic (Remote Control path), and honored by clients for the local-socket path.

1. Secondary: credential/machine-scoped isolation — a way to mark a machine or credential

as "isolated" (never discoverable via ListAgents, cannot enroll in Remote Control),
intended exactly for sandbox/CI use.

1. Secondary: default crossSessionInbound: refuse and no discoverability for sessions

started with --dangerously-skip-permissions.

Error Messages/Logs

Steps to Reproduce

Try any way to keep a VMed agent from modifying it's own config in dangerously-skip-permissions / auto mode

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.223

Claude Code Version

2.1.224

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_