Sign up
View stargazersSign up

[Bug]: Claude auto-compaction still shows "Thinking" — status:"compacting" is flattened into the generic running state#10959

openedSep 9, 2026byJJardo-51

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Start a thread with the Claude provider and keep working until the context fills up enough that Claude Code compacts on its own (do not type /compact).
  2. Watch the thread status in the web client while that compaction runs.

Expected behavior

Automatic compaction surfaces the same Compacting… state that #9293 added for the manual command, so it is obvious the agent is compacting rather than stalled.

Actual behavior

The thread just says Thinking (and Working for N) for the entire compaction, which can run for minutes with no output. It is indistinguishable from a stuck or looping turn.

The Compacting… state added by #9293 is gated entirely on an explicit /compact user message:

  • apps/web/src/components/ChatView.tsx:661 — isCompactCommandMessage matches a user message whose text is exactly /compact with no attachments
  • apps/web/src/components/ChatView.tsx:2945 — isCompacting is derived from that message plus turn timestamps

Automatic compaction produces no such message, and Claude's own start signal is discarded before any client can see it:

  • apps/server/src/provider/Layers/ClaudeAdapter.ts:3411 — SDKStatusMessage status:"compacting" is flattened into the generic waiting session state
  • apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts:261-279 — orchestrationSessionStatusFromRuntimeState collapses waiting into running

So by the time the orchestration session reaches the client, "compacting" and "running a normal turn" are the same value. compact_boundary only arrives after compaction, so the completed divider and token counts do render — but nothing marks the interval while it is running.

This is the case #7652 originally described (it names ClaudeAdapter's status:"compacting" → waiting flattening as the root cause). #7652 was closed as fixed by #9293, and #7714 — which did implement the automatic path via an optional statusDetail: "compacting" / compactingSince on OrchestrationSession, fed by Claude's status:"compacting", Codex's contextCompaction item, and OpenCode's session.time.compacting — was closed as superseded at the same time. #9293 only shipped the manual /compact command path, so the automatic case is still unhandled on main.

Impact

Minor bug or occasional failure

(Cosmetic in mechanism, but it reliably reads as a hung agent: users cancel turns and waste tokens because a multi-minute silent Thinking looks broken.)

Version or commit

main @ 6c58362 (line numbers above verified against that commit; originally observed on a fork tracking upstream 299404a)

Environment

Linux, web client served from source (apps/server + apps/web), Node 24.15, Claude provider.

Logs or stack traces

shell
1n/a — no error is produced; the status label is simply generic.

Workaround

None for automatic compaction. Typing /compact manually does show Compacting…, but that only covers the case that already works.

JJulius MarmingeSep 9, 2026

Triage

Confirmed on main @ 6c58362. Automatic Claude compaction still has no in-progress Compacting… state. This is the gap #7652 originally named; #9293 only covered the explicit /compact command.

What the code does today

  • Claude's SDKStatusMessage status:"compacting" is mapped to runtime "waiting" in ClaudeAdapter.ts (session.state.changed).
  • Ingestion then collapses "waiting" to orchestration "running" (orchestrationSessionStatusFromRuntimeState). By the time the session reaches the client, compacting and a normal turn are the same value.
  • OrchestrationSession has no statusDetail / compactingSince. RuntimeSessionState has no "compacting".
  • Web (ChatView.tsx) and mobile (use-thread-composer-state.ts) set isCompacting only when a user message is exactly /compact with no attachments. Auto-compaction never produces that message, so the timeline stays on Thinking / Working for N.
  • compact_boundary still becomes the completed context-compaction divider after the fact. The silent interval while compaction runs is unmarked.

Codex contextCompaction item start events and OpenCode session.time.compacting are also unused for in-progress UI. Completion-only signals (thread.state.changed / session.compacted) already feed the divider.

Related

  • #7652 — closed as fixed by #9293. The close covered the /compact chrome and the result row, not auto-compaction while it is running.
  • #9293 — merged. Manual /compact → Compacting… → completed divider.
  • #7714 — closed unmerged as superseded by #9293. That supersession was incomplete for the automatic path.
  • #7589 and #10724 are different bugs (stuck session after /compact; queue rejected during /compact).

No open PR implements automatic compaction status.

Decision

Accept as a remaining gap left by #9293. Do not reopen #7714 as-is.

#7714 is an XL stacked PR (DB migrations, decider settle changes, per-adapter wiring, composition with still-open #7591). Current main already has the #9293 Compacting… UI and completion row. Reopening that branch would fight the tree we have now.

Reuse #7714's overlay idea in a new, smaller change:

  1. Optional statusDetail: "compacting" (plus a compactingSince clock) on OrchestrationSession. Keep status as running so lifecycle / settling stay unchanged and older clients keep decoding.
  2. Stop flattening Claude status:"compacting"; raise and clear the overlay from that signal. Later: Codex contextCompaction started and OpenCode session.time.compacting.
  3. Web + mobile: isCompacting = existing /compact heuristic or session.statusDetail === "compacting".

Cursor and Grok have no ACP compaction start signal — treat as not supported, same as #7652.

Leaving this issue open as the home for that work. Not reopening #7652 or #7714.