Desktop: ccd_session_mgmt__send_message reports "Message sent" but never delivers

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?

In the desktop app, the MCP tool mcp__ccd_session_mgmt__send_message always
replies Message sent to session <id>, but the message never becomes a turn in
the target session, and no error surfaces anywhere.

Between 12 and 15 August 2026, 17 out of 17 sends reported success and none was
delivered. The last successful delivery was on 11 August, the day before the
bundled CLI moved from 2.1.222 to 2.1.227. Still broken on 2.1.229.

Nothing is written to the target session's transcript — no
<cross-session-message ...> record is ever created.

What Should Happen?

Either the message is delivered, or the tool reports an error. Reporting success
on a delivery that did not happen is the worst part: the sender has no way to
notice, and the content is lost without a trace. Today the only way to find out
is to read the target session's transcript by hand after every send.

Error Messages/Logs

Two distinct signatures in the desktop log.

Target session not attached — the app wakes it but never hands it the message;
the `Sending message to session` line never appears, and the woken session sits
idle:


Resuming session local_<B> in <project-dir>
Starting local session local_<B> in <project-dir>
Loaded <N> transcript messages for session local_<B>
        <- no "Sending message to session" line
[CCD CycleHealth] unhealthy cycle for local_<B> (hadFirstResponse=false)


Target session attached — the send starts, but the CLI never echoes it back:


Sending message to session local_<B>
[LocalSessionManager] drained 1 deferred send(s) for local_<B>
[LocalSessionManager] reaped 1 stale pendingEchoUuids for local_<B>
        - CLI dropped the isReplay echo

Steps to Reproduce

1. Open two desktop sessions, A and B.
2. From A, call mcp__ccd_session_mgmt__send_message targeting B.
3. The tool replies Message sent to session ....
4. In B the message never appears, and no <cross-session-message ...> record

is written to B's transcript.

Happens both when B is idle and when list_events reports B as (running).

Claude Model

_No response_

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.222

Claude Code Version

2.1.229 (Claude Desktop 1.30096.5.0, bundled CLI)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Why later releases do not seem to fix this: the cross-session improvements from
2.1.224 onward target the CLI's native peer channel, which requires each session
to register a messagingSocketPath in ~/.claude/sessions/<pid>.json.
Desktop-spawned sessions never join it — CLAUDE_CODE_MESSAGING_SOCKET and
messagingSocketPath appear zero times in the desktop app bundle, and no
desktop session's pid file carries that field. That leaves the desktop path as
the only channel between two desktop sessions, and it is the broken one.

If that path is considered superseded by SendMessage, having it report an
error instead of a success would already help a lot — or bringing desktop
sessions into the peer network.