[BUG] Receiving session is interrupted when a cross-session message arrives, and afterwards has no knowledge of the message
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?
[BUG] Receiving session is interrupted when a cross-session message arrives, and afterwards has no knowledge of the message
Version: 2.1.133 (Claude Code desktop, Windows 11 Pro 26200)
Regression: yes — worked correctly on the previous version, one day earlier.
What happens: When session B receives a message from session A (via mcp__ccd_session_mgmt__send_message), session B stops immediately mid-turn. When I then ask session B a new question, it has no knowledge of the message that was delivered — the content is not in its context.
Expected: the message is delivered into the receiving session's context and the session continues, or at minimum the message is available on the next turn.
Impact: cross-session coordination is unusable. The sending session believes the hand-off succeeded; the receiving session never saw it. Silent loss, no error on either side.
Frequency: roughly five times in one morning, across different session pairs.
Note: related but distinct from #78706 (approval friction on the same feature) and #35741 (random interrupts without messages, closed as duplicate).
What Should Happen?
Expected: the message is delivered into the receiving session's context and the session continues, or at minimum the message is available on the next turn.
Error Messages/Logs
Steps to Reproduce
- Let a session perform a task
- In the mean time, start another session and let it send a message to the first session
- The first session reveives the message (according to the GUI), but stops processing and is unaware of the message.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.133 (Claude Code desktop, Windows 11 Pro 26200)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
possible dupe of #86012 although I haven't seen the "interrupted" framing before, and the other similar reports cite claude code version 2.1.227
I believe I am experiencing the same underlying issue, but with a different manifestation on Claude Code 2.1.228.
Reproduction
I have two independent Claude Code sessions, A and B.
SendMessageto send a simple message to B:PRUEBA 123 — responde únicamente OKMessage sent to session ...Escstops the stuck state and returns B to the normal prompt.holamanually in B, and B immediately responds normally.Observed behavior
The message is successfully delivered and displayed in B, but B becomes stuck while processing the incoming cross-session message.
After pressing
Esc, the session is fully functional again.The reproducible sequence is:
SendMessage → message appears in B → B becomes stuck → Esc → B recovers → manual prompt works normallyEnvironment
Claude Code 2.1.228
This is using the cross-session messaging functionality (
SendMessage/ListAgents).This appears to be related to the issue reported here, but in my case the receiving session remains in the active animation rather than immediately stopping.
I can reproduce this issue on Claude Code 2.1.228.
My reproduction is very similar to the behavior described here:
SendMessage.Escstops the stuck query.holamanually to B produces an immediate normal response.So the sequence is:
SendMessage → message appears in B → no output → stuck indefinitely → Esc → session recovers → manual prompt worksThe important detail is that the receiving session is not generally frozen. After
Esc, it works normally.Claude Code version: 2.1.228
This also suggests that the issue is still present in 2.1.228, although the exact manifestation may differ from the original report.
Silent loss with no error on either side — #86298 documents the same failure chain with root-cause analysis (Windows desktop, regression at app 1.28929.0 / bundled CLI 2.1.227, still present on app 1.30096.1.0 / CLI 2.1.229): the desktop bridge sends the message with a class-less
origin:{kind:'peer'}, the recipient CLI/SDK's cross-session consent gate holds it for an approval no desktop surface offers, anddialogExpiry(~5 min) then drops it — while the sender keeps a success receipt. A memory-dump repro in that thread shows the payload reaching the recipient CLI process but never its transcript. SettingcrossSessionInbound: "accept"in user settings does not unblock it (tested on running, cold-started, and post-restart fresh sessions).