[BUG] Windows Terminal input completely frozen starting from v2.1.30 (regression from v2.1.29)
Bug Description
Claude Code becomes completely unresponsive to keyboard input on Windows Terminal starting from v2.1.30. The screen appears frozen — no characters can be typed, and the input prompt is non-functional. Downgrading to v2.1.29 immediately resolves the issue.
Environment
- OS: Windows 11
- Terminal: Windows Terminal (native, not WSL)
- Shell: PowerShell / Git Bash (both affected)
- Node.js: v20.11.0
- Installation: npm (
@anthropic-ai/claude-code)
Reproduction Steps
- Install Claude Code v2.1.30:
npm install -g @anthropic-ai/claude-code@2.1.30 - Open Windows Terminal
- Run
claude - Attempt to type anything into the prompt
- Result: No input is accepted. Screen appears completely frozen.
Expected Behavior
The prompt should accept keyboard input normally (as it does in v2.1.29).
Root Cause Analysis
Binary diff analysis of the bundled cli.js between v2.1.29 and v2.1.30 reveals the following significant changes:
1. New useInterval hooks (0 → 5)
v2.1.29 had zero useInterval-based animation hooks. v2.1.30 introduces 5 new useInterval hooks running at 50ms–1000ms intervals:
| Hook | Interval | Purpose |
|------|----------|---------|
| Spinner position animation | 50ms / 200ms | Glimmer effect calculation |
| Stalled detection timer | 100ms | Tracks request duration |
| Stalled intensity interpolation | 50ms | Smooth animation easing |
| Team name animation | 1000ms | UI counter increment |
| Elapsed time tracker | 100ms | Duration display |
Each interval triggers a React state update → full Ink re-render → ANSI escape sequence generation → stdout write.
2. Rewritten spinner component
The spinner component was completely rewritten with new Box layout (flexWrap:"wrap", height:1, width:2), a reducedMotion parameter, and a reversed animation frame array — all adding layout computation overhead per render cycle.
3. Additional reactive state
| Metric | v2.1.29 | v2.1.30 | Diff |
|--------|---------|---------|------|
| useInterval hooks | 0 | 5 | +5 |
| useRef | 144 | 153 | +9 |
| useState | 542 | 545 | +3 |
| setTimeout | 302 | 308 | +6 |
| useMemo | 83 | 87 | +4 |
| spinner/animation refs | 182 | 204 | +22 |
Why this breaks on Windows Terminal
Ink (React for CLI) re-renders the entire screen buffer on every state change. On macOS/Linux terminals with Synchronized Output (DEC mode 2026), these rapid re-renders are batched and handled efficiently. However, Windows Terminal's ConPTY layer processes ANSI sequences significantly slower, causing:
- Rapid
useIntervalcallbacks (50–100ms) trigger continuous React re-renders - Each re-render writes ANSI sequences to stdout via ConPTY
- ConPTY cannot drain the output buffer fast enough
- stdout
write()blocks the Node.js event loop - Blocked event loop cannot process stdin (keyboard input)
- Result: Screen appears frozen, input is impossible
prefersReducedMotion does NOT fix this
v2.1.30 added a prefersReducedMotion config option. Testing confirmed it does not resolve the issue — it only changes the visual representation (blinking dot instead of animated spinner) but the underlying useInterval hooks continue firing at the same frequency.
Suggested Fix
- Gate
useIntervalhooks behind a ConPTY/Windows detection check, or significantly increase their intervals on Windows (e.g., 500ms+ instead of 50ms) - Make
prefersReducedMotion: trueactually disable or throttle the interval hooks, not just change visuals - Consider using
requestAnimationFrameor passive rendering instead of aggressive interval-based re-renders
Workaround
Downgrade to v2.1.29:
npm install -g @anthropic-ai/claude-code@2.1.29Related Issues
- #18084 — Severe screen flickering in VS Code/Cursor integrated terminal on Windows (same Ink re-rendering root cause)
- #10736 — Windows Terminal Input Stream Loss After Command Execution
- #19637 — Windows cmd rendering issue since v2.1.3
13 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I'm seeing this too. I can't start any new sessions because I can't type into any of them!
+1
@gongpyung if you press the ENTER key when Claude first starts, then it will unfreeze the terminal and you can use 2.1.31
I'm still testing this workaround to see if it's stable. While it unfreezes the keyboard for inputs the ANSI animations still seem flaky, but I've been able to by-pass this bug so far. If you forget to hit ENTER, then you're out of luck and have to restart Claude.
@gongpyung another workaround; if your terminal is already frozen, then selecting some text and pressing CTRL+V appears to unfreeze it.
Wow..this actually works perfectly! How did you figure this out? Super impressive 😄
I’ll be using your approach for a while. Thanks a lot!
@gongpyung reading the comments in the duplicates and trying their fixes. Some of them worked and some didn't.
It doesn't work perfectly, because if you have a SessionStart hook configured that gets bypassed and doesn't run.
Do you have a SessionStart hook configured?
I started experiencing the same thing. I have a SessionStart hook that runs a command which renders output to the terminal. I ran claude in --debug mode, and saw there was an error parsing the json output of the command.
Removing the hook configuration fixed claude. So, I started debugging the command (it's my cli tool that is configured to be called).
I wasn't getting anywhere. So I ran a test. I configured my hook to fire an echo command.
"SessionStart": [ { "matcher": "startup", "hooks": [ { "type": "command", "command": "echo {}" } ] } ]
I fired claude up again and it still froze.
In conclusion, this isn't a bug with my cli and I've confirmed its a bug with Claude Code and most definitely a bug with the SessionStart hook protocol.
After checking, I confirmed that I don’t have any SessionStart hooks configured myself. However, I did find that one of the installed plugins has a SessionStart hook registered. 😅
~~Fixed as of 2.1.36~~
Scrap that. It was working, but then they released 2.1.37.
Not for me. Bug still exists.
+1 — Confirming this is still present in v2.1.37 on Windows 11 25H2
Environment:
Behavior:
claude --resumerenders the session picker UI correctly, but keyboard is completely frozen — no arrow keys, no typing in search box, no Ctrl+C. Must close the terminal window entirely.claude --continuealso freezes identically.claude(fresh launch, no flags) works fine./resumeslash command from inside a running session works fine.--continueand has not recovered since.Workaround: Launch
claudewithout flags, then use/resumefrom within the session. This uses a different code path and is not affected.This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.