[Bug] ! CRITICAL ! Input Unresponsive on Windows After v1.0.113

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/7739
2. https://github.com/anthropics/claude-code/issues/7693
3. https://github.com/anthropics/claude-code/issues/7171

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Having same issue

Me too.

Every version since 1.0.113 up to actual gets worse. Now, with the newest version 1.0.117 -> NOTHING WORKS! It becomes unresponsive right after the start. If one awaits Claude done his startup things - what ever it is doing - and then I can type delayed with 1-1.3 typings per second. With such a delay its impossible to write fluently. Claude Code told me as a workaround to "Use an external Editor and copy & paste the prompt." -> Thank you so much for your constructive input, Claude!
I would rather like see you fix it!

I'm using win10, native install (with powershell script presented on claude code download site, later updated with "autoupdate" and "claude update" manually), windows terminal & git-bash for windows (portable).

Exact same TOTALLY BLOCKING problem here. Claude Code is completely unusable at this point! I cannot type even a single character into either the vs code integrated interface or just a simple windows terminal once Claude Code has been launched.
I am on 1.0.117 according to the Claude Code for VS Code extension.
I downgraded to 1.0.110 and it unfortunately fixed nothing for me.
For more context, while waiting for Anthropic to fix this, I am running Gemini CLI without any problem. Soooo...not a windows, or VS Code problem, but truly Claude Code.

For now using the windows command prompt (not through Windows Terminal) is functional though it can't render any of the unicode characters.

I am having the same issue with the same symptoms with Windows 11 Pro and Claude Code v1.0.117. Note on symptom - if I let the window sit for up to 5 minutes Claude (intermittently) will start accepting input again. These symptoms exists regardless of terminal window (in IDE or out, bash or ps)

As a temporary workaround, pressing enter twice seems to make it accept input again.

Update: We've got a fix coming in 1.0.118. Alternately, temporarily downgrade to 1.0.113.

Update: We've got a fix coming in 1.0.118. Alternately, temporarily downgrade to 1.0.113.

How to prevent, after a downgrade, the auto update on native claude.exe?

I'm just going to point out that in the other bug (that was opened before but somehow closed as a duplicate to this) that builds 111-114 are increasingly laggy on input input. Downgrading to 110 will give you the best overall improvement until the fix is released.

Update: We've got a fix coming in 1.0.118. Alternately, temporarily downgrade to 1.0.113.

1.0.120 still has the issue unfortunately...

This is still a present issue with native install drove me crazy I found a few interesting things and some listed here repeated:

• 2.0.21 Still Present as OP post and many others
• Tapping Enter key 2x DOES unlock it
• If for any reason it bothers you to tap enter here was my solution I found it seems specific to you windows setup and if you use NVM:

I found this in what appears to be my WSL Ubuntu "home" directory for my user account but oddly it only has the npm packages I installed globally in windows?
C:\home\lab\.npm-global\ this is the root of it then I found this: C:\home\lab\.npm-global\claude.cmd which I thought was the native binary, but its an executable "Windows Command Script" however it does use node BUT it runs with 0 issues unlike the windows binary. IF you wanted to use it instead what I did was just took the path opened PowerShell pasted the path to that .cmd and it launched no issue or you can also double click the file and it opens in command prompt but def need to fix the blocker in the native binary asap.

## Consistent Reproduction on Every Launch

I'm experiencing this exact issue on every single launch of Claude Code v2.0.33.

System Info:

• Claude Code: v2.0.33
• Windows: Build 26100 (Windows 11)
• Terminal: Windows Terminal (PowerShell)

Symptoms:

• On every launch, no keyboard input is registered at all
• The system message from SessionStart hook appears immediately
• Double-tapping Enter consistently unlocks keyboard input
• Once unlocked, input works normally for the rest of the session
• The issue persists even after waiting several minutes without the double-tap workaround

What I've Tested:

• Initially, I suspected SessionStart hook was causing it
• Completely disabled all hooks - issue still occurs
• The problem is not timing-related (persists even after waiting minutes)
• Issue happens in all directories (git repos and non-repos)

Behavior:
The double-tap workaround is 100% reliable for me - it always unlocks input on the second Enter press. This
suggests the input handler is stuck in some initial state that requires a keystroke to activate, rather than a
complete freeze.

This is distinctly different from #6796 (corrupted .cmd files) as the issue is present from fresh installation and
happens every single time, not intermittently.

I had the same (or a similar? double Enter helps though) issue. Claude Code (v2.0.37) was running fine, but it started hanging once I generated a CLAUDE.md file with its help. I found that @testing-library/react is the part that makes it hang. @t gives the same result, so I guess it kinda tries to find a referenced file that's not there

hope it helps

UPD: Claude also suggested wrapping the name into backticks (` @testing-library/react `). that helps as well

<details><summary>Full Claude's reply (in case it has some helpful info)</summary>
<p>

Ah! That's a great find! The @testing-library/react mention is definitely suspicious. This is likely happening because:

1. Claude Code might be treating @mentions as interactive elements - Similar to how some CLIs or chat interfaces use @ for commands or mentions (like @file or @symbol), Claude Code might be interpreting @testing-library/react as a

trigger for some interactive parsing mode.

1. Terminal input buffering issue - The @ character could be putting the terminal in an unexpected state where it's waiting for input, which is why pressing Enter twice (once to finish the input, once more to continue) unlocks it.
2. Readline/TTY interaction - If Claude Code uses readline or similar input libraries, @ might be triggering a special input mode.

The fact that pressing Enter twice unlocks it strongly suggests it's an input buffering/prompt issue rather than the content breaking something.

Workaround options:

1. Escape the @ in the markdown - Use backticks: @testing-library/react
2. Rephrase it - "testing-library/react package"
3. Use a different format - Write it as "testing-library for React"

I'd suggest fixing it in C-LAUD-E.md by wrapping package names in backticks (which is also better markdown style anyway):

• ` @testing-library/react ` for React component testing

This is also worth reporting to the Claude Code team if you haven't already - it's a parsing bug where @ symbols in markdown content trigger unexpected terminal behavior.

Want me to fix the file with backticks around all the @ mentions?

</p>
</details>

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

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.