/compact executes repeatedly with no user input — phantom dequeue events in queue-operation log (Remote Control + concurrent sessions)

Status Open
Reported on v2.1.212
Maintainer reply None cached
Activity 0 comments · opened Jul 17, 2026

Environment

  • Claude Code CLI version: 2.1.212
  • OS: macOS (Darwin 25.3.0)
  • Setup: Remote Control (mobile) bridged to a local tmux session via a custom session-keeper wrapper script; multiple Claude Code sessions run concurrently in the same project directory

Summary

/compact is executing 3-4 times back-to-back in a session with zero corresponding user input. I never typed /compact in these sessions. This has occurred in at least 4 separate sessions in one evening. In the clearest case, the session JSONL shows a queue-operation "dequeue" event firing with no matching "enqueue" anywhere earlier in the file, followed by a /compact execution that lines up with it to the millisecond — i.e., a compact command materializing from nowhere in the queue log itself, not just appearing to run without visible input.

Evidence (session f9864afc-cd3c-4ac5-b2fa-8e847b9a8ee2.jsonl)

  • Line 341: one queue-operation "enqueue" event for /compact at 01:17:54.161Z
  • Line 349: first /compact execution, 2ms later — this one is legitimate, tied to a real enqueue
  • Line 356: a second "dequeue" event fires 93 seconds later at 01:19:27.783Z with no matching enqueue anywhere earlier in the file
  • Line 359: second /compact execution, matching that orphan dequeue to the millisecond
  • Line 385: a third /compact execution at 01:19:27.840Z (47ms after the second) with no queue-operation event logged at all — this one returned "Not enough messages to compact," confirming it fired against an already-compacted transcript (a replay of a phantom command, not a fresh one)

Three additional sessions from the same evening show the identical pattern (repeated /compact firing with no corresponding user input): catalog-every/8f46f479, and Reconcile-Notion/f5d53dad.

Second, independent confirmation (session c6d15ab6-221e-478e-840d-72b9ba1faf58.jsonl)

A different session, revived on a different evening via a separate phone-based session-revive tool, shows the same mechanism:

  • 07:10:09.885Z: queue-operation "enqueue" for /compact — no real user typing event around it; it executes 8ms later
  • 07:11:14.459Z: my real message ("checking if this is live") correctly queues behind it
  • 07:11:50.163Z: a queue-operation "dequeue" with no shown content — dequeuing the delayed first /compact
  • 07:11:50.094Z: compact_boundary fires, trigger:"manual", preTokens 127181 → postTokens 27122
  • 07:11:50.177Z: a second literal /compact fires immediately after, same promptId as the compact boundary — chained, not a new user action, with another dequeue
  • 07:11:50.276Z: my real message finally surfaces ~100ms after the second phantom /compact

Both executions are tagged trigger:"manual" — Claude Code itself believed these were user-issued. This rules out the away-summary/idle-threshold auto-compact mechanism (a separate, already-fixed issue): it's the queue enqueue/dequeue mismatch producing phantom slash-command execution, now confirmed on a second, unrelated session with a different revive path.

We also grepped all of our local session-revive/resume tooling and settings.json for anything that could inject /compact into a queue, and found nothing — no local script writes this. The mechanism originates inside Claude Code's own queue/replay logic, not in user tooling.

Suspected mechanism

This setup — Remote Control + tmux-hosted session + multiple concurrent Claude Code sessions in the same project directory — overlaps the conditions described in three existing open issues:

  • anthropics/claude-code#26964 — cross-session JSONL contamination
  • anthropics/claude-code#62734 — Remote Control queue can't be cleared from the phone side
  • anthropics/claude-code#38379 — resume crash on queue-operation replay with stale task refs

None of the three is an exact match, but each touches a piece of the same failure surface (queue-operation replay, cross-session JSONL bleed, stale Remote Control queue state). This may be a fourth symptom of the same underlying bug, or distinct but related.

Impact

Every phantom /compact destroys working context without warning or consent, and cost real hours spent debugging what looked like local tooling before the JSONL evidence pointed at Claude Code's own queue-replay logic instead.

Reproduction

Not a clean minimal repro — intermittent. Observed reliably under: Remote Control active, session hosted in tmux via a custom keeper script, multiple concurrent Claude Code sessions open in the same project directory.

View original on GitHub ↗