[BUG] Cross-session messages are displayed in the target session but never enqueued (model never sees them)

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?

Summary
Since 2026-08-12, messages sent from one local session to another (the "send message to session" / cross-session messaging feature) are rendered in the target session's UI but never delivered to the model. The target session shows the message block on screen, a spinner runs for 10 to 30 seconds, then nothing happens. The message is never written to the target session's transcript, and it disappears entirely when the app is restarted.

This is not a display problem: the receiving model never sees the message at all, so it cannot answer it. The feature is silently non-functional in both directions.

Environment
Claude Desktop 1.30096.1.0 (MSIX), Windows 10 Pro 19045, x64, 16 GB RAM
Bundled Claude Code CLI: 2.1.229 (installed 2026-08-14 01:06)
Still broken after a full uninstall/reinstall of the app on 2026-08-14 00:55
Also reproduced on brand-new, empty sessions (43-line transcript), so it is not related to session size or context saturation
Steps to reproduce
Open two local sessions, A and B, in different project folders.
From session A, send a message to session B (cross-session message).
The tool reports Message sent to session <B>.
Open session B: the message block is displayed in the conversation.
Expected: session B processes the message as a user turn and can reply.

Actual: a spinner runs briefly, then stops. The model in session B never sees the message. Anything typed by the user in session B afterwards is answered normally, with no reference to the cross-session message. The message is absent from session B's transcript on disk and is lost on restart.

Evidence

1. The message never enters the session input queue

The target session's transcript records queue-operation entries for everything that enters its input queue. For a session that received two cross-session messages and three user-typed prompts, the queue journal contains only the user-typed prompts:

11:09:37 enqueue "/restore_session" -> dequeue
11:48:03 enqueue "ok" -> dequeue
11:58:58 enqueue "ok" -> dequeue
Zero enqueue entries for the cross-session messages, although both were displayed in the UI and are visible through the session-listing tooling.

1. The CLI mapping step is skipped for cross-session messages only

In main.log, a user-typed message is followed by a mapping line; a cross-session message is not:

13:56:05 Sending message to session local_<A>
13:56:10 Mapping internal session local_<A> to CLI session <uuid> <-- user-typed, delivered
13:57:14 Sending message to session local_<B>
(no Mapping line at all) <-- cross-session, lost
13:58:58 Mapping internal session local_<B> to CLI session <uuid> <-- user-typed, delivered

1. Exact regression window

Scanning every local transcript on this machine, 443 cross-session messages were received successfully, the last one on 2026-08-12 at 03:43:45 local time. Zero have been received since, although dozens have been sent (Sending message to session ... appears throughout 2026-08-13 and 2026-08-14 in main.log).

The first lost delivery is 2026-08-12 04:35:51. Inside that 52-minute window, the only recorded event is an app/VM restart with a CLI version change:

cowork-service.log
2026/08/12 04:24:00 [Server] Stopping VM for session ...
2026/08/12 04:24:04 [Server] Created new VM session for ...
claude-code binaries
2.1.222 last used 2026-08-12 04:24:05
2.1.227 folder created 2026-08-12 04:24:04
first used 2026-08-12 04:35:40 (11 s before the first lost delivery)
2.1.229 installed 2026-08-14 01:06 (still broken)

1. Secondary symptom: cold target session times out and is flagged as errored

When the target session has no live process, the app warms it up but no turn ever runs, and the session is eventually marked as errored in the sidebar:

13:11:31 Sending message to session local_<B>
13:11:41 [WarmLifecycle:preview] Warming up session local_<B>
13:11:42 LocalSessions.startShellPty: sessionId=local_<B>
13:12:09 [WarmLifecycle:session] Starting idle timeout for local_<B>: 900s
13:27:38 [warn] [CCD] Session local_<B> timed out after 967s of inactivity
(hadFirstResponse=false, last_message_type=user, last_tool_name=none,
seconds_since_stderr=never)
seconds_since_stderr=never indicates the spawned process never produced any output at all, not even an error. No error is surfaced anywhere in the UI or in the logs until the 16-minute timeout.

Impact
Cross-session messaging is the only mechanism that lets one session hand work to another without the user relaying it manually. With it silently broken, the sending side reports success, the receiving side displays the message, and nothing happens. There is no error, no warning, and no trace on disk, so the failure is invisible until someone checks the target session's transcript.

Secondary issue: corrupted session store files are never quarantined or repaired
On the same machine, 150 of the 186 files in AppData\Roaming\Claude\claude-code-sessions\<...>\ contain NUL bytes at 4 KiB boundaries (offsets 4096, 8192, 12288 and neighbours), which is the classic signature of an unclean shutdown. At every launch this produces dozens of parse failures:

[warn] Failed to load session from <file>.json:
Bad control character in string literal in JSON at position 4096
[warn] Failed to load session from <file>.json:
Unexpected token '\x00', "\x00\x00\x00..." is not valid JSON
Two suggestions:

Quarantine corrupted files instead of re-reading them at every launch. They will never parse again, and the app rediscovers and re-logs each of them on every start.
A single corrupted file appears to abort a whole store load. In local-agent-mode-sessions, 8 files were present, 5 corrupted and 3 valid, and the app logged Loaded 0 persisted sessions rather than 3. The failures happen inside a Promise.all, so one rejection may be discarding the whole batch.

What Should Happen?

Session should react when receive an interession message , but it do nothing

Error Messages/Logs

Steps to Reproduce

Send a message intersession

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.30096.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Claude desktop