[BUG] Deterministic Bun startup segfault at USER32.dll+0xbe584 / address 0x3C on Windows 11 build 26200 (claude.exe 2.1.114+) — distinct from 0xFFFFFFFFFFFFFFFF family

### Preflight Checklist

• [x] I have searched existing issues and verified this is not a duplicate (see "Why this is not a duplicate" below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.126)

What's Wrong?

The bundled-Bun claude.exe distribution cannot run interactively on Windows 11 build 26200 due to a deterministic Bun startup crash at USER32.dll internal offset 0xbe584 (segfault address 0x3C). --version and --help succeed (they exit before the crashing init). Everything else — doctor, -p, the interactive REPL — segfaults at startup, every time, 100% reproducible.

This is not the same bug as the 0xFFFFFFFFFFFFFFFF/N-API/use-after-free family (oven-sh/bun #27003, #25630, #21469, etc.). Those are race conditions / long-session crashes / ~50% probabilistic. This is a deterministic startup segfault at a different address (0x3C, not 0xFFFFFFFFFFFFFFFF) with a different stack frame (USER32 internal at +0xbe584). Filing fresh per #25630's auto-stale-closure (locked Mar 22) since the affected user community has no fix path.

What Should Happen?

claude doctor and the interactive REPL should run, like they do on the npm-distributed pure-Node version (2.1.110 and earlier).

Error Messages/Logs

============================================================
Bun v1.3.14 (0a466a11) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2
Args: "C:\Users\<user>\AppData\Local\Microsoft\WinGet\Packages\Anthropic.ClaudeCode_Microsoft.Winget.Source_8wekyb3d8bbwe\claude.exe"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) fetch(12) jsc spawn(17) standalone_executable yaml_parse(2) claude_code
Builtins: ...
Elapsed: 1237ms | User: 562ms | Sys: 203ms
RSS: 0.51GB | Peak: 0.51GB | Commit: 0.70GB | Faults: 133353

panic(thread 5944): Segmentation fault at address 0x3C
oh no: Bun has crashed.

https://bun.report/1.3.14/e_10a466a1mgggkEugogCCYnpggNT64.desy2TCYnpggNT64.desynouE__CYnpggNT64.desws0PCUUSER32.dllo4yvBCYnpggNT64.desgi6RCYnpggNT64.desg76D___CYnpggNT64.desoqmWA2A4D

Decoded stack (from bun.report):

Segmentation fault at address 0x0000003C
- ??? at 0x2769     in npggNT64.des
- ??? at 0x239079   in npggNT64.des
- *2 unknown/js code*
- ??? at 0x3e8c8    in npggNT64.des
- ??? at 0xbe584    in USER32.dll       <-- CRASHING CALL
- ??? at 0x47420    in npggNT64.des
- ??? at 0xf5b0     in npggNT64.des
- *3 unknown/js code*
- ??? at 0x58ca4    in npggNT64.des

The 0xbe584 offset in user32.dll (build 10.0.26100.8117 / Win11 26200) does not correspond to any exported function — the closest export is gapfnScSendMessage at RVA 0xaa440, 82,244 bytes earlier. So the crash is in an internal USER32 function, likely message-dispatch / window-class / DPI machinery, called transitively from Bun's startup.

Identical stack signature also crashes vanilla bun upgrade --canary (see oven-sh/bun #24257, which the original reporter closed without a fix in Oct 2025; same 0xbe584 USER32 frame).

Steps to Reproduce

# Win11 26200, x64
winget install Anthropic.ClaudeCode    # Or: npm install -g @anthropic-ai/claude-code@2.1.126
claude doctor                           # Crashes immediately, every time

Claude Model

Opus 4.7

Is this a regression?

Yes, demonstrable bisect across npm tarballs. The cutover is between 2.1.110 and 2.1.114:

| Version | Distribution | Win11 26200 status |
|---------------|--------------------------|-------------------------------------|
| 2.1.110 | Pure-Node cli.js (17.8 MB) | Works fully — REPL, doctor, -p |
| 2.1.111-113 | (Not on registry) | — |
| 2.1.114+ | cli-wrapper.cjs + 249 MB bin/claude.exe Bun standalone | Segfaults at startup |

Confirmed by npm pack --dry-run of every version: package/cli.js exists in 2.1.110, replaced by bin/claude.exe in 2.1.114+.

Last Working Version

@anthropic-ai/claude-code@2.1.110 (pure-Node distribution).

Claude Code Version

2.1.126 (latest; same crash on 2.1.118, 2.1.121, 2.1.123)

Platform

Anthropic API (Claude Max)

Operating System

Windows 11 build 26200, x64

Terminal/Shell

PowerShell 5.1, Cursor's integrated terminal, also reproduces in cmd.exe and Windows Terminal.

Additional Information

Why this is not a duplicate

| Issue | Crash address | Trigger | Determinism | This issue |
|-------------------------------------------------------|------------------------------|----------------------|------------------|---------------------|
| #25630 | 0xFFFFFFFFFFFFFFFF | Random startup | ~50% probabilistic | 0x3C deterministic |
| #21469 | 0xFFFFFFFFFFFFFFFF/E | Long session | After 5min–2.5hr | Immediate startup |
| #27320 | Pipe write | Long session | Eventual | Immediate startup |
| oven-sh/bun #27003 | N-API cleanup race | Heavy spawn loops | After hours | Pure-startup |
| oven-sh/bun #24257 | 0x3C + 0xbe584 USER32 | bun upgrade | Deterministic | Same signature |

The closest match is oven-sh/bun #24257 — same exact crash signature on bun upgrade --canary (closed by reporter without a fix in Oct 2025). Strongly suggests this is a vanilla Bun Windows-startup bug, not an Anthropic-specific one, that was never actually triaged.

Verification: I rebuilt the binary using vanilla Bun 1.3.13 and it still crashes

Reverse-engineered Bun's standalone format from oven-sh/bun/src/StandaloneModuleGraph.zig:

[ Bun runtime PE ] + [ .bun PE section: 134 MB module graph ] + [ Offsets struct (32 bytes) + "\n---- Bun! ----\n" trailer ]

Built a hybrid claude-fixed.exe by extracting Anthropic's .bun PE section (file offset 0x722AC00, raw size 134,329,856 bytes) from bin/claude.exe and grafting it onto vanilla Bun 1.3.13's PE (with section header VirtualSize/SizeOfRawData and Optional Header SizeOfImage updated). The hybrid runs (--version returns "2.1.126 (Claude Code)") — and crashes with the identical USER32+0x3C signature on doctor / -p / interactive. So the bug is in vanilla Bun, not Anthropic's claude_code feature flag (which actually appears to have partial mitigations: Anthropic's claude.exe survives --bare -p with stdin pipe, while the vanilla-Bun hybrid crashes even on that).

Compatibility / install paths tested (all crash identically)

• winget install Anthropic.ClaudeCode — Bun 1.3.14 canary baseline
• npm install -g @anthropic-ai/claude-code@2.1.126 — same bin/claude.exe
• npm install -g @anthropic-ai/claude-code@2.1.118 — Bun 1.3.13 release baseline (same crash)
• Hybrid (vanilla Bun 1.3.13 modern + Anthropic .bun section) — same crash + worse
• claude --bare doctor — still crashes (so --bare doesn't disable the offending init)

The only operational mode that works on Anthropic's binary is claude --bare -p with piped stdin — which loses the REPL, hooks, plugins, LSP, and OAuth (--bare requires ANTHROPIC_API_KEY). Not a usable workaround for Claude Max users.

What does work for Win11 26200 users today

npm install -g @anthropic-ai/claude-code@2.1.110
# DISABLE_AUTOUPDATER=1 + autoUpdates:false in settings.json so it stays put

But this requires users to know that 2.1.110 is the last pure-Node version, and Anthropic's docs/installer don't surface this anywhere.

Asks

1. Triage independently from the 0xFFFFFFFFFFFFFFFF/N-API issues — this is a different crash address with a different stack and a different determinism profile. Don't auto-stale-close it as a duplicate of #25630.
2. Cross-reference oven-sh/bun #24257 with the Bun team — same USER32+0x3C signature, different trigger, almost certainly the same root cause in Bun's Windows console/window init path.
3. Ship a 2.1.x release that targets a Bun version with this fixed, or reinstate the pure-Node distribution channel as an officially-supported install path for Windows users until the Bun bug is resolved. Right now the only working path is undocumented and self-discovered.
4. Surface the install-via-pure-Node fallback in the installer error path, so the next person to hit this Bun panic gets pointed at a working version instead of a stack trace.