[BUG] 100% CPU / frozen UI during plan mode streaming — auto-mode + fast-mode hot-loop in reactive state

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Submitting a message while in plan mode causes the UI to freeze and the claude process to spike to 100% CPU for the entire duration of the model's streaming response. The UI recovers once
streaming completes, but is completely unresponsive until then.

This makes claude code practially unusable in a linux environment

What Should Happen?

The UI remains responsive while the model streams a response.

Error Messages/Logs

From ~/.claude/debug/<session>.txt, two log lines begin firing in alternating pairs at up to ~30 iterations/second starting the moment the model begins streaming:                          
   
  [auto-mode] hasAutoModeOptIn=false skipAutoPermissionPrompt: user=undefined local=undefined flag=undefined policy=undefined                                                                 
  Fast mode unavailable: Fast mode requires extra usage billing · /extra-usage to enable                                                                                                      
   
  Example excerpt (2-second window, ~50 iterations):                                                                                                                                          
                                                                                                                                                                                            
  2026-05-12T07:12:29.484Z [DEBUG] [auto-mode] hasAutoModeOptIn=false skipAutoPermissionPrompt: ...                                                                                           
  2026-05-12T07:12:29.485Z [DEBUG] Fast mode unavailable: Fast mode requires extra usage billing ...                                                                                          
  2026-05-12T07:12:29.489Z [DEBUG] [auto-mode] hasAutoModeOptIn=false skipAutoPermissionPrompt: ...                                                                                           
  2026-05-12T07:12:29.492Z [DEBUG] Fast mode unavailable: Fast mode requires extra usage billing ...                                                                                          
  ... (continues at ~25-30 pairs/second for ~6.5 minutes)                                                                                                                                     
                                                                                                                                                                                              
  The loop runs for exactly as long as the model streams — in this case from 07:12:26 to 07:18:52 (~6.5 minutes). No API errors, no crashes — the session recovers cleanly once the stream    
  ends.

Steps to Reproduce

1. Have disableAutoMode set in settings (either user or project settings)
2. Open a session in plan mode (e.g. via a CLAUDE.md that activates plan mode, or /plan)
3. Submit a prompt that produces a long streaming response (e.g. a planning request that triggers Explore agents and a plan file write)
4. Observe 100% CPU and frozen UI for the duration of the stream

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.123

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Since this is not listed: I am using the standard Linux terminal.

I analysed the problem with claude code itself via the debug mode. Here is the claude code's hypothesis:

Root cause hypothesis

The [auto-mode] eligibility check and the fast-mode availability check appear to be subscribed to the same reactive state atom. In plan mode with disableAutoMode set, each evaluation
returns false but appears to schedule a state update, which triggers a re-render, which re-evaluates both subscriptions — a positive feedback loop with no debounce or memoization guard.
Each incoming streaming token drives another render cycle, which keeps the loop spinning at token-delivery rate.

Relevant startup log lines confirming the configuration:
[WARN] auto mode disabled: disableAutoMode in settings
[DEBUG] [auto-mode] kickOutOfAutoIfNeeded applying: ctx.mode=plan ctx.prePlanMode=undefined reason=settings

Workaround

None user-side. The loop terminates on its own when streaming ends.

Here is the full debug log:

debug-log.txt