[BUG] Dispatch permanently bricked once orchestrator transcript grows large — Claude Code process exits code 1 on every resume (88MB transcript, Windows)
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
The Dispatch orchestrator session on my machine has been unusable since 2026-07-27. Every dispatched task fails with TASK ENDED in the UI. Desktop logs show the underlying cause: the Claude Code child process crashes with exit code 1 within ~3 seconds of every resume attempt, before producing any response.
The correlating factor is transcript size. The orchestrator session's transcript is 87,919,021 bytes (~84 MiB) and has been frozen at exactly that byte count since the first crash — nothing can append to it, because every process that tries to load it dies.
Since Dispatch offers no way to start a new thread, there is no user-facing recovery path. Logging out of both devices, rebooting, and re-pairing do not help, because none of those touch the transcript file.
Environment
Claude Desktop version: 1.24012.9 (MSIX / Windows Store package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc)
Claude mobile app version: v1.260721.0 (iOS)
OS: Windows 11, version 25H2 (OS Build 26200.8973)
Plan: Max
First crash: 2026-07-27 06:32:44 local
Frequency: 100% — 60 crash events logged in the current main.log alone, zero in any prior rotation
Steps to Reproduce
Use Dispatch continuously until the orchestrator session transcript reaches tens of MB. (Mine accumulated over ~3 months of daily use including scheduled tasks.)
Dispatch any task from mobile, or trigger any scheduled-task notification that cold-starts the orchestrator.
The task fails. UI shows TASK ENDED; logs show process_crashed.
Expected Behavior
The orchestrator resumes and the task runs — or, if the transcript is too large, the app compacts/rotates it rather than crash-looping.
Actual Behavior
Every resume crashes. Representative CycleHealth record:
session_id: local_ditto_<redacted>
session_type: agent
model: claude-opus-4-6
cli_session_id: 0fa04957-e07e-4f58-a7f6-754c9a14e066
cycle_health: unhealthy
had_first_response: false
seconds_to_outcome: 3
is_resume: true
unhealthy_reason: system_error
error_message: Claude Code process exited with code 1
error_category: process_crashed
transcript_size_bytes: 87919021
And the accompanying error:
[error] Session local_ditto_<redacted> query error: Claude Code process exited with code 1
at qQ.getProcessExitError (...\app.asar\.vite\build\index.chunk-41sTXhtI.js:100:8497)
at byt.<anonymous> (...\app.asar\.vite\build\index.chunk-41sTXhtI.js:100:8302)
at byt.setExited (...\app.asar\.vite\build\index.chunk-D4J9UP7v.js:922:2525)
at Object.onExit (...\app.asar\.vite\build\index.chunk-D4J9UP7v.js:922:4491)
Evidence that transcript size is the discriminator
Within the same log file, sessions that complete normally carry transcripts of 233 KB to 9.7 MB. The only session that crashes is the one at 88 MB. had_first_response: false and seconds_to_outcome: 3 indicate the process dies during transcript load/replay, not during inference.
The size value is byte-identical across all 60 crash events spanning 7/27 → 7/29, confirming the session is frozen — no writes are landing.
Confirmed on disk. The transcript file matches the cli_session_id from the crash record exactly:
...\local-agent-mode-sessions\<org>\agent\local_ditto_<redacted>\.claude\projects\
-sessions-cool-beautiful-gates\0fa04957-e07e-4f58-a7f6-754c9a14e066.jsonl
Length : 87919021
LastWriteTime : 2026-07-26 13:43:50
Last successful write was 7/26 13:43. The first crash was the next resume attempt, 7/27 06:32:44. The file has not been written since. The session's sibling audit.jsonl (86.9 MB) does keep appending, so the audit path survives what the transcript load path cannot.
What I've Already Tried (none worked, and none could have)
Reset Dispatch
Logged out of both devices, rebooted, re-signed in desktop-first
Confirmed both apps on latest builds
Confirmed "Keep computer awake" ON, machine not sleeping
Confirmed Cowork sessions started locally on the desktop run normally
Suggested Fixes
Recovery path (urgent): give users a way to reset or archive the Dispatch thread. Right now a single oversized transcript permanently disables the feature with no remedy.
Guardrail: auto-compact or rotate the orchestrator transcript past a size threshold, rather than crash-looping on resume.
Diagnostics: surface a correlation/task ID on TASK ENDED. The UI error carries none, so users have nothing actionable — this failure was only diagnosable by reading main.log directly.
Fail loudly: process_crashed with had_first_response: false should surface a distinct, actionable error instead of the generic TASK ENDED.
Related Issues
Likely the same root cause behind several reports where local remediation consistently failed:
#45937 — Dispatch main conversation permanently offline despite working Cowork tasks
#40161 — Dispatch tasks execute on desktop but results not reported back
#52330 — Dispatch: messages marked Read but no response delivered (Windows, post-reinstall)
#40179 — Dispatch responses generated but never delivered to clients
Note on timing
Onset (7/27) predates the 2026-07-29 "Elevated errors across all models" incident. Unrelated.
What Should Happen?
Expected Behavior
The orchestrator resumes and the task runs — or, if the transcript is too large, the app compacts/rotates it rather than crash-looping.
Error Messages/Logs
Steps to Reproduce
Steps to Reproduce
Use Dispatch continuously until the orchestrator session transcript reaches tens of MB. (Mine accumulated over ~3 months of daily use including scheduled tasks.)
Dispatch any task from mobile, or trigger any scheduled-task notification that cold-starts the orchestrator.
The task fails. UI shows TASK ENDED; logs show process_crashed.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.24012.9
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗