You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] [Windows/Desktop] Cross-session messages to idle sessions are silently lost after auto-update; wake attempts wedge the session #86029
We run a multi-session orchestration setup (one verifier session coordinating worker
sessions via the ccd_session_mgmt send_message tool). After today's auto-update,
cross-session message delivery became state-dependent and lossy:
Messages sent to an IDLE session are silently lost. The sender gets a success
response ("Message sent" / "Message queued"). The message sometimes even RENDERS
in the receiving session's transcript UI. But it is never persisted to the
receiver's session JSONL and the receiving model never processes it.
Verified by grepping the receiver's ~/.claude/projects/<project>/<session>.jsonl
for unique marker strings: 0 occurrences, while the sender-side record exists.
Messages sent while the receiver is ACTIVE (mid-turn) deliver normally at the
next turn boundary. We confirmed this repeatedly in the same session pair, same day.
Wake attempts wedge the session. A message that should wake an idle session
instead starts a turn that spins for ~10 minutes with no output and no JSONL
growth. The session shows a warning icon and only recovers when the user types
into its input box manually. User-typed input persists fine; cross-session
deliveries into the same session do not — so the failure is specific to the
background delivery path, not the transcript writer in general.
Two sessions in one project, A (sender) and B (receiver).
Let B go idle.
From A, send B a message containing a unique marker string via send_message.
Observe: A gets success; B's UI may render the message; B's JSONL never contains
the marker (grep), B's model never responds; B may enter a wedged turn (~10 min).
Repeat while B is mid-turn: the marker appears in B's JSONL and B processes it.
Impact
Multi-session workflows are effectively broken: an orchestrating session cannot wake
or task idle worker sessions. Rulings/instructions sent between sessions vanish
without any error, which cost us ~50 messages of coordination state today.
Workaround (for other affected users)
We replaced the message channel with a file-based bus: instructions are written to
files, each worker arms a background file-watcher loop whose completion notification
self-wakes the session, and reports are appended to shared files that the
orchestrator watches. This fully restores automation, which also suggests the
background-task notification path is healthy while the cross-session delivery path
is not.
Asks
Fix persistence of cross-session deliveries to idle sessions (flush before ack,
or fail loudly to the sender instead of returning success).
Fix the wedged wake turn (idle session receiving a message spins ~10 min).
Consider fsyncing session JSONL before/after auto-update to prevent transcript loss.
What Should Happen?
Title: [Windows/Desktop] Cross-session messages to idle sessions are silently lost after auto-update; wake attempts wedge the session
Environment
Windows 11 Pro (build 10.0.26200)
Claude Code Desktop app, MSIX install (package Claude_pzs8sxrjxfjjc)
Started immediately after a desktop app auto-update today (previous version unknown — no version history is kept on disk for MSIX installs)
We run a multi-session orchestration setup (one verifier session coordinating worker
sessions via the ccd_session_mgmt send_message tool). After today's auto-update,
cross-session message delivery became state-dependent and lossy:
Messages sent to an IDLE session are silently lost. The sender gets a success
response ("Message sent" / "Message queued"). The message sometimes even RENDERS
in the receiving session's transcript UI. But it is never persisted to the
receiver's session JSONL and the receiving model never processes it.
Verified by grepping the receiver's ~/.claude/projects/<project>/<session>.jsonl
for unique marker strings: 0 occurrences, while the sender-side record exists.
Messages sent while the receiver is ACTIVE (mid-turn) deliver normally at the
next turn boundary. We confirmed this repeatedly in the same session pair, same day.
Wake attempts wedge the session. A message that should wake an idle session
instead starts a turn that spins for ~10 minutes with no output and no JSONL
growth. The session shows a warning icon and only recovers when the user types
into its input box manually. User-typed input persists fine; cross-session
deliveries into the same session do not — so the failure is specific to the
background delivery path, not the transcript writer in general.
Two sessions in one project, A (sender) and B (receiver).
Let B go idle.
From A, send B a message containing a unique marker string via send_message.
Observe: A gets success; B's UI may render the message; B's JSONL never contains
the marker (grep), B's model never responds; B may enter a wedged turn (~10 min).
Repeat while B is mid-turn: the marker appears in B's JSONL and B processes it.
Impact
Multi-session workflows are effectively broken: an orchestrating session cannot wake
or task idle worker sessions. Rulings/instructions sent between sessions vanish
without any error, which cost us ~50 messages of coordination state today.
Workaround (for other affected users)
We replaced the message channel with a file-based bus: instructions are written to
files, each worker arms a background file-watcher loop whose completion notification
self-wakes the session, and reports are appended to shared files that the
orchestrator watches. This fully restores automation, which also suggests the
background-task notification path is healthy while the cross-session delivery path
is not.
Asks
Fix persistence of cross-session deliveries to idle sessions (flush before ack,
or fail loudly to the sender instead of returning success).
Fix the wedged wake turn (idle session receiving a message spins ~10 min).
Consider fsyncing session JSONL before/after auto-update to prevent transcript loss.
Error Messages/Logs
Steps to Reproduce
Title: [Windows/Desktop] Cross-session messages to idle sessions are silently lost after auto-update; wake attempts wedge the session
Environment
Windows 11 Pro (build 10.0.26200)
Claude Code Desktop app, MSIX install (package Claude_pzs8sxrjxfjjc)
Started immediately after a desktop app auto-update today (previous version unknown — no version history is kept on disk for MSIX installs)
We run a multi-session orchestration setup (one verifier session coordinating worker
sessions via the ccd_session_mgmt send_message tool). After today's auto-update,
cross-session message delivery became state-dependent and lossy:
Messages sent to an IDLE session are silently lost. The sender gets a success
response ("Message sent" / "Message queued"). The message sometimes even RENDERS
in the receiving session's transcript UI. But it is never persisted to the
receiver's session JSONL and the receiving model never processes it.
Verified by grepping the receiver's ~/.claude/projects/<project>/<session>.jsonl
for unique marker strings: 0 occurrences, while the sender-side record exists.
Messages sent while the receiver is ACTIVE (mid-turn) deliver normally at the
next turn boundary. We confirmed this repeatedly in the same session pair, same day.
Wake attempts wedge the session. A message that should wake an idle session
instead starts a turn that spins for ~10 minutes with no output and no JSONL
growth. The session shows a warning icon and only recovers when the user types
into its input box manually. User-typed input persists fine; cross-session
deliveries into the same session do not — so the failure is specific to the
background delivery path, not the transcript writer in general.
Two sessions in one project, A (sender) and B (receiver).
Let B go idle.
From A, send B a message containing a unique marker string via send_message.
Observe: A gets success; B's UI may render the message; B's JSONL never contains
the marker (grep), B's model never responds; B may enter a wedged turn (~10 min).
Repeat while B is mid-turn: the marker appears in B's JSONL and B processes it.
Impact
Multi-session workflows are effectively broken: an orchestrating session cannot wake
or task idle worker sessions. Rulings/instructions sent between sessions vanish
without any error, which cost us ~50 messages of coordination state today.
Workaround (for other affected users)
We replaced the message channel with a file-based bus: instructions are written to
files, each worker arms a background file-watcher loop whose completion notification
self-wakes the session, and reports are appended to shared files that the
orchestrator watches. This fully restores automation, which also suggests the
background-task notification path is healthy while the cross-session delivery path
is not.
Asks
Fix persistence of cross-session deliveries to idle sessions (flush before ack,
or fail loudly to the sender instead of returning success).
Fix the wedged wake turn (idle session receiving a message spins ~10 min).
Consider fsyncing session JSONL before/after auto-update to prevent transcript loss.
Preflight Checklist
What's Wrong?
Title: [Windows/Desktop] Cross-session messages to idle sessions are silently lost after auto-update; wake attempts wedge the session
Environment
Claude_pzs8sxrjxfjjc)Summary
We run a multi-session orchestration setup (one verifier session coordinating worker
sessions via the
ccd_session_mgmtsend_message tool). After today's auto-update,cross-session message delivery became state-dependent and lossy:
Messages sent to an IDLE session are silently lost. The sender gets a success
response ("Message sent" / "Message queued"). The message sometimes even RENDERS
in the receiving session's transcript UI. But it is never persisted to the
receiver's session JSONL and the receiving model never processes it.
Verified by grepping the receiver's
~/.claude/projects/<project>/<session>.jsonlfor unique marker strings: 0 occurrences, while the sender-side record exists.
Messages sent while the receiver is ACTIVE (mid-turn) deliver normally at the
next turn boundary. We confirmed this repeatedly in the same session pair, same day.
Wake attempts wedge the session. A message that should wake an idle session
instead starts a turn that spins for ~10 minutes with no output and no JSONL
growth. The session shows a warning icon and only recovers when the user types
into its input box manually. User-typed input persists fine; cross-session
deliveries into the same session do not — so the failure is specific to the
background delivery path, not the transcript writer in general.
Transcript truncation on restart. One receiving session's transcript dropped
from 5,916 to 5,866 messages (~50 lost) across an app restart. Notably, the model
had already acted on instructions contained in the now-vanished messages — i.e.
the content reached the model in memory but was never flushed to the JSONL, and
the restart discarded it. This matches the IndexedDB/JSONL desync described in [BUG] Windows: Claude Code Desktop app shows sessions in sidebar but all message content missing after auto-update — content not persisted to claude-code-sessions JSONL files #53717.
Repro
the marker (grep), B's model never responds; B may enter a wedged turn (~10 min).
Impact
Multi-session workflows are effectively broken: an orchestrating session cannot wake
or task idle worker sessions. Rulings/instructions sent between sessions vanish
without any error, which cost us ~50 messages of coordination state today.
Workaround (for other affected users)
We replaced the message channel with a file-based bus: instructions are written to
files, each worker arms a background file-watcher loop whose completion notification
self-wakes the session, and reports are appended to shared files that the
orchestrator watches. This fully restores automation, which also suggests the
background-task notification path is healthy while the cross-session delivery path
is not.
Asks
or fail loudly to the sender instead of returning success).
What Should Happen?
Title: [Windows/Desktop] Cross-session messages to idle sessions are silently lost after auto-update; wake attempts wedge the session
Environment
Claude_pzs8sxrjxfjjc)Summary
We run a multi-session orchestration setup (one verifier session coordinating worker
sessions via the
ccd_session_mgmtsend_message tool). After today's auto-update,cross-session message delivery became state-dependent and lossy:
Messages sent to an IDLE session are silently lost. The sender gets a success
response ("Message sent" / "Message queued"). The message sometimes even RENDERS
in the receiving session's transcript UI. But it is never persisted to the
receiver's session JSONL and the receiving model never processes it.
Verified by grepping the receiver's
~/.claude/projects/<project>/<session>.jsonlfor unique marker strings: 0 occurrences, while the sender-side record exists.
Messages sent while the receiver is ACTIVE (mid-turn) deliver normally at the
next turn boundary. We confirmed this repeatedly in the same session pair, same day.
Wake attempts wedge the session. A message that should wake an idle session
instead starts a turn that spins for ~10 minutes with no output and no JSONL
growth. The session shows a warning icon and only recovers when the user types
into its input box manually. User-typed input persists fine; cross-session
deliveries into the same session do not — so the failure is specific to the
background delivery path, not the transcript writer in general.
Transcript truncation on restart. One receiving session's transcript dropped
from 5,916 to 5,866 messages (~50 lost) across an app restart. Notably, the model
had already acted on instructions contained in the now-vanished messages — i.e.
the content reached the model in memory but was never flushed to the JSONL, and
the restart discarded it. This matches the IndexedDB/JSONL desync described in [BUG] Windows: Claude Code Desktop app shows sessions in sidebar but all message content missing after auto-update — content not persisted to claude-code-sessions JSONL files #53717.
Repro
the marker (grep), B's model never responds; B may enter a wedged turn (~10 min).
Impact
Multi-session workflows are effectively broken: an orchestrating session cannot wake
or task idle worker sessions. Rulings/instructions sent between sessions vanish
without any error, which cost us ~50 messages of coordination state today.
Workaround (for other affected users)
We replaced the message channel with a file-based bus: instructions are written to
files, each worker arms a background file-watcher loop whose completion notification
self-wakes the session, and reports are appended to shared files that the
orchestrator watches. This fully restores automation, which also suggests the
background-task notification path is healthy while the cross-session delivery path
is not.
Asks
or fail loudly to the sender instead of returning success).
Error Messages/Logs
Steps to Reproduce
Title: [Windows/Desktop] Cross-session messages to idle sessions are silently lost after auto-update; wake attempts wedge the session
Environment
Claude_pzs8sxrjxfjjc)Summary
We run a multi-session orchestration setup (one verifier session coordinating worker
sessions via the
ccd_session_mgmtsend_message tool). After today's auto-update,cross-session message delivery became state-dependent and lossy:
Messages sent to an IDLE session are silently lost. The sender gets a success
response ("Message sent" / "Message queued"). The message sometimes even RENDERS
in the receiving session's transcript UI. But it is never persisted to the
receiver's session JSONL and the receiving model never processes it.
Verified by grepping the receiver's
~/.claude/projects/<project>/<session>.jsonlfor unique marker strings: 0 occurrences, while the sender-side record exists.
Messages sent while the receiver is ACTIVE (mid-turn) deliver normally at the
next turn boundary. We confirmed this repeatedly in the same session pair, same day.
Wake attempts wedge the session. A message that should wake an idle session
instead starts a turn that spins for ~10 minutes with no output and no JSONL
growth. The session shows a warning icon and only recovers when the user types
into its input box manually. User-typed input persists fine; cross-session
deliveries into the same session do not — so the failure is specific to the
background delivery path, not the transcript writer in general.
Transcript truncation on restart. One receiving session's transcript dropped
from 5,916 to 5,866 messages (~50 lost) across an app restart. Notably, the model
had already acted on instructions contained in the now-vanished messages — i.e.
the content reached the model in memory but was never flushed to the JSONL, and
the restart discarded it. This matches the IndexedDB/JSONL desync described in [BUG] Windows: Claude Code Desktop app shows sessions in sidebar but all message content missing after auto-update — content not persisted to claude-code-sessions JSONL files #53717.
Repro
the marker (grep), B's model never responds; B may enter a wedged turn (~10 min).
Impact
Multi-session workflows are effectively broken: an orchestrating session cannot wake
or task idle worker sessions. Rulings/instructions sent between sessions vanish
without any error, which cost us ~50 messages of coordination state today.
Workaround (for other affected users)
We replaced the message channel with a file-based bus: instructions are written to
files, each worker arms a background file-watcher loop whose completion notification
self-wakes the session, and reports are appended to shared files that the
orchestrator watches. This fully restores automation, which also suggests the
background-task notification path is healthy while the cross-session delivery path
is not.
Asks
or fail loudly to the sender instead of returning success).
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
No response
Claude Code Version
lastest
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
No response