[BUG] Manual `/compact` flushed from the queue by an interrupt runs completely silently (126s, no indicator); the "Compacting conversation" spinner only appears on the next submit, after the work has already finished

Environment

• Claude Code version: 2.1.227
• Entrypoint: claude-desktop
• OS: macOS (Darwin 27.0.0)

Summary

I queued /compact while a long-running Bash tool call was in flight, then interrupted the tool call. The queued /compact was delivered and did run — it took 126 seconds — but the UI showed no compaction indicator at all for that entire time. The transcript just sat there looking idle, with the /compact message rendered as an ordinary sent message.

Believing the command had been dropped by the interrupt, I typed /compact a second time. That second command was a no-op (Not enough messages to compact., returned in 150 ms) — and that is when the UI finally rendered Compacting conversation · 2s… 9s…, i.e. a progress spinner for work that had already completed one second earlier.

So the indicator is decoupled from the actual compaction: the real 126 s compaction is invisible, and a phantom spinner is attached to a subsequent no-op submit.

Evidence

Session: ~/.claude/projects/<project>/3f887417-04e1-4c37-8f03-10d069c8aa8d.jsonl

| Time (UTC) | Record |
|---|---|
| 05:57:20.884 | assistant → Bash tool_use toolu_013fs7w1BHEifKQpt2Qs9GKJ (a gh run list polling loop) |
| 06:01:32.425 | queue-operation enqueue — "进度呢" |
| 06:02:25.809 | queue-operation dequeue (no content field) |
| 06:02:30.444 | queue-operation enqueue — "/compact" |
| 06:02:34.085 | tool_result is_error:true — The user doesn't want to proceed with this tool use. (my interrupt) |
| 06:02:34.086 | [Request interrupted by user for tool use] |
| 06:02:34.091 | queue-operation dequeue |
| 06:02:34.096 | user → <command-name>/compact</command-name> (promptId 5e4bdc2c-…) — compaction starts here |
| 06:04:40.419 | system / compact_boundary — trigger:"manual", preTokens: 923331, postTokens: 14481, durationMs: 126312 |
| 06:04:41.136 | queue-operation enqueue — "/compact" (my second, manual attempt) |
| 06:04:41.179 | <local-command-stdout>Compacted …</local-command-stdout> (output of the first /compact) |
| 06:04:41.302 | <local-command-stdout>Not enough messages to compact.</local-command-stdout> (the second /compact) |

durationMs: 126312 back-dates the start to 06:02:34.107, which matches the delivery of the queued /compact exactly. There is exactly one compact_boundary in the whole file.

Between 06:02:34 and 06:04:40 the UI rendered nothing indicating work in progress. The spinner I screenshotted (Compacting conversation · 9s) was taken after 06:04:41, i.e. after the boundary had already been written.

Impact

1. A 126-second blocking operation is completely invisible. On a large context (923 K → 14 K tokens here) the session looks hung/idle for over two minutes.
2. The progress indicator lies about what it is measuring. It appeared attached to a command that returned Not enough messages to compact. in 150 ms.
3. It actively invites a duplicate /compact. Here the retype was harmlessly rejected only because the first compaction had just finished. Submitted a few seconds earlier — or in a session where the second /compact finds enough messages — the retype would compact an already-compacted transcript and destroy working context. Compare anthropics/claude-code#78414, where phantom /compact executions cost real context.
4. The Compacted stdout of the first command rendered 40 ms after I pressed enter on the second, so the success message reads as if the retype was what worked. Misattribution is essentially guaranteed.

Repro (as observed; intermittent-ness untested)

1. Start a long-running tool call (e.g. a Bash polling loop) in a session with a large context.
2. While it is running, type /compact so it goes into the queue (queue-operation enqueue).
3. Interrupt the tool call (Esc / reject).
4. The queued /compact is flushed and executes — observe that no compaction indicator appears while it runs.
5. Submit anything else afterwards and observe the spinner appear for work that is already done.

Expected

• The compaction indicator should be shown for the duration of the actual compaction, including when /compact is delivered from the queue by an interrupt.
• No Compacting conversation spinner should be shown for a /compact that immediately returns Not enough messages to compact.

Secondary observation (lower confidence)

The queued message "进度呢" (enqueued 06:01:32.425) never appears anywhere in the transcript as a user message. There is a dequeue at 06:02:25.809, but dequeue records carry no content, so I cannot tell from the log whether it was silently dropped or whether I pulled it back out of the queue myself. Noting it in case it is the same queue-flush path; I am not claiming it as a bug.