Repository navigation
Cross-session send_message delivers to the target session's queue but never triggers a responding turn (regression in desktop 1.28929.0 / CC runtime 2.1.227, still broken in 2.1.231) #86385
Description
Activity
Solid writeup \u2014 and the fact it survives the runtime bump to 2.1.231 points at the desktop shell rather than CC itself. Worth testing a rollback of the MSIX to 1.26832.0, the last known-good, and disabling auto-update while you're there; that at least unblocks agent-to-agent delivery until a fix lands. The held-steer evidence you captured should make this easy for them to reproduce.
Still broken on desktop app 1.30096.1.0 + runtime 2.1.229 — and the recipient hard-freezes
Confirming this on the newest desktop build, which extends the regression window past 1.28929.0. Adding one detail that I don't see stated elsewhere in the thread and that changes the severity: the recipient does not just fail to respond — it wedges, and stays wedged until manually stopped.
Environment
OS | Windows 11 Home, 10.0.26200 -- | -- Desktop app | 1.30096.1.0 (MSIX, auto-updated from 1.28929.0.0 on 2026-08-13) Bundled runtime | 2.1.229 (both sender and recipient) Transport | mcp__ccd_session_mgmt__send_message, two local desktop sessions, same project directoryBoth sessions were created fresh after the app update, so this is not a stale-session artifact.
Repro
Two idle sessions in one project. Sender asked the recipient to reply with a single line confirming receipt — no tools, no file access, nothing but a text reply.
- Sender receives
Message sent to session …. - Recipient's
lastActivityAtadvances, and the message lands on the recipient side — it renders in its window and is present in its transcript. Delivery itself is real; the break is entirely on the receiving end. - The recipient's working indicator starts spinning and never stops. No thinking trace, no output, no error, no timeout.
- It stays in that state indefinitely. The only way out is stopping the turn manually, which returns the session to a normal prompt.
- Typing the same text directly into the recipient's input box immediately afterwards works first try.
Why this is worse than a silent drop
The thread so far reads as "messages don't arrive" or "the recipient stays quiet." In practice each send costs a manual intervention and puts the recipient's in-flight state at risk:
- Messaging cannot be used unattended at all. A send to an idle session parks it until a human notices and intervenes.
- The success receipt makes it invisible from the sending side, so a coordinating session believes the handoff landed and keeps going.
- It retroactively explains earlier confusion in multi-session workflows: sessions that appeared to ignore a relay were most likely hung on it the whole time — not declining the work, not missing it.
We run a multi-session setup where roles hand findings to each other, and we've had to disable cross-session messaging entirely and route every handoff through a shared markdown file. That workaround is stable, but it means the feature is currently unusable for its main purpose here.
- Sender receives
This looks like the "wedge" mechanism documented in the follow-up comment on #86298, with app-log evidence: an injected cross-session message that the CLI holds (consent gate) gets drained into the CLI at a turn boundary and is never "echoed" back as a user turn; the app then logs
isRunning held by unechoed input at result … pendingEchoUuids: […]and treats the session as busy indefinitely — phantom turn, watchdog kills, and the user's own typed prompts queue/stall behind a turn that never ends until apriority=nextsend (typing another message force-flushes) or a restart reclaims it. Matches the queue-delivery-without-responding-turn you describe.Retested on 2.1.233 + the new
crossSessionInboundsetting — still broken; the setting is not the fixRetest after today's desktop update (Windows 10, MSIX app, runtime 2.1.233 on both ends, full app restart, two freshly created sessions):
- Set
"crossSessionInbound": "accept"in user settings.json before launching either session (the new /config row from 2.1.232 didn't render in our build — appears feature-gated — but the setting itself is honored from settings.json). send_messagereturns success and the message lands in the receiver's transcript as a user turn within seconds. Delivery is fine.- The receiver flips to "running" immediately and never produces a turn: no thinking trace, no output, for 6+ minutes, after which the UI eventually surfaces a "Claude Code stopped responding — Try sending your message again" error card. Identical wedge with old (pre-update) sessions and with brand-new ones.
- The wedge is universal on our machine: a third session that received only a two-line summary via
send_messagewedged the same way, and only recovered when the user typed into it.
So even with the new inbound setting explicitly on "accept", the receiving side wedges. This closes off "configure accept" as a workaround; the break looks like it's in the receiver's turn-start path, matching the held/un-echoed-input mechanism described above. We remain on file-based handoffs as the only reliable channel.
- Set
Closing as a duplicate of #86237 — please follow and 👍 that issue instead so we can track it in one place. If you think this was closed in error, comment here and we'll reopen.
🤖 Generated with Claude Code
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
- locked as resolved and limited conversation to collaborators
on Sep 30, 2026
Environment
ccd_session_mgmtMCPsend_messagetool between local sessionsSummary
Since the 1.28929.0 update, a message sent from one local session to another with
send_messageis correctly enqueued into the target session (it appears in its transcript as a<cross-session-message>user turn), but the receiving agent never runs a turn over it. The queued message only surfaces when the user manually types anything into the receiving session — it then flushes into that turn together with the user's input.On 1.26832.0 the receiving session responded to cross-session messages automatically. This broke agent-to-agent report delivery workflows.
Steps to reproduce
ccd_session_mgmtsend_messagetargeting B.main.logshows either no query cycle at all, or a delivery cycle that runs and ends withhadFirstResponse=false(observed: 65s and 235s cycles with zero output, one killed by warm-lifecycle/MCP-reconfig housekeeping).Evidence from
%APPDATA%\Claude\logs\main.logResuming session <id>fires (wake works), thenLocalSessions.interrupt+healthy cycle … (235s, hadFirstResponse=false)— no output ever produced.(65s, hadFirstResponse=false).LocalSessions.sendMessage→ healthy cycle withhadFirstResponse=true, and the queued cross-session message is answered in the same turn.LocalSessions.sendMessage(user-typed input); cross-session sends never do after the update.What we ruled out
Sending message to session <target>) at 16:22:43; no query-start or model activity follows.main.logshows[LocalSessionManager] flushed held steers (1 steer(s)) for <target>(16:34:35), the model responded within seconds, and the cycle closed ashealthy cycle … (718s, hadFirstResponse=true)— i.e. one cycle had been open since delivery (16:22:43) with the message held the whole time. The regression appears to be that cross-session messages are classified as steers that are held indefinitely; nothing flushes them until a user-typed message arrives.send_message; no ACK was ever sent, and the agent showed no awareness of the message). The message is visible in the session's transcript UI, but the model's flushed turn behaves as if it only received the user's character. In earlier repros on 2.1.227 the flushed message was answered in the same turn, so this may be a second regression or an intermittent variant.Expected
The receiving session runs a responding turn over an incoming cross-session message automatically, as in 1.26832.0.