[BUG] ## UPDATE: CLI Startup Loop Variant Observed (2026-02-02)

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?

New Manifestation of Same Bug

Encountered a different trigger pattern that produces the same catastrophic outcome:

Original bug pattern:

• Claude's output containing commands (e.g., /start-log) misinterpreted as user input
• Loop triggered during conversation after Claude generates responses
• Session log shows commands appearing without user keystrokes

New pattern observed today:

• CLI fails to exit initialization sequence
• Startup screen repeatedly renders before any user interaction with Claude
• Loop occurs at claude command execution, not during conversation

Evidence from Session Log

File: C:\Users\AC\Claude_Conversations\00-system\00.01-Session_Logs\2026-02-02-1700.md

Lines 12-216: CLI renders identical startup sequence 16 times:

 ▐▛███▜▌   Claude Code v2.1.29
▝▜█████▛▘  Sonnet 4.5 · API Usage Billing
  ▘▘ ▝▝    C:\Users\AC

────────────────────────────────────────────────────────────────────────────
> Try "create a util logging.py that..."
────────────────────────────────────────────────────────────────────────────

This block repeats 16+ times with no user input between iterations.

Line 217: User finally gains control, types /start-log
Lines 218-396: Session proceeds normally
Line 397: User asks first substantive question
Line 398: Context limit reached - tokens already exhausted by startup loop

Token Impact

• 30,000-40,000 tokens consumed by startup loop before user can interact
• Session unusable after single exchange
• Identical cost profile to original bug (~$1-1.50 per incident)

Technical Implications

Two different entry points to same failure mode suggests:

1. Shared root cause: Likely in command parsing/execution layer that both startup sequence and runtime output pass through
2. No output sanitization: Neither startup messages nor Claude responses are filtered before CLI parser
3. No loop detection: CLI has no mechanism to detect repeated identical operations

The startup variant is particularly problematic because:

• User has zero opportunity to intervene (no Ctrl+C window)
• Fails before session establishes, so no /exit or /clear available
• Only recovery: Kill process externally, restart terminal

Reproduction Conditions

• Windows 10/11 PowerShell
• Claude Code v2.1.29
• No special configuration or commands required
• Trigger appears random (cannot reliably reproduce on demand)

Frequency

Combined with original bug pattern: 15+ incidents in 30 days. This startup variant observed at least once, possibly more (user may have killed terminal without checking session logs).

Session Log Available

Full session log available on request (contains proprietary business context, not posting publicly).

What Should Happen?

Expected behavior:

1. Startup: User runs claude command → CLI initializes once → displays single startup screen → accepts user input
2. During session: Claude generates text output → output is displayed to user → CLI waits for next user input
3. Commands: Only execute when user explicitly types them (e.g., /start-log, /clear)
4. Token consumption: Proportional to actual conversation length

Actual behavior:

Two failure modes observed, both causing infinite loops and catastrophic token waste:

Failure Mode A (Runtime Output Loop):

• Claude generates text output containing command-like syntax (e.g., mentions /start-log in response)
• CLI misinterprets Claude's OUTPUT as user INPUT
• Executes the command automatically without user keystroke
• Creates feedback loop: output → execution → new prompt → repeat
• Session log shows commands appearing without corresponding user input
• 40-50K tokens consumed per incident

Failure Mode B (Startup Loop):

• User runs claude command
• CLI fails to exit initialization sequence
• Startup screen renders repeatedly (16+ times observed)
• Loop completes before user can intervene
• Session starts with 30-40K tokens already consumed
• First actual user question hits context limit immediately

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

Critical limitation: This bug is non-deterministic. I cannot reliably trigger it on demand. However, I can provide:

1. Environment details where bug occurs
2. Evidence from session logs proving bug exists
3. Patterns observed across 15+ incidents

Environment

• OS: Windows 10/11
• Shell: PowerShell 7.x
• Claude Code Version: v2.1.29
• Model: Sonnet 4.5
• Billing: API Usage Billing
• Working Directory: C:\Users\AC
• Context: Frequent use of custom startup hook that loads CLAUDE.md configuration file
• Session logging: Active (using /start-log command at start of most sessions)
• Frequency: 15+ incidents over ~30 days of daily use (~1-2 incidents per 3 days)

Observed Trigger Patterns (Non-Deterministic)

For Runtime Output Loop (Failure Mode A):

The bug appears to trigger when:

1. User loads specialized agent (custom prompt injection via file read)
2. Agent generates long, structured response (5+ sections with headers)
3. Response contains references to slash commands or session management
4. Session has been running for multiple exchanges (not immediate)

Pattern from one captured incident:

1. User types: /start-log
2. Claude executes skill successfully
3. User types: load the engineer agent
4. Claude reads agent file, begins work
5. User provides detailed project requirements
6. Claude generates long structured response (~2000 tokens) with discovery questions
7. Bug triggers spontaneously - WITHOUT next user input:

• CLI executes /start-log again (appears in session log)
• Claude loads engineer agent again (appears in session log)
• Cycle repeats 3-4 times in rapid succession

1. User (unaware of loop) types answer to questions
2. Claude generates second detailed response with ROI analysis
3. Bug triggers again - 9 repetitions of second response
4. Context limit reached, session unusable

For Startup Loop (Failure Mode B):

1. User opens PowerShell
2. User runs claude command
3. CLI displays startup screen
4. Instead of accepting input, startup screen repeats 16+ times
5. User eventually gains control (loop self-terminates after ~30-40K tokens)
6. User types /start-log - works normally
7. User continues session normally until first substantive question
8. Immediate context limit error

Evidence Available

I can provide full session logs showing:

1. Runtime loop evidence: Commands appearing in log without user keystrokes (CLI inserted them automatically)
2. Startup loop evidence: Identical startup screen repeated 16 times before user gains control
3. Token consumption: Context limits reached after 3-4 actual user exchanges

Session log excerpts (sanitized for proprietary content) available on request.

Minimal Reproduction Attempt (Unsuccessful)

I have attempted to reproduce deterministically with:

# Test 1: Startup loop
claude
/start-log
load the engineer agent
[provide detailed requirements]
# Result: No loop triggered (5 attempts)

# Test 2: Rapid commands
claude
/start-log
load the engineer agent
[immediately type next command]
# Result: No loop triggered (3 attempts)

# Test 3: Long output
claude
[request very long structured response with multiple sections]
# Result: No loop triggered (2 attempts)

Hypothesis for why reproduction fails:

• Possible race condition or timing-dependent trigger
• May require specific CLI state/buffer conditions
• May be related to Windows terminal rendering/buffer handling
• Trigger might be probabilistic based on response length or complexity

What Engineers Need

Since deterministic reproduction isn't possible, engineers likely need:

1. Instrumented logging around command parser to capture:

• Source of commands (user input vs. other)
• Parser state when loop triggers
• Buffer/queue contents during loop

1. Session logs from incidents (I have multiple available)

1. Windows PowerShell specific debugging (bug appears platform-specific)

1. Loop detection telemetry to identify other users hitting this silently

Workarounds Currently Using

1. Monitor terminal for unexpected command execution
2. Keep Ctrl+C ready at all times
3. External token monitoring to detect runaway consumption
4. Frequent context saves (every 5-10 exchanges)
5. Kill process immediately if startup screen repeats: taskkill /F /IM node.exe

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

v2.1.29

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_