[Bug] Claude Code TUI completely freezes on Windows startup without input
Bug Description
[BUG] [BLOCKER] Claude Code completely freezes on Windows - TUI unresponsive, no input possible, no workaround
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report
- I am using the latest version of Claude Code
Environment
- Platform: Windows 11 (Build 10.0.26200.7705)
- Claude Code version: 2.1.31 (native install)
- Install path: C:\Users\<username>\.local\bin\claude.exe
- Install method: Native
- Terminal tested: PowerShell, CMD, Windows Terminal
- Subscription: Claude Max
Bug Description
Claude Code launches successfully and the TUI renders completely (logo, version, project path, and prompt suggestions are all visible). Hooks may even execute normally. However, after the UI appears, keyboard input is completely dead. No characters appear when typing, the cursor is stuck, and standard interrupt signals (Ctrl+C, Ctrl+Z, Esc) do not work. The only way to exit is force-closing the terminal window.
This is not a startup crash — the application loads fine. The freeze occurs in the input handling layer after the TUI is fully rendered and ready for input.
Critical Finding
The freeze is inconsistent and unpredictable:
# FREEZES - launches, renders UI, but input is dead
claude
claude --project myproject
claude --project myproject "prompt here" # Also freezes
# SOMETIMES WORKS
claude "start" # Worked once with inline prompt
claude /doctor # Seems more reliable
Inline prompts are not a reliable workaround. The freeze appears random but frequent, making Claude Code essentially unusable on Windows.
Steps to Reproduce
- Open PowerShell or CMD on Windows
- Navigate to any project directory
- Run claude (no arguments)
- Observe: TUI renders completely (logo, version, project path, prompt suggestions visible)
- Hooks may execute (if configured)
- Attempt to type anything
- Result: No characters appear, cursor is frozen
- Attempt Ctrl+C, Ctrl+Z, Esc
- Result: No response, process cannot be interrupted
- Must force-close terminal window
Expected Behavior
- Claude Code should accept keyboard input at the prompt after TUI renders
- Standard interrupt signals should work
- TUI should be responsive to input
Actual Behavior
- TUI renders visually and appears ready for input
- Hooks may execute successfully
- But keyboard input is completely dead — no characters register
- Cannot interrupt with Ctrl+C/Ctrl+Z/Esc
- Requires force-kill via closing terminal or Task Manager
Diagnostic Information
claude /doctor output (this command works):
Diagnostics
└ Currently running: native (2.1.31)
└ Path: C:\Users\<username>\.local\bin\claude.exe
└ Invoked: C:\Users\<username>\.local\bin\claude.exe
└ Config install method: native
└ Search: OK (bundled)
Updates
└ Auto-updates: enabled
└ Auto-update channel: latest
└ Stable version: 2.1.19
└ Latest version: 2.1.31
Version Locks
└ No active version locks
Environment details
- .claude.json size: 40KB (not bloated)
- .claude/ folder: Cleared during troubleshooting (was 1.35GB - 800MB projects, 400MB debug)
- Issue persists even after clearing all cached data
- Issue persists across different projects (tested multiple projects, empty test folder)
- Issue persists across different terminals (PowerShell, CMD)
Troubleshooting Already Attempted
- ❌ Cleared ~\.claude\projects\ (800MB) - no effect
- ❌ Cleared ~\.claude\debug\ (400MB) - no effect
- ❌ Cleared entire ~\.claude\ folder - no effect
- ❌ Created .claudeignore for large project - no effect
- ❌ Tested in empty folder with no files - same freeze
- ❌ Tested different terminals (CMD, PowerShell) - same freeze
- ❌ Pressed Esc, Enter, Ctrl+C, clicked in window - no response
- ❌ Launching with inline prompt - inconsistent, mostly freezes
- ✅ claude /doctor works (but not useful for actual work)
Likely Cause
The freeze occurs in the TUI input handling layer after the application has fully loaded and rendered. When a prompt is passed inline, this input-waiting state is bypassed, which explains why inline prompts sometimes work.
Possibly related to:
- Shell snapshot/permission system (referenced in #6823)
- Windows-specific terminal input handling
- Ink/React TUI input event loop in idle state
Related Issues
- #6823 - Claude CLI randomly/predictably freezes on Windows
- #7182 - Incredibly slow performance (PowerShell freezes main thread)
- #7694 - Input is very laggy on Windows systems
- #9114 - Claude Code hangs and freezes on startup
Version Information
- Current version: 2.1.31 (latest channel)
- Stable version: 2.1.19
- Note: Unable to test stable version yet - claude update --channel stable not recognized
Workaround
No reliable workaround exists.
- Inline prompts sometimes work, sometimes freeze
- claude /doctor appears more reliable but is not a functional workaround for actual usage
- Downgrade to stable (2.1.19) untested but recommended
Impact
- Severity: Critical/Blocker - Claude Code is essentially unusable on Windows
- Affected users: Windows users on v2.1.31
- Workflow impact: Cannot use Claude Code for any work
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Update after systematic isolation testing (Windows 11, Claude Code v2.1.31):
Summary: The input freeze is a core Windows TUI bug. Disabling hooks changes the behavior (interactive works), but inline
prompts still freeze.
Tests performed:
1) Disabled SessionStart + Stop hooks (other hooks left as-is)
A) claude (interactive) → WORKS (can type, no freeze)
B) claude "hello" (inline) → FREEZES (input dead during/after output)
C/D) cc moom-order-forecasting hello (alias -> inline) → FREEZES
2) With full hooks ON:
Other isolation steps:
Conclusion:
or hooks.
Workaround for now:
I find that it only happens in git repos
Got the same thing, do a Control+V on some text, you will be able to write in the input box after
I'm facing the exact same issue
Same issue - just hitting enter in the prompt field allowed me to start using it normally
Same issue here
For anyone blocked by this, I run Ubuntu via WSL 2 on Windows 11 and haven't hit this TUI freeze at all. Claude Code runs stable in interactive mode with no input deadlocking.
This completely bypasses the native Windows TUI input handling layer that's causing the freeze. Since the bug appears to be in the Windows-specific stdin/input event loop (as OP identified), running in a real Linux environment sidesteps it entirely.
Not a fix for the underlying issue, but a fully functional workaround until the native Windows path is patched.
I tried the workaround proposed a issue #22969 which is to press ENTER -> it worked for me
Additional datapoints from Windows 11 / MSYS2 Git Bash:
Environment: Windows 11, MSYS2 Git Bash, Claude Code v2.1.25 through v2.1.37 (all affected)
Key finding — Bedrock auth vs OAuth:
I use both
claude(OAuth/subscription) and a Bedrock-authenticated wrapper (claude --profile aws). The stdin freeze only affects OAuth launches. Bedrock auth works reliably in every directory, every time, no Enter needed. This suggests the race condition is in the OAuth async initialization path specifically — Bedrock skips that entirely and narrows the startup window enough to avoid the race.SessionStart hooks widen the race:
With ~10 hooks configured (including a SessionStart hook that spawns a background process), the freeze was near-100% reproducible in project directories. Removing the subprocess spawn from SessionStart reduced severity but didn't eliminate the issue. Home directory (minimal config to load) rarely triggers it.
Pattern:
winpty claude: no improvementWorkaround: Press Enter once after launch to unstick stdin. Consistent across all versions tested.
It's a race condition in the Windows stdin event loop — the TUI renders before the input handler finishes registering. Pressing Enter once after launch unsticks it. SessionStart hooks that spawn subprocesses make it worse. WSL2 bypasses it entirely. Details + hook workaround: https://cacheoverflow.dev/blog/YnaKqv6I