claude-code - 💡(How to fix) Fix Cowork Dispatch: results from long-running spawned sessions never relayed back to the thread (after-the-fact readback broken); persists across updates on 1.9659.2

Summary

In Cowork, the persistent Dispatch orchestrator thread spawns Code sessions/tasks fine and delivers results from trivial/fast tasks, but it never receives results from long-running spawned sessions and can no longer review task transcripts after the fact. The orchestrator's after-the-fact result-delivery/readback path is broken while task execution and transcript-writing are healthy. This has persisted continuously for many days across several auto-installed app updates, including the current build.

This looks like the same symptom family as #40358, #40142, and #44867, but I am filing a fresh report because it is still occurring on a current build and the partial-delivery behavior (fast results arrive, long-running ones do not) is a useful additional data point.

Environment

• Claude desktop app: 1.9659.2 (installed/auto-updated 2026-05-28, i.e. the current public build)
• macOS: 26.5 (build 25F71), Apple Silicon (arm64)
• Bundled Code VM: not directly readable (packed in app.asar); standalone claude CLI on the same machine reports 2.1.92
• Mode: Cowork "Dispatch" (the persistent single orchestrator thread on desktop)

What works vs. what is broken

Works:

• Spawning new Code sessions from Dispatch
• Sending the initial message/prompt to a spawned session
• Receiving the result of trivial/fast tasks (result returns inline in the immediate completion)

Broken:

• Receiving results from long-running spawned sessions (the result is never relayed back into the Dispatch thread)
• Reviewing a spawned session's transcript after the fact from within Dispatch

Partial fix only:

• Restarting the app restored the fast-result path but not the long-running result delivery or transcript readback
• Installing app updates (several, over many days) has not fixed it

Steps to reproduce

1. In Cowork Dispatch, spawn a Code session for a task that takes more than a few seconds to complete.
2. Let the spawned session run to completion. (It does complete and writes its full transcript to disk.)
3. Observe the Dispatch thread: the spawned session's card shows it started, but the result is never relayed back into the Dispatch conversation.
4. The result is only obtainable by manually opening the background session; Dispatch itself never ingests or relays it.

Expected vs. actual

• Expected: when a spawned task finishes, its result is relayed back into the same Dispatch thread (plus a completion notification), per the documented Cowork Dispatch behavior.
• Actual: for long-running tasks the result never arrives in the Dispatch thread; the orchestrator does not follow up; transcript review from Dispatch fails.

Additional evidence

• The spawned session's transcript is written correctly to disk and is readable by any ordinary process, so the failure is on the delivery/readback side, not task execution or transcript generation.
• Confirmed live: Dispatch spawned an investigation session itself; that session completed and wrote a full transcript; Dispatch never received the result. It had to be retrieved by opening the background session manually.
• Persistence across updates indicates this is not resolved by the v2.1.87 "Fixed messages in Cowork Dispatch not getting delivered" change for this case; it may be a regression or an uncovered variant (the network-switch onset in #40358 was never confirmed fixed).

Notes

• Other reporters with this symptom family (#40142) found that clearing IndexedDB / LevelDB / Session Storage / bridge-state.json plus a full restart did not fix it, suggesting a renderer/result-delivery code bug rather than local stored-state corruption. That matches the experience here (restart and updates do not durably fix it).

Related issues

#40358, #40142, #44867, #40179, #40178, #40255, #40283, #45937, #52330