[BUG] /compact hangs indefinitely with no error in desktop local-agent (multi-session) mode — process alive, transcript frozen, UI counter climbs forever
Summary
In the Claude desktop app's local-agent mode (the "Code"/cowork multi-session UI that spawnsclaude … --output-format stream-json --resume <id> subprocesses), a user-invoked /compact on a
large session hangs indefinitely with no error and no recovery path. The UI shows
"Compacting conversation · Xm Ys" and the counter climbs forever; the CLI subprocess stays alive but
stops producing any output; the session goes IDLE. Nothing is thrown — this is a silent stall,
which distinguishes it from the ECONNRESET-throwing large-context failures in #74544 and #67381.
This appears to happen frequently on large, long-running sessions.
Environment
- Claude Code app build 2.1.197
- macOS Darwin 25.5.0
- Model claude-opus-4-8,
--effort high - Run mode: desktop app local-agent / multi-session ("Code") mode, not the standalone TUI. Subprocess args include
--output-format stream-json --verbose --input-format stream-json --include-partial-messages --permission-mode auto --allow-dangerously-skip-permissions --resume <uuid> --replay-user-messages. - Several concurrent local sessions running in the same app.
- No VPN/proxy; no
ANTHROPIC_BASE_URLoverride.
Symptoms / repro signature
/compactinvoked at a clean point on a large session (transcript.jsonl≈ 19 MB).- UI: "Compacting conversation · 11m+", counter never stops.
- The CLI subprocess (PID confirmed via
ps) stays alive the entire time — it does not crash or exit. - The session transcript file
~/.claude/projects/<project>/<cli-uuid>.jsonlstops being written: its mtime froze at the moment compaction began and never advanced again (verified >13 min stale). A healthy compaction streams and keeps writing. - App log
~/Library/Logs/Claude/main.logkeeps emitting[WarmLifecycle:session] Starting idle timeout … 900sfor the stalled session (re-arming) but shows no[CCD CycleHealth] healthy cycle, no[Stop hook] Query completed, and — critically — no error of any kind: noECONNRESET, no timeout, no abort, no 429/529. - Session reads IDLE; there is no automatic recovery. The only escape is abandoning/killing the session (losing state) or, as here, having another session take over the work.
Why this looks distinct from existing issues
- #74544 (1M-context
/compact→ ECONNRESET, macOS) and #67381 (auto-compact dies at 100% context, regression since ~2.1.172): both surface an error / die. This report is a silent hang with no thrown error, specifically inside the desktop local-agent orchestration path — plausibly the same underlying large-uncached-compaction-request root cause, but manifesting as an indefinite stall rather than a reset, and never surfacing to the user or logs. - Related: #72667 (FR to warn on large transcripts / show a size-health indicator) — a health/size warning plus a compaction timeout with a surfaced error and retry would both help here.
What would help
- A hard timeout on the compaction request that surfaces an error and offers retry/recovery instead of hanging forever.
- Emit a compaction error to
main.log(and the UI) when the underlying request stalls — right now there is zero diagnostic signal. - The transcript-size / context-health warning proposed in #72667, so users can pre-empt on large sessions.
Happy to provide sanitized main.log excerpts or ps/mtime captures from the stalled session on request.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Frequency / breadth context from the reporter: these session hangs are not compaction-specific — the reporter observes them almost daily, across a wide variety of conditions (normal turns, tool use, long operations, etc.); this issue happens to capture the
/compactmanifestation because that's what was on screen when it was caught. The common through-line across occurrences is the silent stall: the CLI subprocess stays alive but stops producing output, the transcript.jsonlmtime freezes, no error is written tomain.log, and the session sits IDLE with no recovery path. Flagging the near-daily frequency as prioritization signal — happy to capture and attach additional signatures (non-compaction ones) as they recur.Another silent hang after
/compactcompleted (recurrence)Follow-up to the earlier report in this issue — same signature, one day later, on a newer build.
What happened: A session hung silently right after
/compactfinished. The compaction itselfsucceeded (the compact-summary entry was written to the transcript). The user then sent a short
follow-up message; the session never produced any response to it. The transcript file froze at the
moment that user message was written and never advanced again, while the session still reported as
running/idle in the UI.
Key discriminator — no error at all. The app log shows the compaction cycle closing normally
(
CycleHealth healthy cycle (~105s, hadFirstResponse=false)), then only benign idle-timeoutre-arming and session-warmup lines as the user re-focused and re-sent. No ECONNRESET, no timeout,
no abort, no 429/529, no exception anywhere around the freeze window. This is a pure silent stall,
matching the previously reported incident — distinct from #74544 (ECONNRESET) and #67381 (dies at
100% context), which throw. The
hadFirstResponse=falsemarker indicates the first turn after thecompleted compaction never generated output.
Environment:
replacement then hung the same way.
Signature summary:
/compactcompletes successfully → first user turn afterward produces noresponse → transcript write freezes → silent, no error logged, no automatic recovery. Recurs
daily across builds and both mid- and post-compaction. Happy to provide sanitized log excerpts.
I can add a signature from a different environment (Windows 10 Pro 10.0.19045, Claude Code 2.1.207 via npm, several long-running sessions on one machine driven through the official Telegram channels plugin, shared ~/.claude profile): in my case the bug appears BOUND TO THE PROJECT DIR, not to a process or session.
In afflicted ~/.claude/projects/<slug>/ dirs, new sessions create the <session-id>/ subfolder (tool-results) but never create or append <session-id>.jsonl at all (occasionally a ~322-byte stub with only last-prompt/mode/permission-mode meta lines, zero messages). Process restarts, fresh sessions, and a package swap 2.1.198 to 2.1.207 do not cure it. Meanwhile a sibling project dir on the same machine, same profile, same binary and flags writes transcripts normally (live sessions, megabytes).
5 of my 7 project dirs are afflicted, onset dates spread from Jun 22 to Jul 12. cleanupPeriodDays is not set. Impact matches #75435: every transcript-based hook and sensor is blind for affected sessions while they keep working. One more datapoint: my afflicted sessions run claude-opus-4-8 (same model as this report), while the one project dir that still writes transcripts runs a different model. May be coincidence, flagging it in case it narrows the search.
During active turns in an afflicted dir a FileSystemWatcher records zero file-system events in the project dir (no create attempts visible at FS level), so the write seems to never reach the filesystem. Happy to capture procmon traces with syscall error codes if useful.