[BUG] /compact hangs indefinitely with no error in desktop local-agent (multi-session) mode — process alive, transcript frozen, UI counter climbs forever #75400

Summary

In the Claude desktop app's local-agent mode (the "Code"/cowork multi-session UI that spawns
claude … --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_URL override.

Symptoms / repro signature

• /compact invoked 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>.jsonl stops 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.log keeps emitting [WarmLifecycle:session] Starting idle timeout … 900s for the stalled session (re-arming) but shows no [CCD CycleHealth] healthy cycle, no [Stop hook] Query completed, and — critically — no error of any kind: no ECONNRESET, 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

• 1M-context session becomes unrecoverable: ECONNRESET on large uncached requests, and /compact fails with the same error #74544 (1M-context /compact → ECONNRESET, macOS) and Auto-compact fails on Opus 4.6 [1m]: session dies at 100% context (regression since ~2.1.172) #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: [Feature Request] Warn on large session transcript + show size/health indicator in session list #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

1. A hard timeout on the compaction request that surfaces an error and offers retry/recovery instead of hanging forever.
2. Emit a compaction error to main.log (and the UI) when the underlying request stalls — right now there is zero diagnostic signal.
3. The transcript-size / context-health warning proposed in [Feature Request] Warn on large session transcript + show size/health indicator in session list #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.