Infinite queue-operation loop when user sends message during tool execution

Summary

User message sent while Claude is mid-tool-execution causes infinite enqueue → dequeue loop in the message queue. Process spins at 100%+ CPU, session file grows unboundedly with queue-operation entries.

Environment

• Claude Code version: 2.1.17
• Model: claude-opus-4-5-20251101
• OS: macOS Darwin 25.2.0 (macOS 26.2)

Reproduction Steps

1. Start a Claude Code session
2. Ask Claude to run a long-running Bash command (e.g., any command taking several seconds)
3. While the command is executing (spinner showing), type a follow-up message and press Enter
4. Observe: harness enters infinite loop

What Happened

1. Claude initiated a Bash tool call with "stop_reason": null and "output_tokens": 2 (still streaming)

1. User typed a follow-up message while spinner was showing

1. The harness started looping:

``
10:29:32.122Z - enqueue: "user message..."
10:29:32.144Z - dequeue
10:29:32.166Z - enqueue: "user message..."
10:29:32.188Z - dequeue
... (infinite loop)
``

1. After 9 minutes: 35,000+ queue-operation entries, 117% CPU, session file at 4MB+

Session File Evidence

Line 41 (assistant): text=["I found it — session 166ddde7..."]
Line 42 (assistant): tools=['Bash']  ← IN-FLIGHT TOOL CALL
Line 43 (queue-operation): enqueue   ← LOOP STARTS HERE
Line 44 (queue-operation): dequeue
Line 45 (queue-operation): enqueue
...

The same user message is being enqueued and dequeued in rapid succession (~14ms per cycle) without ever being processed.

Diagnostics

• Queue rate: 70.8 ops/second, ~14ms per enqueue-dequeue cycle
• CPU: 117% (tight loop, no blocking syscalls per sample)
• Memory: 385MB physical footprint
• Network: 10+ established TCP connections to API (idle)

Likely Cause

Race condition in message queue handling when:

• Assistant response is streaming (stop_reason: null)
• A tool call is in progress
• User submits a new message

The dequeue operation doesn't properly handle the pending tool result, so it re-enqueues the message.

Workaround

Kill the process (kill <pid>). Session cannot be recovered — the user message was never processed.

Severity

• Impact: Complete session hang, requires force-kill
• Data loss: User message lost, any in-flight work lost
• Resource: 100%+ CPU until killed, unbounded disk growth

Attachments

I have the full session JSONL (4MB, 35k+ entries) and a CPU sample available if helpful for debugging.