Cross-session `send_message` has no working return path — sender's `local_<uuid>` id is unreachable from the `ListAgents`/`SendMessage` namespace

Correction: the original report's headline claim is wrong

I filed this saying cross-session send_message has no working return path. That is not correct, and I want to fix it rather than leave it standing.

A recipient can reply. It just cannot reply with the tool the prompt tells it to use.

What was actually tested

Sender session A → recipient session B, asking B to (1) call mcp__ccd_session_mgmt__list_sessions and check whether the sender's local_<uuid> appears, and (2) reply to that id with mcp__ccd_session_mgmt__send_message.

Result — B reported back:

Yes — list_sessions returned a session whose sessionId exactly equals local_bdc9326a-…. It was the first entry in the list.

and the send succeeded:

Message queued for session local_bdc9326a-… ("Issue #86012 reproduction test");
it will be processed after the in-flight turn finishes if that session stays healthy.

The ACK arrived end-to-end in the sender's session 139 s later (the sender was mid-turn; see the deferred-hold note below).

So list_sessions exposes the sender, and mcp__ccd_session_mgmt__send_message is keyed on exactly the local_<uuid> namespace the envelope's from= carries. The return path exists and works.

The actual defect

The injected envelope instructs the recipient to reply via SendMessage using the from= attribute. SendMessage resolves a different namespace — peers named <cwd-basename>-<hex> (scott-e5, scott-cd) over uds:\.\pipe\cc-msg-…. A local_<uuid> matches no scheme there and falls through to name resolution, which can never match. Hence, every time:

No agent named 'local_bdc9326a-…' is reachable

So the bug is a wrong reply instruction for Desktop-injected messages, not a missing capability. Recipients that follow the instruction fail; recipients that reach for the CCD tool succeed.

(The parser-level explanation above is from reading the bundled CLI and I have not verified it byte-for-byte. The behavioural result — SendMessage fails, mcp__ccd_session_mgmt__send_message succeeds — is directly observed and reproducible.)

Correction to the original evidence

I reported 4 of 10 recipients hitting this. That understates it: the other 6 never attempted a reply at all. Failure appears deterministic for any recipient that tries a bare local_ address via SendMessage. If anyone observes a non-deterministic result here, that would falsify the explanation above and point at something stateful instead.

Suggested fix

Have Desktop emit an address the CLI can resolve — e.g. from="uds:<messagingSocketPath>", or a second attribute carrying cliSessionId — so the existing socket lookup can route the reply. Alternatively, make the reply instruction name mcp__ccd_session_mgmt__send_message when the message arrived over the Desktop transport.

Two adjacent nits found while testing, both filed/notable separately:

• The envelope emits name="…" while the CLI parser matches from-name="…", so the sender renders as a raw id rather than its title.
• The body is HTML-escaped and stamped encoded="1", but never decoded (filed separately).

Environment: Claude Code 2.1.237 · Claude Desktop 1.34493.1 (MSIX) · Windows Server 2025 (10.0.26100)

The return path exists — the reply instruction just names the wrong tool

I filed this as "cross-session send_message has no working return path". That framing is wrong, and I can now show it with a positive and a negative control from a single trial.

Environment: Windows 11 Pro 26200 (VMware VM) · Claude Desktop 1.34493.1 (MSIX/Store) · engine 2.1.237.

The test

I asked a recipient session to attempt the reply four ways and report the literal return strings.

Step 1 — can the recipient even see me? mcp__ccd_session_mgmt__list_sessions returned the sender's id exactly:

local_132844a6-8f21-4671-b7a8-4d38a8576bbe   (title "Test Runner", isRunning true)

Step 2 — reply via the CCD tool. mcp__ccd_session_mgmt__send_message with session_id set to that id:

Message queued for session local_132844a6-… ("Test Runner"); it will be
processed after the in-flight turn finishes if that session stays healthy.

The ACK arrived in my session. The return path works.

Step 3 — reply the way the tooling tells you to. SendMessage with to set to the same id:

{"success":false,"message":"No agent named 'local_132844a6-8f21-4671-b7a8-4d38a8576bbe' is reachable.\nUse ListAgents to see everyone you can message."}

Step 4 — what ListAgents actually advertises:

wshal-4a [b510b7]  ·  interactive  ·  started 6m ago
wshal-b6 [486503]  ·  interactive  ·  started 56m ago

Why step 3 fails deterministically

SendMessage's address parser has no local: scheme. uds:, bridge:, did:, a leading /, and \\.\pipe\ all match; everything else falls through to scheme:"other" and then to name resolution. Peer names are the cwd basename plus a random hex byte (wshal-4a, wshal-b6), so a local_<uuid> can never match one.

The two address spaces are disjoint by construction, and ListAgents never surfaces a local_ id.

Meanwhile the SendMessage description and the coordinator prompt both say, unconditionally: "To reply to an incoming message, copy its from attribute as your to." That is correct for CLI-native peers. For a Desktop-injected message the from is always a local_ id — so following the documentation produces the step-3 failure every time.

That also explains why recipients appear to "fail to reply" at varying rates: it depends entirely on which tool the recipient happens to reach for. The capability was never missing.

Suggested retitle

Desktop-injected cross-session messages tell recipients to reply with a tool that cannot resolve their address

Suggested fixes, cheapest first

1. Textual. Make the reply instruction conditional: for a message whose from is a local_ id, name mcp__ccd_session_mgmt__send_message and session_id instead of SendMessage/to.
2. Structural. Have Desktop emit the routable address in a second attribute. from-session= is already in the CLI's envelope regex and currently unused, so the existing session-id → socket lookup could route the reply with no new grammar.

Two envelope bugs found alongside this

The envelope Desktop emits:

<cross-session-message from="local_132844a6-…" name="Test Runner" encoded="1">

The CLI's parser captures, in this strict order:

from=  from-session=  hop-chain=  from-name=  from-mode=

• name= vs from-name=. Desktop emits name=; the parser captures from-name=. The sender's display name is therefore dropped. (Confirmed on the wire, not just from the bundle — from-name= appears 0 times in delivered transcripts.)
• encoded="1" is emitted and never honoured. encoded= has 0 occurrences in claude.exe, and there is no decode step — see the separate issue for the resulting entity corruption. Note the strict regex above has no slot for name or encoded either; delivery still works because inbound goes through the looser ^<cross-session-message\b[^>]*> stripper rather than the strict parser.

Cross-linking #87034 (the parser) as load-bearing prior art.

Still relevant. mcp__ccd_session_mgmt__send_message delivers reliably, but the recipient sees the sender as a local_<uuid> session id, while ListAgents and SendMessage enumerate peers in an entirely different namespace. The sender id resolves in neither, so the recipient cannot answer.

Keeping the separation from #86012 clear: there the recipient wedges and never responds. Here the recipient responds normally and simply has nowhere to send the response.

The practical effect is that cross-session messaging is one-way only. Fan-out works, and nothing can report back, which rules out any pattern that needs a result rather than a notification.