Feature request: trusted peer sessions — allow cross-session send_message without per-message approval

Status Open
Reported on v2.1.209
Maintainer reply None cached
Activity 0 comments · opened Jul 18, 2026

Problem

The Claude Code desktop app's session-management MCP tool (mcp__ccd_session_mgmt__send_message) requires explicit user confirmation on every cross-session message, even when mcp__ccd_session_mgmt is in permissions.allow. There is no setting, flag, or env var to relax this (verified against current docs).

For a single-user machine running a coordinator-session pattern — one session reviewing, unblocking, and relaying findings between ~10 concurrent local sessions — this means the human must click through an approval for every relay. One coordination sweep today cost ~10 approval clicks, and the human is reduced to a button-pressing proxy for messages they asked the coordinator to send.

What I tried

  • permissions.allow: ["mcp__ccd_session_mgmt"] (server-wide rule) — permission layer passes, app-layer confirmation still appears on every send.
  • Native SendMessage tool — cannot address independent desktop sessions (teammates/subagents only; verified empirically).
  • Agent teams — prompt-free, but only within a spawned hierarchy; cannot bridge already-running standalone sessions.

Request

An opt-in trust mechanism for same-user, same-machine session messaging. Possible shapes:

  • A setting like trustedPeerSessions: true (analogous to the existing isolatePeerMachines semantics, which implies same-machine peer messaging was considered) that suppresses per-message approval for local sessions owned by the same user;
  • or a per-session grant ("allow this session to message other sessions without asking"), so a designated coordinator can be trusted without trusting every session;
  • or a permission-rule extension, e.g. mcp__ccd_session_mgmt__send_message(to:local_*).

Security acknowledgment

I understand the confirmation exists as a prompt-injection firewall — without it, a compromised session could silently puppet others. An opt-in setting with clear provenance labeling on delivered messages (the existing "From {session}" attribution) and default-off behavior preserves that protection for everyone who doesn't explicitly choose the coordinator workflow. The per-session grant variant would keep the blast radius narrowest.

Environment

  • Claude Code desktop app 2.1.209, macOS (darwin 25.3)
  • Filed via Claude Code acting as the user's session coordinator, at the user's request

🤖 Generated with Claude Code

View original on GitHub ↗