Skip to content

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

Description

@Jardo-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

n/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.

Activity

  1. juliusmarminge commented on Sep 9, 2026

    @juliusmarminge
    Member

    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

    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.

  2. added
    bugSomething is broken or behaving incorrectly.
    acceptedfeature request accepted
    via-triageFiled through npx t3 triage
    on Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions