CLI: Task execution escapes to PowerShell, becomes unresponsive

Closing as duplicate of #21266 (input focus lost to PowerShell). Same root cause - control escaping to underlying shell.

Reopening - this is a distinct issue from #21266. Focus loss is a different symptom than the app escaping to PowerShell and becoming completely unresponsive during task execution.

Detailed Reproduction - Long-Running Task on Windows

Environment:

• Claude Code on Windows
• PowerShell terminal

What Was Happening

• Claude Code actively running a simulation task (54m 6s elapsed, 1.6k tokens)
• Agent was mid-workflow: "Re-run simulation and collect comparison numbers"
• Multiple sub-tasks were completed (shown with strikethrough)
• 6 files with pending edits (+351 -124 lines) awaiting acceptance

The Bug

Claude Code unexpectedly dropped out of the agent interface back to the raw PowerShell prompt. The terminal shows:

(tradingalertslive) PS C:\Users\Cassie\Desktop\trading_system> [0[Iplease continue

Notice the garbled escape sequence [0[I before "please continue" — this suggests:

1. CC lost control of the terminal
2. User input that should have gone to the CC agent went directly to PowerShell instead
3. The escape codes that CC uses for its UI leaked into the prompt

Expected Behavior

Typing "please continue" should have been interpreted by Claude Code as a continuation instruction.

Actual Behavior

Input went directly to PowerShell as a malformed command.

Possible Triggers

• Long-running task (54+ minutes)
• Large pending edit queue (6 files)

Note: This happens consistently, not tied to any specific terminal setup or remote session.

New Reproduction — Feb 10, 2026

Version: Bun Canary v1.3.9-canary.51 (d5628db2) Windows x64
Claude Code version: Latest (Opus 4.6)
OS: Windows 11

What Was Happening

Claude Code was running a long sub-agent task (Step 4 verification gates on a 2.8 GB parquet file). Three parallel sub-agents were active:

✽ Running Step 4 verification… (11m 29s · ↓t12.0k tokens)
  ⎿  ◼ Step 4 verification gates + score continuity check
     ◼ Run Step 4 verification gate checks on trading system (3,910 → 7,157)
     ◼ Run Step 4 verification gates on ALL_MFE_MOMENTS.parquet

Multiple prior tasks were completed (shown with ✔ checkmarks). The task list, todo spinners, and UI were all rendering normally.

The Bug

Mid-execution (~11.5 minutes into the sub-agent run), Claude Code dropped out to the raw PowerShell prompt:

(tradingalertslive) PS C:\Users\Cassie>

The user's queued input messages (typed while the agent was working) were dumped directly into PowerShell instead of being interpreted by Claude Code. The CC TUI vanished entirely — no garbled escape codes this time, just a clean drop to shell.

Key Details

• Trigger: Long-running parallel sub-agents (~11+ minutes)
• Sub-agent output was LOST — the verification gate results were never returned
• Todo list state preserved on screen but non-interactive (rendered as dead text)
• No crash dialog or error — just silently dropped back to PS prompt
• This is now the 4th reproduction of this bug (previous: 54m task, gh command, and another long task)

Pattern

Every reproduction involves either:

1. Long-running tasks (11-54+ minutes), OR
2. Shell-invoking operations (gh commands)

The common thread seems to be the terminal control handoff — when CC delegates to a subprocess (sub-agent or shell command) for an extended period, it loses control of stdin/stdout and never recovers.

Still hitting this on latest channel (Feb 2026). Running on Windows with MSYS/Git Bash as configured shell. Mid-task, Claude Code drops to a PowerShell prompt (PS C:\Users\Cassie>), interrupting the session. Combined with the stale resume bug, this means losing hours of context every time it happens. High-impact for Windows users running long agent sessions.

5th Reproduction — Feb 19, 2026

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

What Was Happening

Two parallel sub-agents running:

• Agent 1 ("Update project docs") — had just COMPLETED, wrote plan file update
• Agent 2 ("Wire hold/exit classifier into backtest") — still running, reading codebase and making edits

Context was at 2% remaining (about to auto-compact). Claude had just finished updating the plan file and was waiting on the backtest wiring agent.

The Bug

TUI dropped to raw PowerShell prompt mid-execution:

(TradingAlertsLive) PS C:\Users\Cassie>

The task list rendered as dead text on screen (7 done, 1 in progress). The backtest wiring agent's work was lost — it was actively reading and editing files when the drop occurred. No crash, no error, just gone.

Key Detail: Context at 2%

This time the drop happened right at the edge of auto-compaction (2% context remaining). Possible that the auto-compact trigger + active sub-agent execution creates a race condition where the TUI loses control of the terminal.

Pattern Update (5 reproductions)

| # | Trigger | Duration | Context % |
|---|---------|----------|-----------|
| 1 | Long task | 54 min | Unknown |
| 2 | gh command | Short | Unknown |
| 3 | Long task | ~11 min | Unknown |
| 4 | Long task | Unknown | Unknown |
| 5 | Parallel agents + near-compact | ~1.5 min bake | 2% |

New hypothesis: the terminal escape may be related to context pressure / auto-compaction triggering during active sub-agent execution, not just task duration alone.

6th Reproduction — Feb 21, 2026

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

What Was Happening

Claude was running a series of bash commands analyzing column differences between 1-minute and 5-minute feature engineering parquet files. A python command was actively executing (~3 seconds in) while Claude was "Whirlpooling" (13m 52s, 17.9k tokens).

The Bug

TUI dropped to raw PowerShell prompt mid-command execution:

(tradingalertslive) PS C:\Users\Cassie>

The running bash command's output was lost. Task spinner still visible as dead text on screen.

Pattern Update (6 reproductions)

| # | Trigger | Duration | Context % |
|---|---------|----------|-----------|
| 1 | Long task | 54 min | Unknown |
| 2 | gh command | Short | Unknown |
| 3 | Long task | ~11 min | Unknown |
| 4 | Long task | Unknown | Unknown |
| 5 | Parallel agents + near-compact | ~1.5 min | 2% |
| 6 | Bash command mid-execution | ~14 min whirlpool | Unknown |

This is now happening roughly once per day. Every instance loses in-progress work and requires restarting the session.

Additional Note

Also violating multi-line bash rules (#15742) in the same session — all 4 python commands shown used multi-line python -c "..." which bypasses permission allow rules. But the TUI escape is the more severe issue since it kills the entire session.

7th, 8th, 9th Reproductions — Feb 21, 2026: THREE in one session, then COMPUTER CRASHED

Version: Bun Canary v1.3.9-canary.51, Windows 11, PowerShell, Opus 4.6

What Happened

Three PowerShell escape events in rapid succession during the same work session, followed by a full system crash (hard reboot required).

This raises a serious question: is the TUI escape leaking resources? When Claude Code drops to PowerShell, the process doesn't cleanly exit — it just loses terminal control. If the underlying process (Bun runtime, sub-agents, bash children) keeps running in the background after each escape, that's 3 orphaned process trees accumulating memory/handles before the system gave out.

Updated Pattern (9 reproductions)

| # | Date | Trigger | Outcome |
|---|------|---------|---------|
| 1 | Jan 28 | Long task (54 min) | Session lost |
| 2 | Jan 28 | gh command | Session lost |
| 3 | Feb 10 | Parallel agents (~11 min) | Agent output lost |
| 4 | Feb 14 | Long task | Session lost |
| 5 | Feb 19 | Parallel agents + 2% context | Session lost |
| 6 | Feb 21 | Bash mid-execution (~14 min whirlpool) | Command output lost |
| 7 | Feb 21 | Unknown | Session lost |
| 8 | Feb 21 | Unknown | Session lost |
| 9 | Feb 21 | Unknown | COMPUTER CRASHED |

Severity Escalation

• 9 reproductions in 24 days
• Accelerating frequency: 3 in a single session today
• Now correlated with a system crash — possibly due to orphaned processes from repeated TUI escapes
• Combined with the file deletion bug (#27507) and permission bypass (#27002), the Windows CLI experience is actively dangerous

Request

Can someone from the Anthropic team please look at the Windows TUI terminal control code? This has been reported by 10+ users across #12234, #18109, #21576, and #21266. Zero official response in 2+ months.

Specifically:

1. What happens to child processes when the TUI loses terminal control?
2. Are orphaned Bun/node processes cleaned up?
3. Is there a resource leak that accumulates across multiple escape events?

10th Reproduction — Feb 22, 2026: Escape Codes Leaking into PowerShell

Version: Bun Canary v1.3.9-canary.51, Windows 11, PowerShell, Opus 4.6

What Was Happening

7 background bash commands running (ML model training jobs), sub-agent re-pulling data (~1 hour in, 10.6k tokens). Task list active with checkboxes. Claude had been running overnight.

The Bug

TUI dropped to PowerShell as usual, but this time with garbled ANSI escape sequences accumulating on the PS prompt line:

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

[I and [O are terminal focus gained/lost escape sequences (CSI I = focus in, CSI O = focus out). These are being emitted every time the terminal window gains or loses focus (e.g., when the user alt-tabs, clicks away, or the computer wakes from sleep).

Key Finding: Escape Codes Grew Overnight

The user reports that the [I[O[I[O... string grew overnight — it was longer in the morning than when they last saw it. This means:

1. The TUI lost terminal control at some point during the night
2. After the escape, the Bun process was still running and still receiving terminal focus events
3. Each focus gain/lost event appended [I or [O to the dead PS prompt
4. By morning, dozens of focus events had accumulated (screen saver, monitor sleep/wake, Windows background activity)

What This Proves

• The orphaned process theory is confirmed. After the TUI escapes to PowerShell, the Bun process does NOT exit. It continues running in the background, consuming resources and dumping escape codes into the terminal.
• Multiple TUI escapes in one session = multiple orphaned Bun processes. Yesterday we had 3 escapes followed by a computer crash — likely 3 orphaned processes accumulating.
• The [I[O pattern is a smoking gun for the Bun TUI's terminal control code not properly handling ConPTY focus events on Windows.

Updated Count

10 reproductions in 25 days. 4 in the last 48 hours. One caused a computer crash. All on the same Windows 11 + PowerShell + Bun Canary environment.

Still zero Anthropic response.

11th Reproduction — Feb 22, 2026: BUN SEGFAULT CRASH

This time it didn't just escape to PowerShell — Bun itself crashed with a segmentation fault.

Crash Details

Bun v1.3.10 (1423d3c8) Windows x64 (baseline)

Elapsed: 64460420ms | User: 8241968ms | Sys: 533515ms
RSS: 0.31GB | Peak: 3.27GB | Commit: 13.40GB | Faults: 91058111 | Machine: 34.19GB

panic(main thread): Segmentation fault at address 0x18
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Key stats:

• Runtime: 17.9 HOURS (64.4 million ms)
• Peak RSS: 3.27 GB — but Commit: 13.40 GB (virtual memory 4x physical)
• 91 MILLION page faults — the process was thrashing virtual memory for hours
• Segfault at 0x18 — null pointer dereference (address near zero = dereferencing a struct member off a null pointer)

Crash report URL

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

What Was Happening

Claude had been running for ~18 hours (overnight ML training session). 8 tasks in progress (6 done, 1 running, 1 open). Was checking on a background bash command when the crash occurred — specifically during a permission prompt for a ps aux | grep command.

Connection to Previous TUI Escapes

The 91 million page faults and 13.4 GB commit charge suggest this is what happens when the TUI escape bug goes long enough. Previous escapes left orphaned processes (confirmed by [I[O escape codes). Over 18 hours, those orphaned processes accumulated enough memory pressure to cause a segfault in the Bun runtime itself.

Progression:

1. Short sessions: TUI escapes to PowerShell (recoverable with restart)
2. Multiple escapes: Orphaned processes accumulate → computer crash (Feb 21)
3. Long single session: 18 hours → Bun segfaults from memory pressure

Updated Count

11 reproductions in 25 days. This is the most severe yet — a runtime segfault, not just a TUI escape. The Bun binary migration is clearly not production-ready for long-running Windows sessions.

12th reproduction — NEW crash profile (fast segfault, not memory exhaustion)

Previous crash (#11) was after 17.9 hours with 91M page faults (slow memory leak → segfault). This one crashed in 9.5 minutes with clean state:

Elapsed: 572582ms (~9.5 min) | User: 79140ms | Sys: 7734ms
RSS: 0.78GB | Peak: 1.40GB | Commit: 1.12GB | Faults: 1539241 | Machine: 34.19GB
panic(main thread): Segmentation fault at address 0x18

Key differences from #11:
| Metric | #11 (slow) | #12 (fast) |
|--------|-----------|-----------|
| Runtime | 17.9 hours | 9.5 minutes |
| Page faults | 91M | 1.5M |
| Peak RSS | 3.27 GB | 1.40 GB |
| Commit | 13.4 GB | 1.12 GB |
| Crash address | 0x18 | 0x18 (same) |

Same crash address 0x18 (null pointer deref) in both cases. Two distinct crash modes hitting the same null deref — this is not a memory pressure issue, it's a use-after-free or race condition in Bun's runtime.

Context: Claude Code was mid-task (sub-agent running a RAM-safe parquet patch script in background). TUI was idle at the prompt waiting for task completion.

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

Environment: Windows 11, Bun v1.3.10, x64 baseline. 12th reproduction in 26 days. Two crashes in one day (Feb 22).

13th reproduction — 3 incidents in a single day (Feb 22)

Today's tally: 2 Bun segfaults + 1 TUI escape = 3 crashes in ~12 hours.

This instance: Claude was mid-response (user asked to back up parquet files before a patch overwrites them), baked for 34s, then TUI escaped to raw PowerShell. [O[I[O[I[O[I[O[ escape codes visible on PS prompt — orphaned Bun process still alive, receiving terminal focus events.

Context lost: background sub-agent was running a RAM-safe shock feature patch on a 3.5 GB parquet (ALL_MFE_MOMENTS, ~4M rows). Unknown whether the patch completed, corrupted, or was interrupted. User had to manually verify file state and re-backup.

Feb 22 incident log:

1. Bun segfault after 17.9 hours (91M page faults, 13.4 GB commit)
2. Bun segfault after 9.5 minutes (1.5M page faults, clean memory state)
3. TUI escape to PowerShell mid-response (this instance)

All three: Bun v1.3.10, Windows 11, x64. The system is essentially unusable — crashes faster than work can be completed. 13 reproductions in 26 days with zero Anthropic response.

14th reproduction — 4th crash today (Feb 22)

TUI escape to PowerShell with [O[I[O[ escape codes. Claude was monitoring a background Python process (running fine at 2.9 GB RAM, well under thresholds). User said "keep going" → Claude baked for 1m 47s → TUI dropped to raw PS.

Feb 22 incident log (4 in one day):

1. Bun segfault after 17.9 hours (91M page faults, 13.4 GB commit)
2. Bun segfault after 9.5 minutes (1.5M page faults, clean state)
3. TUI escape mid-response (background parquet patch running)
4. TUI escape mid-response (same background process, still running fine)

The Python background process (PID 70472) survived all 4 Claude Code crashes. It's Bun that keeps dying, not the user's workload. 14 reproductions in 26 days, zero Anthropic response.

15th reproduction — 5th crash today (Feb 22)

TUI escape after churning for 14m 39s. Context was at 5% (auto-compact imminent). Claude had just completed an hour-long backtest sub-agent task (11/13 tasks done) and was presenting results. Dropped to PS with [ escape code fragment.

Feb 22 incident log (5 in one day):

1. Bun segfault after 17.9 hours (memory exhaustion)
2. Bun segfault after 9.5 minutes (clean state)
3. TUI escape mid-response (background parquet patch)
4. TUI escape mid-monitoring (Python process at 2.9 GB survived)
5. TUI escape after 14m 39s churn at 5% context (this instance)

5 crashes in a single day. The user cannot complete any multi-step task — every session dies before finishing. Background Python processes survive every crash, confirming Bun is the sole failure point. 15 reproductions in 26 days, zero Anthropic response.

16th reproduction — 6th crash today (Feb 22)

TUI escape mid-task while a sub-agent was retraining an entry model (writing a new training script). Dropped to PS with [I[O[ escape codes. Sub-agent was interrupted mid-file-write — unknown if the script was partially written or corrupted.

Feb 22 final tally: 6 crashes in one day

1. Bun segfault after 17.9 hours (memory exhaustion)
2. Bun segfault after 9.5 minutes (clean state)
3. TUI escape mid-response
4. TUI escape mid-monitoring
5. TUI escape after 14m churn at 5% context
6. TUI escape mid-sub-agent file write (this instance)

16 reproductions in 26 days. 6 in a single day. The user lost an entire day of productivity to Bun crashes. Every multi-step task gets interrupted before completion. Zero Anthropic response.

17th Reproduction — Real Financial Impact (Feb 23, 2026)

The Bun crash epidemic has now caused real financial damage.

Timeline:

• Feb 22: 6 Claude Code crashes in one day (2 Bun segfaults + 4 TUI escapes)
• Feb 22 overnight: Orphaned Bun processes from TUI escapes consumed all system memory
• Feb 22 ~10:43 PM: Windows paging file exhaustion begins — services start failing
• Feb 22 ~11:13 PM: Microsoft Defender crashes (out of memory)
• Feb 23 AM: System found completely frozen, required hard reboot
• Feb 23 AM: Post-reboot DNS policy table corruption (0x57), .NET profiling API failure, registry unload failures
• Feb 23: 2+ hours into market open with no live trading data connection. IQFeed data service was killed by the crash and never restarted. Trading system offline during active market hours.

Windows Event Log evidence:

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

This is no longer just a developer inconvenience. Orphaned Bun processes from the N-API race condition (#21875) are bricking Windows machines and causing downstream financial impact.

17 reproductions in 27 days. 2 full computer lockups. 0 Anthropic responses.

Version: Claude Code v2.1.50, Bun v1.3.10, Windows 11, 34 GB RAM

Reproductions 18-20 — 3 Simultaneous Tab Crashes (Feb 24, 2026)

Three open Claude Code tabs all crashed to PowerShell at the same time:

1. Tab 1: Running a 60-day validation backtest (sub-agent active, 1m 27s in)
2. Tab 2: Mid-conversation about IQFeed connectivity (6% context, near compaction)
3. Tab 3: Idle — completed tasks, waiting for input, brewing for 1m 40s

All three dropped to raw PowerShell with [I[O escape codes simultaneously. Three different workloads, three different context levels, one of them completely idle.

This proves definitively that the crash is in Bun's terminal layer, not triggered by any specific Claude Code workload. An idle session crashed alongside active ones.

v2.1.51 released today. Zero crash fixes. Zero Bun updates. The changelog contains plugin marketplace features and bash login shell optimization while users are experiencing 20 crashes in 29 days.

20 reproductions. 2 computer lockups. Lost live trading data. Zero Anthropic response.

Version: Claude Code v2.1.50/v2.1.51, Bun v1.3.10, Windows 11

Reproduction 21 — Feb 24, 2026

TUI escape 19 minutes into a 60-day validation backtest. Sub-agent was running backtest_pattern_v6.py across the full dataset. Dropped to raw PowerShell with [ escape code.

21 reproductions in 29 days. Still on Bun v1.3.10. Still zero response.

Version: Claude Code v2.1.51, Bun v1.3.10, Windows 11

Reproduction 22 — Config File Corruption (Feb 24, 2026)

New severity: Bun crash corrupted .claude.json configuration file.

After repro #21 (TUI escape during backtest), opening a new terminal to resume produced:

Claude configuration file at C:\Users\Cassie\.claude.json is corrupted: JSON Parse error: Unexpected EOF
The corrupted file has been backed up to: C:\Users\Cassie\.claude\backups\.claude.json.corrupted.1771953011687

The Bun process was mid-write to the config file when it crashed, leaving a truncated file. Claude Code's auto-backup mechanism caught it and restored from .claude.json.backup, but if that backup hadn't existed, all user configuration (permissions, settings, API keys) would have been lost.

Escalation path:

1. Bun N-API race condition → segfault/TUI escape (#21875)
2. Orphaned processes → system memory exhaustion → computer lockup
3. Ungraceful shutdown → DNS policy table corruption, registry errors
4. Now: config file corruption from mid-write crash

This is no longer just a "terminal drops to PowerShell" bug. The Bun crash is causing cascading data corruption across the entire system.

22 reproductions. Config corruption. Computer lockups. Lost trading data. Zero Anthropic response.

Version: Claude Code v2.1.51, Bun v1.3.10, Windows 11

Reproduction 23 — Feb 24, 2026

TUI escape while Claude was mid-analysis ("Crunched for 33s"), about to redesign the move exhaustion detector. 70 tasks tracked in this session, 66 completed. All progress lost.

v2.1.52 shipped today — a single VS Code fix. Still Bun v1.3.10. Still zero response on this issue.

23 reproductions in 29 days. 6 crashes today alone.

Version: Claude Code v2.1.51, Bun v1.3.10, Windows 11

Reproductions 24-25 — Pre-v2.1.53 (Feb 24, while AFK)

Two more crashes on v2.1.50 (before v2.1.53 shipped with 4 Windows crash fixes):

Repro 24: NEW crash type — Illegal Instruction (SIGILL)

panic(thread 34112): Illegal instruction at address 0x7FF711913B20
Elapsed: 86436998ms (24 hours)
RSS: 0.95GB | Peak: 2.75GB | Commit: 19.45GB | Faults: 13293904

This is a SIGILL (illegal CPU instruction), not the usual SIGSEGV. Crash on a non-main thread (34112). 24 hours runtime with 19.45 GB commit charge. Crash report: bun.report/1.3.10/e_11423d3cmgEugogCgy9ktC6q4...

This likely maps to the v2.1.53 fix: "Fixed a crash in the WebAssembly interpreter on Linux x64 & Windows x64" — WASM interpreter generating invalid instructions.

Repro 25: TUI escape with [I[O codes (standard)
Same as all previous TUI escapes. Orphaned process spewing CSI focus codes.

Both on Bun v1.3.10 / v2.1.50. v2.1.53 has since shipped with 4 Windows crash fixes. Testing now.

25 reproductions in 29 days.

v2.1.53 Crash Fixes INEFFECTIVE — v2.1.55 Still Crashing, Another Computer Lockup (Feb 25, 2026)

Repro count: 25+ and climbing.

v2.1.53 shipped 4 Windows crash fixes on Feb 24:

• "Fixed a panic (switch on corrupted value) on Windows"
• "Fixed a crash that could occur when spawning many processes on Windows"
• "Fixed a crash in the WebAssembly interpreter on Linux x64 & Windows x64"
• "Fixed a crash that sometimes occurred after 2 minutes on Windows ARM64"

Result: Multiple Bun crashes on v2.1.55, computer locked up again.

This is now the 3rd computer lockup caused by orphaned Bun processes (Feb 21, Feb 23, Feb 25). The pattern hasn't changed:

1. TUI escapes to PowerShell with [I[O CSI focus codes
2. Bun process stays alive as orphan
3. Multiple orphans accumulate (each crash session leaves one behind)
4. System resources exhaust → full lockup → hard reboot required

What the v2.1.53 Fixes Missed

The 4 fixes targeted specific crash modes (WASM, ARM64, spawn panic). The core issue — Bun's N-API race condition causing terminal loss and process orphaning — is untouched. The community root cause analysis on #21875 (27 memory dumps, WinDbg analysis) identified a double-free/vtable corruption in Bun v1.3.10's N-API layer. None of the v2.1.53 fixes address this.

Timeline

| Date | Repros | Version | Computer Crash? |
|------|--------|---------|-----------------|
| Feb 22 | 6 | v2.1.50 | No |
| Feb 23 | 1 | v2.1.50 | Yes (overnight lockup) |
| Feb 24 | 8 | v2.1.50-53 | No |
| Feb 25 | Multiple | v2.1.55 | Yes — 3rd lockup |

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

4th Computer Lockup — Feb 25, v2.1.55 (Repros 26+)

Another full system lockup today on v2.1.55. Multiple Bun crashes, computer bricked, hard reboot required. That's 4 lockups in 5 days (Feb 21, 23, 25 AM, 25 PM).

v2.1.53's "4 Windows crash fixes" changed nothing. The N-API race condition in Bun v1.3.10 is untouched. Every version from v2.1.50 through v2.1.55 has the same root cause, the same crash behavior, and the same orphaned-process pipeline that kills the system.

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

Repro 27+ on v2.1.58 — TUI Escape, Same [I[O Codes (Feb 25 Evening)

Same crash, new version. TUI dropped to raw PowerShell with [O[I[O[ CSI focus codes on the prompt. Classic orphaned Bun process pattern.

4 Releases in One Day, Zero Progress on This

Anthropic shipped 4 releases today:

| Version | Time (UTC) | Change |
|---------|------------|--------|
| v2.1.53 | 00:13 | 4 Windows crash fixes (didn't address N-API root cause) |
| v2.1.55 | 03:15 | Bash EINVAL fix (regressed session naming) |
| v2.1.56 | 06:27 | VS Code command fix |
| v2.1.58 | 20:00 | "Expand Remote Control to more users" |

v2.1.58 is a feature release — expanding Remote Control access — shipped the same day 90+ users are experiencing Bun crashes and 4 computer lockups.

The N-API race condition identified on #21875 (27 memory dumps, WinDbg analysis, high-priority + oncall labels) remains unaddressed through all 4 releases. Still zero staff comments after 30+ days.

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

Correction: Repro 27+ Was on v2.1.56 (Not v2.1.58)

Correcting my previous comment — the TUI escape with [O[I[O[ codes was on v2.1.56, not v2.1.58. Had to upgrade to v2.1.58 after the crash.

The version table still tells the same story: 4 releases in one day, zero Bun crash fixes after v2.1.53's ineffective attempt.

| Version | Time (UTC) | Change | Crash? |
|---------|------------|--------|--------|
| v2.1.53 | 00:13 | 4 Windows crash fixes | Still crashing |
| v2.1.55 | 03:15 | Bash EINVAL fix | Still crashing, 3rd + 4th lockup |
| v2.1.56 | 06:27 | VS Code command fix | Repro 27+ — TUI escape |
| v2.1.58 | 20:00 | "Expand Remote Control" | Untested (just upgraded) |

Repro 28: Segfault at 0x18 on v2.1.58 (Feb 25 Late Evening)

v2.1.58 — upgraded to this version after v2.1.56 crashed earlier today. Lasted 4.5 hours before segfault.

Crash dump:

• Bun v1.3.10 (d885ce7f) Windows x64
• Segmentation fault at address 0x18
• Elapsed: 16,159,783ms (~4.5 hours)
• RSS: 0.72 GB | Peak: 2.20 GB | Commit: 4.80 GB
• Page faults: 42,699,630 | Machine: 34.19 GB
• Crash report: bun.report/1.3.10/e_1d885ce7mgEuhogCkx34tDk+n9sDoxo9sD43kosDm46y1Ci9i66B___A2AwB

Same crash address 0x18 (null pointer deref) as repros 1-27. Same N-API race condition. 5 releases today (v2.1.53→55→56→58), zero progress.

Running total: 28 crashes in 30 days, 4 computer lockups, 5 releases tested.

Repro 29: TUI Escape on v2.1.56 — Sub-Agent Work Lost (Feb 25)

Another TUI escape with [I[O[ codes, this time on v2.1.56. Two sub-agents were running — one had completed (8 tool uses), one was 32 tool uses deep into a MemoryError investigation (69.6k tokens). Main context had been "Pondering" for 5m 51s when the TUI dropped to PowerShell.

All sub-agent work lost. The completed agent's results never delivered to the parent session.

Running total: 29 crashes in 30 days. v2.1.56 has now crashed twice today (repros 27 and 29).

Versions crashed on today alone: v2.1.55, v2.1.56 (x2), v2.1.58. Plus 4 computer lockups earlier.

Repros 30-31: Two More Crashes on v2.1.58 (Feb 25-26)

Repro 30: Bun crash 13 minutes into rebuilding training parquets. 90 completed tasks in the session, context at 4%. No [I[O codes captured (user typed over them before noticing).

Repro 31: TUI escape with [O[I[O[ codes confirmed. Same session type — heavy multi-agent orchestration work.

Both on v2.1.58. That's 4 crashes on v2.1.58 alone (repros 28-31), plus 2 on v2.1.56, plus multiple on v2.1.55. 31 crashes in 30 days.

Meanwhile, v2.1.59 Just Shipped

Changelog:

• Added /copy command
• Added auto-memory
• Improved bash prefix suggestions
• Improved task list ordering
• Improved memory usage in multi-agent sessions
• Fixed MCP OAuth token refresh race condition
• Fixed shell error message for deleted working directory

Zero Bun crash fixes. Zero acknowledgment of #21875. Zero staff comments on any crash issue.

They fixed an "MCP OAuth token refresh race condition" but not the N-API race condition that's bricking computers. They "improved memory usage in multi-agent sessions" but the multi-agent sessions crash before they can benefit from it.

6 releases in 2 days (v2.1.53→55→56→58→59). Feature after feature. The crash that 90+ users are reporting with 27 memory dumps and a full root cause analysis? Silence.

Running total: 31 crashes in 30 days, 4 computer lockups, 6 versions tested (v2.1.50→53→55→56→58→59).

Repro 32: v2.1.59 Crashes Too — TUI Escape + Config Corruption (Feb 26)

v2.1.59 was briefly stable, then crashed with TUI escape ([O[I[O[ codes) while a sub-agent was running a process check (23+ tool uses deep). Simultaneous .claude.json corruption (Unexpected EOF).

So much for "improved memory usage in multi-agent sessions."

Running total: 32 crashes in 31 days across 7 versions (v2.1.50, 53, 55, 56, 58, 59).

Every single version since v2.1.50 crashes on Windows. The v2.1.53 "4 Windows crash fixes" didn't help. The v2.1.59 "improved memory usage in multi-agent sessions" didn't help. The Bun v1.3.10 N-API race condition identified on #21875 with 27 memory dumps remains unaddressed. Zero staff comments in 30+ days despite high-priority + oncall labels.

Meanwhile, this user is burning extra usage tokens to:

1. Re-do work lost to crashes (context gone, sub-agent results gone)
2. Re-authorize permissions after .claude.json corruption (#28809 — 80+ corrupted configs in 1 week)
3. File bug reports about the product that's causing the crashes

The product is consuming its own billing to manage its own failures.

Repro 32: v2.1.59 Crashes Too + .claude.json Death Spiral Discovered (Feb 26)

v2.1.59's "improved memory usage in multi-agent sessions" did NOT fix the crashes. TUI escape with [O[I[O[ while sub-agent was 23+ tool uses deep. Simultaneous .claude.json corruption.

.claude.json Config Death Spiral (New Finding)

Investigation of ~/.claude/backups/ revealed a cascading failure:

1. 80+ corrupted config files accumulated Feb 18-25
2. Root cause #1: Some writes include a UTF-8 BOM — Bun's JSON parser can't handle BOMs, marks valid 11KB configs as "corrupted"
3. Root cause #2: Auto-recovery replaces the "corrupted" (actually valid) 11KB config with a 262-byte skeleton
4. Root cause #3: The 262-byte skeleton gets backed up as a "good backup," polluting the backup pool
5. Result: User's full config (permissions, allowed tools, MCP servers) is replaced with empty skeleton. EVERY window needs re-authorization.

The "corrupted" files in the backup directory are actually perfectly valid JSON — they just have a 3-byte BOM prefix. The backup system's parser can't handle it, so it destroys the real config and replaces it with nothing.

This user is paying EXTRA USAGE TOKENS to:

• Re-authorize permissions across 8+ windows after every config corruption
• Re-do work lost to crashes (32 times in 31 days)
• File bug reports about the product that's causing all of this

The product is consuming its own billing to manage its own failures.

Running total: 32 crashes in 31 days, 4 computer lockups, 7 versions tested, 80+ config corruptions.

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

Repro 34 — v2.1.59 Crash During Sub-Agent ML Training

Version: v2.1.59
OS: Windows 10 (MSYS_NT-10.0-26200)
Crash count: 34 crashes in 32 days

What happened

A sub-agent was mid-execution (ML model retraining, step 2 of a multi-step training pipeline) when the TUI escape hit. Terminal dumped [I / [O CSI focus reporting escape codes. The "Do you want to proceed?" confirmation dialog was actively displayed when the crash occurred — I got dumped to a raw PowerShell prompt with garbage characters rendered inline.

Key facts

• This is the 2nd crash on v2.1.59. Repro 32 was also v2.1.59. The changelog for this version claimed "improved memory usage in multi-agent sessions" — the memory improvements clearly did not address the underlying Bun N-API race condition that causes these crashes.
• Focus reporting escapes ([I, [O) are STILL being emitted despite multiple reports. This is not a cosmetic issue — it's a symptom of the terminal state corruption that precedes crashes.
• Sub-agent was actively running a bash command (Python ML training script) when the crash occurred. Multi-agent sessions remain the primary crash trigger.
• 34 crashes in 32 days. That is more than one crash per day on average.

The billing problem

I'm paying for Claude Max + additional usage credits. Every single one of these crashes wastes significant tokens:

• The sub-agent's in-flight work is lost
• Context has to be rebuilt from scratch after restart
• Crash recovery itself consumes tokens (re-reading plans, re-establishing state, re-running compacted context)
• I estimate I spend 30-40% of my paid usage on crash recovery and bug management rather than actual productive work

This is not a minor inconvenience. This is a paying customer whose work product is being systematically destroyed by a known, unpatched runtime bug. 34 times in 32 days.

Environment

• Windows 10, PowerShell terminal
• Multi-agent session (main agent + sub-agent running bash)
• Heavy session (~2700 engineered features in ML pipeline)
• Bun runtime (N-API vtable corruption pattern — see #21875 for WinDbg analysis)

REPRO 35 — The Worst Crash Yet. 18 Crashes Today. 276 Config Corruptions Today.

Version: v2.1.59 (the one with "improved memory usage in multi-agent sessions")
Platform: Windows 11 / MSYS2 / PowerShell
Date: 2025-02-25
Crash count today: 18+
Config corruption events today: 276
Total crashes in 32 days: 35

What Happened (This Is The Worst One)

A sub-agent was running mid-task when the Bun TUI escape fired. What followed is not just a crash — it is a complete breakdown of process isolation between Claude Code's internal state and the host terminal.

1. Claude Code's Internal Messages Were Dumped Into PowerShell As Commands

Claude Code's internal error text, file paths, and recovery messages were literally written to the terminal as executable input. PowerShell tried to run them:

The : The term 'The' is not recognized as the name of a cmdlet, function, script file, or operable program.
A : The term 'A' is not recognized as the name of a cmdlet, function, script file, or operable program.
You : The term 'You' is not recognized as the name of a cmdlet, function, script file, or operable program.

The message "The corrupted file has been backed up to..." was executed as a shell command. The TUI horizontal divider lines (───────) were pasted into the terminal as commands. The internal "Bash command" text was dumped as a raw command.

This is a SECURITY ISSUE. Today it was English sentences that PowerShell couldn't parse. What happens when the dumped internal buffer contains something like rm -rf, del /f /q, or a path expansion that resolves to a destructive operation? The TUI is dumping arbitrary internal strings into a live shell with no sanitization. This is not hypothetical — the "Bash command" text that was dumped IS a command string by design.

2. .claude.json Corrupted to 234-Byte Skeleton

Full config is 11,442 bytes. After the crash: 234 bytes. A skeleton with none of the actual configuration. See #28809 for the ongoing corruption saga.

3. Welcome Screen Reset — Treating a Paying Max Subscriber as a New User

After the crash, Claude Code reset to the welcome screen. Theme picker. Login prompt. As if the application had never been installed. This is a paying Max subscriber with extra usage who has been using this tool daily for over a month. The tool forgot who I am.

4. The "Recovery" Makes Things Worse

The crash message pointed to a backup file: .claude.json.backup.1772086898114. That backup file is itself a corrupted 234-byte skeleton. The suggested restore command (cp .claude.json.backup.1772086898114 .claude.json) would restore corrupted data, not the real config. The recovery mechanism is actively harmful. See #28809.

5. 276 Backup/Corrupted Files Created Just Today

The .claude/ directory now contains 276 backup and corrupted config files from today alone. Each one represents a crash or corruption event. That is roughly one every 2-3 minutes of active use.

The Numbers

| Metric | Value |
|--------|-------|
| Crashes today | 18+ |
| Config corruptions today | 276 |
| Total crashes in 32 days | 35 |
| Days since first report | 32 |
| Version | v2.1.59 ("improved memory usage") |
| .claude.json expected size | 11,442 bytes |
| .claude.json after crash | 234 bytes |
| Backup file size | 234 bytes (also corrupted) |

The Real Cost

I am a paying Max subscriber with extra usage. Every crash:

• Burns paid tokens (the conversation context is lost, work must be re-prompted)
• Corrupts configuration (manual restoration required)
• Destroys in-progress work (sub-agents mid-task are killed)
• Requires 5-15 minutes of recovery before work can resume

At 18 crashes today, I have spent more time recovering from crashes and managing bugs than doing actual work. The tool is not just unreliable — it is a net negative on productivity on days like today.

v2.1.59 Did Not Fix This

The changelog says "improved memory usage in multi-agent sessions." The multi-agent sessions are still crashing. The memory is still being mismanaged. The TUI is still dumping internal state into the host terminal on crash. Whatever was "improved" did not address the root cause.

Related Issues

• #28809 — .claude.json corruption (276 events today, anti-pattern recovery)
• #21875 — N-API crash now dumping raw TUI state into host terminal
• #16157 — Mega-thread, worst single-day experience ever reported

This has been 35 crashes across 32 days. I have provided detailed reproduction steps, terminal output, file sizes, corruption evidence, and crash counts for every single one. The product is unusable on Windows for multi-agent workflows. Something fundamental is broken in the Bun TUI lifecycle management and it is not being addressed.

Repros 35 & 36 — 20+ Crashes in a SINGLE DAY on v2.1.59 (Feb 25, 2026)

This is beyond absurd. 20+ crashes in ONE DAY. 36 total in 32 days. I am a paying Max subscriber running a live trading system and I cannot keep my monitoring up for more than minutes at a time because Claude Code keeps dying.

Repro 35: Sub-Agent ML Training Crash + TUI Escape Dump

• Sub-agent was mid-execution (ML model retraining) when the crash hit
• Terminal dumped [ CSI focus escape codes — raw terminal control sequences vomited into the shell
• The "Do you want to proceed?" confirmation dialog was actively showing when it crashed
• Got dumped to a raw PowerShell prompt
• This follows Repro 34 where Claude's own internal messages were being executed as PowerShell commands — that's not just a crash, that's a potential security issue

Repro 36: Crash Cascaded Into OTHER Running Applications

• Another window crashed with T fragment and horizontal divider line artifacts in the TUI
• IB Gateway (a completely separate Java trading application) had to be restarted because the Bun crash cascaded into disrupting other running processes
• This is a LIVE TRADING SYSTEM. The crashes are no longer contained to Claude Code — they are now taking down adjacent infrastructure

The Numbers (Feb 25, 2026 alone)

• 20+ Bun/TUI crashes in a single day
• 278 config corruption events (backup files in ~/.claude/backups/)
• 36 total repros documented over 32 days
• Version: v2.1.59

What This Means In Practice

I am trying to run 24-hour system monitoring for a live trading system. I cannot do this. The tool crashes every few minutes. When it crashes, it doesn't just kill Claude Code — it's now cascading into crashing my trading infrastructure (IB Gateway). Every crash requires manual intervention: restart Claude Code, restart whatever else it took down, hope it lasts longer than 10 minutes this time. It doesn't.

32 Days. Zero Response.

I have been meticulously documenting every single crash for 32 days. I have a support ticket open (#215473249874164). I have filed detailed repros with terminal output, screenshots, config diffs, and forensic analysis. The response from Anthropic has been absolute silence. Not a "we're looking into it." Not a "we can't reproduce." Nothing. Zero. For a paying Max subscriber whose workflow is being destroyed.

Cross-ref: #21875, #16157, #28809 (config corruption — 278 events today alone)

Repros 38, 39, 40 — Three more crashes in a single session (Feb 26, v2.1.59)

Crashed while:

• Repro 38: Mid-CORE 16 ML model validation. 18 minutes of compute and context destroyed.
• Repro 39: Restarting a production trading monitor after fixing IQFeed connection issues. The monitor fix was done, the restart command was running, TUI escape hit.
• Repro 40: Reporting the previous crashes. Literally crashed while documenting crashes.

All three produced the same [I[O[I[O[ CSI focus reporting escape codes dumped into the terminal.

Running total: 40 crashes in 33 days. At least 22 on Feb 25-26 alone.

PowerShell also threw error 800705af ("Loading managed Windows PowerShell failed") — which means Bun's orphaned processes have corrupted enough system state that PowerShell itself is failing to load. This is beyond Claude Code instability — it's degrading the entire Windows environment.

Meanwhile, since our last report, Anthropic:

• Closed #28809 (our .claude.json corruption root cause analysis with BOM identification, atomic write fix proposal, and 278-event-per-day evidence) as a "duplicate" — while 5 NEW issues about the same bug were filed the same day (#29023, #29050, #29051, #29053, #29075)
• Shipped features: auto-memory, /copy command, Remote Control expansion
• Shipped zero crash fixes since v2.1.53 (which was ineffective)
• Responded to zero of our 117+ comments across 24 issues

This user is trying to run a production trading system. Every crash doesn't just waste Claude Code tokens — it kills live monitoring sessions, destroys ML training runs, and risks missing real market events. The product is being used for serious work and it cannot sustain a 30-minute mean time between failures.

The N-API race condition root cause was identified by the community months ago on #21875. The atomic write fix for .claude.json is a standard pattern (temp+fsync+rename) that takes a day to implement. Neither has been acknowledged, let alone fixed.

At what point does someone at Anthropic read their own bug tracker?

Repro 41: 5th FULL COMPUTER LOCKUP (Feb 26, v2.1.59)

The orphaned Bun processes bricked my entire machine again. Hard reboot required.

5 computer lockups in 8 days. Not application crashes — full system lockups where Windows becomes unresponsive and the only option is holding the power button.

The orphan killer script I built (because Anthropic won't fix process cleanup) runs every 5 minutes and has killed 20+ orphaned processes in the last 24 hours alone, some consuming over 1GB RAM each. But it can't keep up. The crashes spawn orphans faster than the cleanup cycle catches them, they accumulate, exhaust all system RAM, and the machine locks.

Here is a sample from the kill log (last 24 hours):

PID=32164 Mem=1059.1MB Runtime=00:33:24
PID=44712 Mem=887.2MB  Runtime=03:00:31
PID=42640 Mem=1032.4MB Runtime=01:35:53
PID=39384 Mem=1045.1MB Runtime=01:54:50
PID=57052 Mem=972.5MB  Runtime=03:04:45
PID=24036 Mem=1028.8MB Runtime=02:28:29

Six processes, nearly 6GB of leaked RAM from a single day. And these are just the ones that survived long enough for my script to catch — many more accumulate and crash the system before the 5-minute cleanup window.

Running total: 41 crashes in 33 days. 5 computer lockups. 280+ config corruptions. Zero Anthropic responses.

The root cause is known: Bun processes are not cleaned up on crash. No atexit handler, no process group kill, no child process lifecycle management. When the TUI crashes (N-API race condition), the Bun runtime stays alive receiving terminal focus events, leaking memory until the system dies.

Meanwhile this week: auto-memory, /copy command, Remote Control. Zero crash fixes since v2.1.53.

Another user on #29023 had their ENTIRE USER PROFILE deleted by this build. I'm building watchdog scripts and orphan killers to keep my machine alive. This is not acceptable for a paid product.

Addendum to Repros 38-41

The user attempted to use /bug to file a crash report through Claude Code itself. It crashed during the bug report. The crash output could not be captured because the TUI escape killed the terminal session.

You literally cannot report a bug in this product because the product crashes while you try to report the bug. Think about that.

This is the 5th full computer lockup in 8 days. The user has built:

• A watchdog script to restore corrupted config files every 30 seconds
• An orphan killer scheduled every 5 minutes that has killed 20+ leaked processes (some >1GB each)
• A golden backup system in git because the built-in backup mechanism poisons itself

None of this should be necessary for a paid product. The user is spending more time and compute on crash recovery infrastructure than on their actual work (a production trading system).

41 crashes. 33 days. 5 computer lockups. 280+ config corruptions. Zero acknowledgment.

Repros 42, 43, 44 — Three more in one hour (Feb 26, v2.1.59)

• Repro 42: Crashed mid-CORE 16 validation after context compaction. 3 min of work lost.
• Repro 43: Crashed mid-MFE model implementation. Session was implementing "no re-entry after MFE" rule.
• Repro 44: Crashed mid-CORE 16 backtest — 2.5 minutes into a validation run, results were about to return.

All three: TUI escape with [I[O[ codes, session killed, config corrupted.

44 crashes in 33 days. 25+ today alone. The product is now crashing every 15-20 minutes during active use with sub-agents.

Also filed a comprehensive bug with Bun directly: oven-sh/bun#27471

At this point the user cannot complete any task that takes longer than 15 minutes. ML model training, backtesting, code implementation — all require sustained sessions that this product cannot provide.

Repros 45, 46, 47, 48 — Four simultaneous crashes (Feb 26, v2.1.59)

User stepped away for one minute. Came back to find 4 windows had crashed simultaneously with TUI escape [I[O[ codes. All four were running active sessions with sub-agents.

48 crashes in 33 days. 29+ on Feb 26 alone.

The product cannot sustain a session longer than 15-20 minutes during active multi-agent use on Windows.

v2.1.61 Note

Just updated to v2.1.61 which includes "Fixed concurrent writes corrupting config file on Windows." This is the exact bug we documented in #28809 (closed as dup of #28847) with 280+ corruption events per day, BOM death spiral analysis, and the atomic write fix proposal we've been requesting for a month.

Good to see it fixed. The underlying Bun N-API crash that CAUSES the config corruption is still unfixed — see oven-sh/bun#27471 for the comprehensive report filed today. The config fix means crashes won't destroy settings anymore, but the crashes themselves continue.

Running total: 48 crashes, 33 days, 5 computer lockups, 280+ config corruptions, 29 crashes today.

Repro 49: First crash on v2.1.61 (Feb 26)

v2.1.61 shipped "Fixed concurrent writes corrupting config file on Windows." The config corruption fix is appreciated — but the Bun crash itself is unchanged.

Crashed mid-paper-trading-readiness-audit. TUI escape with [I[O[ codes, session killed. Same pattern as the previous 48 repros.

The config fix addresses a symptom. The disease is the Bun N-API race condition (oven-sh/bun#27471). v2.1.61 confirms this: fix the file writes, crashes still happen. The runtime itself is unstable.

49 crashes in 33 days across 9 versions (v2.1.50→61). 30 today.

End of Day Report: 30 Crashes on Feb 26 (Repros 19-49)

Summarizing the worst single day in 33 days of tracking:

30 Bun crashes today. Every 15-20 minutes during active use. All TUI escape with [I[O[ CSI focus codes.

What was destroyed today:

• 3 ML model training/validation runs (18+ min compute each)
• 2 CORE 16 backtests (results were seconds from returning)
• 1 production trading monitor restart
• 1 paper trading readiness audit
• 4 windows crashed simultaneously while user stepped away for 1 minute
• 1 full computer lockup (5th in 8 days, hard reboot)
• 1 crash while trying to file a bug report about the previous crash

v2.1.61 config fix is appreciated — stevenpetryk's incident response on #28847 today was the first meaningful Anthropic engagement in 33 days. Thank you.

But the Bun crash is unfixed. v2.1.61 confirmed: config writes are now atomic, crashes still happen. Repro 49 was on v2.1.61. The config fix addresses a symptom; the Bun N-API race condition (oven-sh/bun#27471) is the disease.

User has now switched from the Bun binary to npm install (runs on Node.js) as a workaround. Will report if this eliminates the crashes.

Running total: 49 crashes in 33 days across 9 versions. Zero acknowledgment of the crash itself from Anthropic — only the downstream config corruption has been addressed.

Update: Node.js Runtime = Stable (Feb 27)

After switching from the native Bun binary to npm install (Node.js runtime), the user has had zero crashes overnight — the first stable overnight session in 33 days.

Same v2.1.61. Same features. Same workload. Only difference: Node.js instead of Bun v1.3.10.

This conclusively isolates the crash to the Bun runtime, not Claude Code's application code. The N-API race condition documented on #21875 and oven-sh/bun#27471 is the root cause.

Recommendation for other Windows users experiencing crashes: Install via npm instead of using the native binary:

npm install -g @anthropic-ai/claude-code

This runs the same version on Node.js and eliminates the Bun segfaults, TUI escapes, orphaned processes, and computer lockups.

Previous 33 days on Bun: 49 crashes, 5 computer lockups, 280+ config corruptions.
First night on Node.js: Zero crashes.

Auto-Updater Silently Reinstalls Bun Binary, Overriding User's Deliberate Node.js Workaround

New development that makes this issue significantly worse.

Timeline

After 49 documented crashes on the Bun binary over 33 days, I switched to the Node.js runtime via npm install -g @anthropic-ai/claude-code on Feb 26. Result: ZERO crashes for 4+ consecutive days. The product was finally stable.

Then overnight on Mar 3, the Claude Code auto-updater (autoUpdatesChannel: "latest" in settings.json) silently re-downloaded the Bun-compiled native binary to ~/.local/bin/claude.exe. Since .local/bin is earlier on PATH than the npm global directory, the Bun binary took precedence without any notification. I was unknowingly running the Bun binary again.

The crashes immediately returned.

The auto-updater actively fights users who work around Bun crashes

• The updater downgraded me from v2.1.62 (npm) to v2.1.61 (Bun native)
• There is no way to disable auto-updates — the only valid values for autoUpdatesChannel are "latest" and "stable". There is no "disabled" or "none" option
• The user's deliberate runtime choice was silently overwritten with zero consent or notification

7 releases, zero Bun crash fixes

Releases v2.1.62 through v2.1.68 have shipped since this issue was filed. None of them contain any fix for Bun runtime crashes. What v2.1.63 did contain was 11 memory leak fixes — confirming the product shipped with massive memory management issues that were apparently known internally.

Meanwhile, v2.1.68 defaults Opus 4.6 to "medium effort" for Max/Team subscribers (throttling thinking depth) and force-removes Opus 4/4.1 model access without user consent. So resources are going to model gating and feature removal, not stability.

Three independent confirmations the Bun runtime is the crash source

1. 49 crashes on Bun binary over 33 days (documented in this thread)
2. Zero crashes on Node.js for 4+ consecutive days
3. Crashes return immediately when the auto-updater silently reinstalls the Bun binary

This is still sitting at zero Anthropic staff response after 35+ days and 49 documented crash reproductions. The auto-updater is now actively undermining the only workaround users have.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

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.