[Windows] N-API vtable corruption causes segfault, TUI escape, and orphaned processes in Bun v1.3.10

[ThatDragonOverThere]

Summary

Bun v1.3.10 (bundled with Claude Code / Anthropic CLI) has a critical N-API race condition on Windows that causes:

1. Segfaults at addresses 0x18, 0x7, 0x113, 0xFFFF (vtable corruption pattern)
2. TUI escape — terminal state machine dumps raw CSI focus reporting codes ([I[O[) and internal message buffers into the host shell as executable commands
3. Orphaned processes — crashed Bun processes stay alive, leak memory (1GB+ each), accumulate until system runs out of RAM
4. Full computer lockups — 5 hard reboots in 8 days from orphaned process memory exhaustion
5. Config file corruption — non-atomic writes during crash leave truncated JSON (280+ corruption events in one day)

Reproduction

• Application: Claude Code (Anthropic CLI), which bundles Bun v1.3.10
• Platform: Windows 11, x86_64 (MSYS2/Git Bash terminal)
• Trigger: Extended sessions (30min+) with sub-agent spawning (multiple concurrent Bun child processes). Also occurs in single-process sessions after ~4-5 hours.
• Frequency: 42 crashes in 33 days. 22+ crashes in a single day (Feb 25-26, 2026).

Steps to Reproduce

1. Run Claude Code on Windows with multiple concurrent sub-agent tasks
2. Wait 30-90 minutes
3. TUI escape occurs: [I[O[I[O[ dumped to terminal, session dies
4. Bun process stays alive with no window handle, consuming 400MB-1GB+ RAM
5. Repeat until system runs out of memory

Crash Variants Observed

• panic(main thread): Segmentation fault at address 0x18 — most common
• panic: switch on corrupt value — vtable corruption
• SIGILL — illegal instruction (less common)
• Silent TUI escape with no panic output (most frequent on Windows)

Root Cause Analysis

WinDbg analysis (posted on anthropics/claude-code#21875) points to N-API callback vtable corruption during concurrent TUI rendering + child process I/O. The crash site is in the N-API bridge between Bun's native runtime and the JavaScript TUI layer.

Community member @balandari identified the pattern: the vtable pointer is corrupted to point at an invalid address, causing the "switch on corrupt value" panic when the runtime tries to dispatch through it. This is consistent with a use-after-free or double-free in the N-API reference tracking.

Terminal State Corruption

When Bun crashes, it does NOT:

• Exit the alternate screen buffer
• Disable focus reporting (CSI ?1004l)
• Restore terminal raw mode to cooked mode
• Kill child processes / process group
• Clean up ConPTY handles (Windows)

This means:

• Focus reporting events ([I / [O) continue being sent to the dead terminal
• Internal message buffers get flushed to stdout as raw text
• On Windows, these strings are interpreted as PowerShell commands: The : The term 'The' is not recognized...
• The terminal remains corrupted until manually reset (stty sane / restart)

Orphaned Process Impact

After each crash, 1-3 Bun processes remain alive with:

• No window handle (headless)
• Increasing memory consumption (400MB → 1GB+ over 1-3 hours)
• Still receiving terminal focus events via the broken ConPTY

Kill log from our custom orphan killer script (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

Downstream Impact

• 42 crashes documented on CLI: Task execution escapes to PowerShell, becomes unresponsive anthropics/claude-code#21576
• 27 memory dumps + WinDbg analysis on Repeated Bun v1.3.5 segfaults -- 78 crashes, root cause identified (Windows + WSL) anthropics/claude-code#21875
• 90 unique affected users across 20+ issues on the Claude Code repo
• 280+ config file corruptions in one day from non-atomic writes during crash
• 5 full computer lockups (hard reboot required)
• 1 user's entire Windows profile deleted ([BUG] Claude Code v2.1.58 deleted entire Windows user profile (C:\Users\msafa) - CRITICAL DATA LOSS anthropics/claude-code#29023)
• Related upstream: Segmentation fault after long-running session (v1.3.9-canary.51) #26984

Environment

• Bun: v1.3.10 (bundled with Claude Code v2.1.50-v2.1.59, all crash)
• OS: Windows 11 (MSYS_NT-10.0-26200, x86_64)
• Terminal: Windows Terminal + Git Bash / MSYS2
• RAM: 32GB (orphaned processes exhaust this in 2-4 hours)
• Crash rate: ~1.3 per day average, up to 22 per day

Expected Behavior

• Bun should not segfault during normal N-API callback dispatch
• On crash, terminal state should be restored (alternate screen, focus reporting, raw mode)
• On crash, child processes should be killed (process group cleanup)
• File writes should be atomic (temp + rename) to prevent corruption on crash

Requested Fixes

1. N-API thread safety audit — the vtable corruption pattern suggests a concurrency issue in reference tracking
2. Crash cleanup handler — atexit/signal handler to restore terminal state and kill child processes
3. Process group management — child processes should die with parent on Windows (Job Objects)
4. ConPTY cleanup — proper handle lifecycle on crash

[github-actions]

Found 3 possible duplicate issues:

1. Segmentation fault at address 0x10 when running Claude Code standalone executable #26843
2. Segfault (null pointer at 0x0) in long-running standalone executable on Windows after sustained memory pressure #26862
3. Windows: Segmentation fault on Bun v1.3.0 when invoking global shim (claude, @anthropic-ai/claude-code) #23043

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

[ThatDragonOverThere]

Repro 43 just occurred while filing this bug report. TUI escape with [I[O[ codes, mid-task crash. 43 crashes in 33 days. This one killed a session that was implementing ML model changes — 3+ minutes of compute and context destroyed.

[ThatDragonOverThere]

Repros 45-48: Four simultaneous crashes (Feb 26)

User stepped away for one minute, returned to find 4 Claude Code windows had all crashed simultaneously with TUI escape codes ([I[O[). All were running sub-agent workloads.

48 total crashes in 33 days. 29 today alone. Mean time between failures during active multi-agent use is approximately 15-20 minutes.

Note: Anthropic just shipped Claude Code v2.1.61 with "Fixed concurrent writes corrupting config file on Windows" — addressing the downstream config corruption we documented. However, the upstream Bun N-API crash that triggers the corruption chain remains unfixed. The config fix is a bandaid on the symptom; the Bun crash is the disease.

The crash rate makes the product unusable for any task requiring more than 15 minutes of sustained compute on Windows.

[ThatDragonOverThere]

Repro 49: Confirmed on Claude Code v2.1.61 (Feb 26)

Anthropic shipped v2.1.61 with atomic config writes (fixing the downstream .claude.json corruption). The Bun crash is unchanged.

Same TUI escape pattern: [I[O[ CSI focus codes dumped to terminal, session killed mid-task. This confirms the crash is 100% in the Bun runtime, not in Anthropic's file handling code.

49 crashes in 33 days. 30 today. Now across 9 versions of Claude Code — all shipping Bun v1.3.10.

[ThatDragonOverThere]

Contesting duplicate closure. The suggested duplicates (#26843, #26862, #23043) do not cover this issue:

• Segmentation fault at address 0x10 when running Claude Code standalone executable #26843: macOS-specific segfault in JSC GC. Our issue is Windows N-API vtable corruption — different crash site, different platform, different root cause.
• Segfault (null pointer at 0x0) in long-running standalone executable on Windows after sustained memory pressure #26862: Generic "Bun crashes after a while." Our issue has 49 detailed reproductions, WinDbg memory dumps, N-API root cause analysis, orphan process kill logs, and terminal state corruption documentation.
• Windows: Segmentation fault on Bun v1.3.0 when invoking global shim (claude, @anthropic-ai/claude-code) #23043: Worker thread cleanup crash. Related but distinct — our crash is in the N-API callback dispatch during TUI rendering + child process I/O, not in worker cleanup.

This issue documents:

• 49 crashes in 33 days (30 today alone)
• 5 full computer lockups from orphaned Bun processes consuming all RAM
• 280+ config file corruptions from non-atomic writes during crash
• Orphan process kill logs showing individual Bun processes at 1GB+ RAM
• Terminal state machine corruption dumping internal buffers as shell commands
• WinDbg vtable corruption analysis
• 90 affected users across 20+ downstream issues

None of the suggested duplicates have this level of evidence or analysis. Please remove the duplicate label.

[ThatDragonOverThere]

Confirmed: Node.js = Stable, Bun = 49 Crashes

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

Same application (Claude Code v2.1.61), same workload, same Windows machine. Only variable changed: the runtime.

This conclusively isolates the crash to Bun's runtime — specifically the N-API bridge under concurrent workloads on Windows.

• Bun v1.3.10: 49 crashes in 33 days, 30 in one day, 5 computer lockups
• Node.js v22.12.0: 0 crashes overnight

The application code is identical. The runtime is the only difference.