Cross-session messaging silently drops messages; 2 app crashes overnight

Summary

Running many concurrent Claude Code sessions in the same project directory overnight (Windows desktop app), I'm seeing two related problems:

1. Cross-session messaging (send_message/list_sessions MCP tools) silently drops messages in both directions.
2. The desktop app itself crashed twice during the same period, and two long-idle sessions now show a warning/error icon in the session picker that I can't get any detail on.

1. Cross-session message delivery failures

Environment: ~15-20 concurrent Claude Code sessions open in the same project (Windows desktop app), several of them actively working via background subagents. Sessions communicate with each other using the built-in cross-session send_message tool.

Confirmed at least 3 times tonight that a message the sender's transcript shows as sent never appears in the receiving session's conversation at all (no <cross-session-message> block, nothing) — not delayed, just absent. This happened in both directions between the same pair of sessions (A→B failed once, B→A failed once, in two different session pairs).

On one retry, the tool's own response text was different from usual — instead of a plain "sent" confirmation, it said the message was queued because the target session had an in-flight turn, and would be delivered "if that session stays healthy." That phrasing suggests queued messages can be silently discarded if the target session's current turn doesn't end cleanly.

That lines up with something I saw independently and repeatedly tonight from a different angle: subagents I spawned that ran a command in the background (e.g. a long test suite) would sometimes stop and report "waiting for the notification" — but the notification never arrives to a subagent for its own backgrounded work, so it just sat there until I sent it another message to nudge it. If the sessions on the other end of my cross-session messages were stuck in that same kind of state when I tried to reach them, that could explain the queued-but-never-delivered messages. I can't confirm this is the actual mechanism — it's the best-supported guess I have from the outside, not a root cause.

Retrying the same send a few times eventually got through in every case I tried, so it seems intermittent rather than a hard failure — but there's no way from inside a session to know a send was dropped, which makes it easy to silently block on a decision that never actually reached the other party.

2. Two Claude Code crashes overnight, and two sessions now showing a warning icon

The desktop app crashed outright twice during this session — once near the start, and once again about an hour before filing this report. I don't have specifics on what triggered either crash from inside the session.

Separately (possibly related, possibly not), two sessions that have been idle since early in the day now show a warning/error icon (⚠️) next to them in the session list, which weren't there earlier. I checked what I could of their state via the get_session/list_sessions MCP tools and found nothing unusual in the fields those return (no error field, no crash indicator) — whatever is driving that icon isn't visible through the MCP session tools, only in the desktop app's own UI.

Environment

• Claude Code desktop app, Windows 11
• ~15-20 concurrent sessions in one project directory over several hours, many spawning their own background subagents
• Cross-session messaging via the built-in session-management MCP tools