Cross-session message delivery hangs a FleetView background session indefinitely (Windows/Cowork)

Cross-session message delivery hangs a FleetView background session indefinitely (Windows/Cowork)

Note on scope: this is Cowork/Claude Desktop's own session-management messaging (the mcp__ccd_session_mgmt__* tools), on Windows. The public docs for the standalone claude CLI's cross-session messaging (crossSessionInbound, etc.) explicitly say that feature isn't available on native Windows at all — so whatever is running here is a separate implementation the CLI docs don't cover. Worth confirming which subsystem actually owns this before triaging.

Summary

Sending a cross-session message (via the SendMessage/mcp__ccd_session_mgmt__send_message
tool exposed to Claude in a Cowork/Claude Desktop session) to an idle FleetView background
session causes the receiving session to enter an indefinite "running" state with zero
progress — no new tool calls, no text output — once it starts processing the incoming
<cross-session-message> turn. The only way to recover is to manually interrupt (Esc).
This reproduced on the first deliberate test of the feature — a single, trivial,
one-line message asking for a one-line reply — so it doesn't appear to need any unusual
setup or heavy prior usage to trigger.

Separately, on the same machine during the same working session, the whole desktop app
became unresponsive enough that killing its processes via Task Manager did not recover it;
only a full Windows restart did. The Windows-service-level log for Cowork shows a service
restart at that time with no preceding clean shutdown (Service stop requested /
Service stopped pair), consistent with a hard kill/crash rather than a graceful stop —
timing and mechanism line up with the reproducible hang above, though this second,
more severe occurrence couldn't be captured live (see confidence note in that section).

Environment

• OS: Windows 11 Pro 10.0.26200
• App: Claude Desktop / Cowork, package Claude_1.30096.1.0_x64__pzs8sxrjxfjjc
• Bundled CLI inside the app: claude-code 2.1.227 (%APPDATA%\Claude\claude-code\2.1.227\claude.exe)
• Background-session service: CoworkVMService (cowork-svc.exe), Windows service,

LocalSystem, Automatic start, uses HCS/HCN (Hyper-V compute/network) APIs for
VM-backed sessions

• Two Claude Code sessions involved: one active/interactive session, one FleetView

background session (idle, isRunning: false) in a different project directory

Steps to reproduce

1. Have a FleetView background session sitting idle (not currently running).
2. From another session, use the cross-session messaging tool to send it any message

(in our case, a trivial test message asking it to reply with a fixed string).

1. Open/resume the target background session so it processes queued input.
2. The message is delivered and appears in its transcript as a turn like:

``
[user] <cross-session-message from="local_XXXXXXXX..." name="<sender session name>" encoded="1">
<message text>
</cross-session-message>
``

1. The session's state flips to running and a "thinking" timer starts counting up in the UI.

Expected behavior

The session processes the incoming message and either responds, calls a tool, or otherwise
makes visible progress within a normal timeframe (seconds to low minutes).

Actual behavior

• The elapsed-time indicator climbs indefinitely — confirmed still climbing at **48 minutes

4 seconds** with the spinner still active.

• Checking the session's transcript (list_events-equivalent) during this window shows

no new turns or tool calls after the incoming cross-session-message turn — the session
is not doing anything, not even a long-running tool call, it's simply not progressing.

• get_session-equivalent status shows isRunning: true the entire time, with

lastActivityAt frozen at the exact moment the message was delivered.

• The only recovery is pressing Esc to interrupt the turn manually. After that,

isRunning returns to false and the session is usable again — but it never produced
the requested reply, and the interrupted turn is simply gone.

Related, more severe occurrence (lower confidence — corroborating context, not a confirmed reproduction)

Separately during the same working session, after a similar round of cross-session
messaging activity, the Claude Desktop app stopped responding entirely. Attempting to
relaunch it did not help; killing its processes from Task Manager repeatedly did not
help either (the underlying block persisted across process kills). Only a full Windows
restart resolved it.

C:\ProgramData\Claude\Logs\cowork-service.log shows, for that time window, a
Starting CoworkVMService as Windows service entry with no preceding
Service stop requested / Service stopped pair — every other start/stop cycle that
day (before and after) is a clean pair; this one entry isn't, which is the fingerprint of
a hard kill/crash rather than a normal close-and-reopen. We can't prove this is the same
root cause as the reproducible hang above (the exact broken state was lost once the
machine was rebooted), but the timing and the general mechanism — heavy cross-session
messaging activity between FleetView sessions — line up, and after reviewing every
configuration change made during the session, nothing else changed that could plausibly
explain either symptom.

Additional observation: inconsistent inbound delivery to an interactive session

Separately from the hang, we also observed that a reply sent back via the same
cross-session messaging tool from another session did not reliably surface in the
receiving interactive session as a genuine delivered message — every time content
appeared to "arrive," it turned out the human user had manually retyped/relayed it,
never an automatic delivery distinguishable from a normal typed message (no
sender-attribution wrapper). This may be a separate, smaller issue, or may be related to
the same underlying delivery mechanism — noting it here for context since it was found
while investigating the same feature.

Public docs (https://code.claude.com/docs/en/cross-session-messaging) state
cross-session messaging for the standalone claude CLI is not available on native
Windows. Since it visibly works here (partially, and with the bug above) via Cowork's
own session-management tools on Windows, this appears to be a separate implementation
from what that page documents — worth keeping in mind when triaging.

Impact

A single stuck background session can escalate to the entire desktop app becoming
unusable, requiring a full OS restart to recover — a disproportionate blast radius for
what should be an isolated per-session issue.