[Bug] Claude Code freezes intermittently on Windows Terminal

2.0.50 is very buggy, causing lag and it seems to edit entire file instead of targeted edits. Multiple bugs were reported on this.

So the workaround is to rollback to 2.0.49

Steps:

1. Windows Search for: Edit the System Environment variables -> Environment Variables -> New system variable -> name: DISABLE_AUTOUPDATER value: 1.

1. npm install -g @anthropic-ai/claude-code@2.0.49

<img width="327" height="109" alt="Image" src="https://github.com/user-attachments/assets/20434566-4a9f-457d-86a2-ae6c5c3553be" />

I am in version 2.0.53

I am having a similar problem. Claude will freeze in thinking mode for several minutes or hours when.

1. I do not enter anything into the keyboard for a long time.
2. Change focus outside of terminal.

It does not come out of this mode until I reestablish windows focus and hit a key on the keyboard.

This happens multiple times a day. I have had it happen on both Opus and Sonnet

Environment
Platform: win64 10 22H2
Memory 32GB Memory
Processor: Intel i7-7700 4.2G/Hz
Terminal: windows-terminal
Version: 2.0.50

I am in version 2.0.53 I am having a similar problem. Claude will freeze in thinking mode for several minutes or hours when. 1. I do not enter anything into the keyboard for a long time. 2. Change focus outside of terminal. It does not come out of this mode until I reestablish windows focus and hit a key on the keyboard. This happens multiple times a day. I have had it happen on both Opus and Sonnet Environment Platform: win64 10 22H2 Memory 32GB Memory Processor: Intel i7-7700 4.2G/Hz Terminal: windows-terminal Version: 2.0.50

You said you were in 2.0.53, but your last line mentions 2.0.50. Check it up again

Same, on a Mac running inside a Jetbrains IDE terminal window. The animations stop, everything stops.. Just for a few seconds. But every few seconds.

Same here on Windows 10 using claude-code 2.0.47-2.0.53, but only when using WSL. Powershell or CMD have these periodic freezes for some reason.

From what I can see it shouldn't be related to the terminal, but instead to the shell or something else. Getting same results for all 3 shells using both Windows Terminal and ConEmu (via Cmder), and others have the problem on Mac -> bash/sh being the common denominator?

Additionally, observed that when I start claude and begin typing, then as soon as it freezes, a python process will jump to the top in my CPU sorted taskmanager. If I keep typing, the freezing will however resolve and seem to fully stop after about ~30 seconds.

For the time being I just use CMD, check the difference compared to WSL here: (edit: saw it too late, but enabling thinking in CMD makes no difference)
!Image

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 still happens

I am getting this issue on WSL and native. Using a Snapdragon X Elite X1E78100 with claude code version 2.1.7

Major input lag and cancel freezing. I noticed I can repro the lag every time when I ESC a working response, even on a clean chat.

• Windows dominates Mac by about 75% for coding; I get that Anthropic favors Mac, but this should get more attention for the overwhelming majority of folks using Windows (likely using _Windows Terminal_)
• Works fine with wsl and pwsh7 standalone terminals

Actually... I'm also now experiencing this on Wezterm. I'm starting to wonder if it's the binary version. When I first started (on node version), I didn't get this for months.

So I noticed this the moment I migrated to the new "native" binary version, prior to that things worked fine

So I noticed this the moment I migrated to the new "native" binary version, prior to that things worked fine

Me too. But when I went back to npm, the issue persisted. I wonder if it's the middle are that allowed for either lib to work that caused it.

Still Happening — Feb 10, 2026 (Bun Canary v1.3.9-canary.51)

This is still actively occurring on the latest build. Adding my reproduction data from #21576 and #21266 to consolidate the trail.

Environment: Windows 11, PowerShell, Bun Canary v1.3.9-canary.51 (d5628db2), Opus 4.6

My Reproduction Pattern (4 occurrences since Jan 27)

Every instance involves either long-running sub-agent tasks or shell-invoking commands (gh). The TUI silently drops back to the raw PowerShell prompt — no crash, no error, just gone. Sub-agent output is lost.

Latest repro (today): 3 parallel sub-agents running verification gates (~11 minutes in). CC dropped to PS prompt mid-execution. All sub-agent results lost.

Previous repros:

• 54-minute task — garbled escape sequences ([0[I) leaked into PS prompt
• After gh commands — input captured by PowerShell instead of CC
• During task list rendering — focus loss, menu unresponsive

Confirming Community Pattern

Agree with @dylanh724 and @wackoisgod that this correlates with the Bun binary migration. The terminal control handoff during long subprocess execution seems to be the weak point — CC delegates to a child process and never reclaims stdin/stdout.

Related issues: #21576, #21266, #18109

5th Reproduction — Feb 19, 2026: New Pattern — Context Pressure Trigger

Dropped to PowerShell again, this time with an interesting new data point: context was at 2% remaining when it happened.

Two parallel sub-agents were active (one just completed, one still running edits). The TUI vanished mid-execution — active agent's work lost. No crash, no error.

This suggests the terminal escape may be triggered by auto-compaction firing during active sub-agent execution, not just long task duration. The compaction mechanism may be killing the TUI's terminal control while sub-agents are still holding stdin/stdout.

Details in #21576 (5th repro). Still no official response on any of the Windows TUI issues.

Do you guys have lingering disabled MCP added? All of you? @ThatDragonOverThere , @wackoisgod , @Badbird5907 , @JanWerder @JulianVallee , @npomfret , @dmm-l-mediehus , etc?

Turns out that disabled MCP is still infinite-loop checked and, if logged out or disconnected (again - even if disabled), it'll check every single character typed (and even longer on ESC).

Still testing, but so far my input lag is gone on Windows 11 (wsl, pwsh, windows terminal)

EDIT: Anthropic needs to respect the disabled mcp options

EDIT 2: Ah, it was working for an entire hour without input lag - alas, it's back, apologies for the pings

Do you guys have lingering disabled MCP added? All of you? @ThatDragonOverThere , @wackoisgod , @Badbird5907 , @JanWerder @JulianVallee , @npomfret , @dmm-l-mediehus , etc? Turns out that disabled MCP is still infinite-loop checked and, if logged out or disconnected (again - even if disabled), it'll check every single character typed (and even longer on ESC). Still testing, but so far my input lag is gone on Windows 11 (wsl, pwsh, windows terminal) EDIT: Anthropic needs to respect the disabled mcp options - seems like we're affected by this bug. If disabled, why even check if it's still connected - or dig into it _at all_?

No, I am using a clean install of cc.

Does anyone have the capability to rename the title to [Bug] Claude Code freezes intermittently in Win11/wsl? It's not just Windows Terminal.

6th Personal Reproduction — Feb 21, 2026

Another drop to PowerShell. This time during a bash command that was actively executing (python column analysis, ~3s in). Claude had been whirlpooling for ~14 minutes. TUI just vanished — running command output lost, session dead.

That's 6 reproductions in 3 weeks. Roughly daily. Still zero Anthropic response on any of the Windows TUI issues (#21576, #21266, #18109, this one).

Details in #21576 (latest comment).

SEVERITY ESCALATION — Feb 21, 2026: 3 escapes in one session → COMPUTER CRASHED

Three PowerShell escape events in rapid succession today, followed by a full system crash requiring hard reboot.

Hypothesis: Each TUI escape leaves orphaned processes (Bun runtime, sub-agents, bash children) running in the background. Three orphaned process trees in one session likely exhausted system resources (32 GB RAM machine running ML pipelines).

This is now 9 personal reproductions in 24 days. The bug is accelerating — went from ~weekly to 3x in a single session. Combined with the autonomous file deletion (#27507) and permission bypass (#27002), the Windows CLI is actively dangerous for production use.

10+ community reporters. Zero Anthropic response. 2+ months.

Full details in #21576 (latest comment).

Smoking Gun Found — Feb 22, 2026: Orphaned Process Confirmed

10th reproduction. This time with hard evidence of the orphaned process:

(TradingAlertsLive) PS C:\Users\Cassie> [I[O[I[O[I[O[I[O[I[O[I[O[I[O[I[O[I[O[

Those are CSI focus in/out escape sequences ([I = focus gained, [O = focus lost). They accumulated overnight — each time the terminal window gained or lost focus (screen saver, monitor sleep/wake), the dead Bun process dumped another pair.

This confirms: After the TUI escape, the Bun process keeps running in the background. It doesn't exit. It doesn't clean up. It keeps receiving terminal events and dumping escape codes into the orphaned PS prompt.

This explains the computer crash from yesterday (3 escapes → 3 orphaned Bun processes → resource exhaustion on 32 GB machine running ML training).

@dylanh724 @wackoisgod — since you traced this to the Bun migration, the [I[O focus event handling in Bun's ConPTY layer is likely where the bug lives.

Details in #21576 (10th repro).

Escalation: Bun Segfault After 18 Hours — Feb 22, 2026

The TUI escape bug has escalated to actual Bun runtime crashes:

Elapsed: 64460420ms (17.9 hours)
Peak: 3.27GB | Commit: 13.40GB | Faults: 91,058,111
panic(main thread): Segmentation fault at address 0x18

91 million page faults. 13.4 GB commit charge on a 34 GB machine. Segfault at address 0x18 (null pointer deref).

This is the endgame of the TUI escape bug: orphaned processes from previous escapes + long runtime = memory thrashing → segfault. The Bun runtime on Windows cannot handle long-running sessions.

Crash report: https://bun.report/1.3.10/e_11423d3cmgEuhogCkzsxtDk27ysDop8ysD4n59rDm/uj3Civxj3C___A2AwB

Details in #21576 (11th repro).

Cross-posting from #21576: 12th reproduction — fast segfault (9.5 min, not memory exhaustion)

Two Bun segfault crashes in a single day (Feb 22). First after 17.9 hours (memory leak), second after just 9.5 minutes (clean state). Both crash at address 0x18. This proves the null deref is not caused by memory pressure — it's a Bun runtime bug (use-after-free or race condition).

Crash report: https://bun.report/1.3.10/e_11423d3cmgEuhogCkzsxtDk27ysDop8ysD4n59rDmlkj3Csy6j3C___A2AwB

Cross-posting from #21576: 13th reproduction — 3rd incident today (Feb 22)

TUI escape to PowerShell mid-response with [O[I[O[I[O[I[O[ escape codes. This makes 3 crashes in one day: 2 Bun segfaults + 1 TUI escape. System is crashing faster than work can be completed. 13 reproductions in 26 days.

Cross-posting from #21576: 14th reproduction — 4th crash today (Feb 22)

TUI escape with [O[I[O[ codes while monitoring a healthy background process (2.9 GB RAM). 4 crashes in a single day: 2 Bun segfaults + 2 TUI escapes. The user's Python process survived all 4 crashes — it's purely Bun's terminal handling failing. 14 reproductions in 26 days.

Cross-posting from #21576: 15th reproduction — 5th crash today (Feb 22)

TUI escape after 14m 39s churn at 5% context. 5 crashes in one day (2 segfaults + 3 TUI escapes). User cannot complete any multi-step task. 15 reproductions in 26 days, zero response.

Cross-posting from #21576: 16th reproduction — 6th crash today (Feb 22)

TUI escape with [I[O[ codes while sub-agent was mid-file-write. 6 crashes in one day (2 segfaults + 4 TUI escapes). User lost entire day to Bun terminal failures. 16 reproductions in 26 days, zero response.

23 Reproductions. Computers Bricked. Config Files Corrupted. Zero Response. (Feb 24, 2026)

Compiling the full damage report from #21576 for visibility on this community hub:

By The Numbers

• 23 reproductions in 29 days (single user)
• 6 crashes today alone (Feb 24)
• 2 full computer lockups requiring hard reboot
• 1 config file corruption (.claude.json truncated mid-write by Bun crash)
• Lost live trading data during market hours (IQFeed killed, 2+ hours to recover)

Cascading System Damage (from Windows Event Logs)

10:43 PM — "The paging file is too small" (4x consecutive)
11:00 PM — Windows Error Reporting Service: paging file exhaustion
11:13 PM — Microsoft Defender Antivirus terminated (out of memory)
 7:27 AM — "Windows cannot unload registry file. Memory not freed."
 7:29 AM — DNS policy table corrupted (error 0x57)

Root Cause (identified by community)

N-API race condition in Bun v1.3.10 — double-free/use-after-free causing vtable corruption. Full analysis with 27 memory dumps on #21875 (@balandari). Upstream: oven-sh/bun#26984.

What Anthropic Has Done

• Added high-priority + oncall labels to #21875
• Shipped v2.1.51 (plugin features) and v2.1.52 (VS Code fix) with zero crash fixes
• Zero staff comments on any Bun crash issue

The Ask

1. Acknowledge the issue exists
2. Provide an ETA or even "we're investigating"
3. Bump Bun or patch the N-API cleanup race

This is affecting paying customers' production systems. The silence is unacceptable.

Affected issues: #21576, #21875, #22632, #27320, #27847, #27851, #27870

v2.1.53 includes several fixes for crashes impacting Windows users.

If this is a NAPI crash, then I suspect it would not be included in that list but we will investigate.

I'm getting this intermittently, where the terminal freezes at random and I have to restart the terminal. Still happens with v.2.1.52 on Windows. Hope it's fixed on v. 2.1.53, as it's a real pain.

Cross-Linking: 26+ Reproductions on #21576, 4 Computer Lockups

Adding data from #21576: 26+ TUI escape / Bun segfault reproductions in 30 days on Windows. 4 full computer lockups requiring hard reboot (Feb 21, 23, 25, 25). v2.1.53 shipped 4 Windows crash fixes — none addressed the Bun v1.3.10 N-API race condition root cause identified on #21875 (27 memory dumps, WinDbg analysis).

The pattern is always the same: TUI drops to raw PowerShell, Bun process stays alive as orphan spewing [I[O CSI focus codes, orphans accumulate, system resources exhaust, computer locks up.

Versions affected: v2.1.50 through v2.1.55. Zero Anthropic staff comments on any crash issue in 2+ months.

Environment: Claude Code v2.1.55, Windows 11 Pro Build 26200, Bun v1.3.10

Experienced a complete system deadlock on Windows 10 with Claude Code v2.1.76 (Opus 4.6, 1M context).

Symptoms:

• System did not BSOD — no crash, no blue screen
• Windows stayed visually responsive — could switch between windows
• Keyboard completely stopped working — no input accepted anywhere
• Could not reboot gracefully — Ctrl+Alt+Del, Start menu, nothing responded to keyboard
• Only recovery: hard power-off (holding power button)

Environment:

• Windows 10 Home 10.0.19045
• Claude Code v2.1.76, Opus 4.6 with 1M context (just enabled)
• GoLand IDE with Claude Code plugin
• 40 GB RAM, WD SN740 512GB SSD

Context:

• This is a recurring issue — we first reported it in December 2025 as #14674 (system freeze with 2+ GoLand instances + Claude Code), which was auto-closed and locked by the bot
• Had not occurred for several weeks, but returned on v2.1.76 with 1M context enabled
• The freeze pattern is different from BSOD (#30137, #32870) — it's a deadlock, not a kernel crash

Previously reported: #14674 (closed/locked by bot without any team response)
Related root cause analysis: #33949