[BUG] Bun 1.3.14 panics 'Stack overflow' in JSC::preCommitStackMemory at startup when Windows system commit is exhausted (misreported OOM)

Environment

• Claude Code: 2.1.170 (native standalone install, claude.exe)
• Embedded Bun: v1.3.14 (521eedd6), Windows x64 (baseline)
• OS: Windows 11 Home, build 26200
• Hardware: 32 GB RAM, pagefile capped at 32 GB

What happened

Launching claude from a plain terminal crashed the embedded Bun runtime with a stack-overflow panic about 7 seconds into startup, before the REPL appeared:

============================================================            Remote Control active
Bun v1.3.14 (521eedd6) Windows x64 (baseline) · ← for agents
Windows v.win11_dt
CPU: sse42 avx avx2
Args: "claude"
Features: jsc standalone_executable claude_code
Elapsed: 7295ms | User: 46ms | Sys: 0ms
RSS: 47.91MB | Peak: 47.91MB | Commit: 0.18GB | Faults: 12377

panic(main thread): Stack overflow
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

https://bun.report/1.3.14/e_1521eeddkggggEggggCg0gu+By6/r+B27xt+Bq41rxBkxjoNm573Gwuq3G4qwp3DCYKERNEL32.DLLu10LCSntdll.dll4h+hBA7

Relaunching a few seconds later worked normally — same config, same directory.

Root cause (diagnosed)

The bun.report trace decodes to a failure in JavaScriptCore VM creation during startup bootstrap:

JSC::preCommitStackMemory          (VM.cpp:1158)
JSC::VM::updateStackLimits         (VM.cpp:1197)
JSC::VM::updateSoftReservedZoneSize (VM.cpp:1134)
JSC::VM::VM                        (VM.cpp:310)
JSC::VM::tryCreate                 (VM.cpp:670)
Zig__GlobalObject__create          (ZigGlobalObject.cpp:473)
bootStandalone                     (bun.js.zig:44)
start                              (cli.zig:610)
main                               (main.zig:71)

At crash time the machine's system commit charge was effectively exhausted: an unrelated leaking process held ~26.5 GB of commit (paged out, so RAM looked fine) and the pagefile had peaked at 30.1 GB of its 32 GB cap. When JSC tried to pre-commit the stack region for the new VM, VirtualAlloc(MEM_COMMIT) failed, and Bun surfaced that allocation failure as panic(main thread): Stack overflow.

This is consistent with the crash being transient: once the memory pressure cleared seconds later, the identical launch succeeded.

Why this is worth fixing

A failed stack pre-commit at VM creation is an out-of-memory condition, not a stack overflow. The current behavior:

• mislabels the error ("Stack overflow" sent users hunting for recursion/config bugs),
• presents it as "a bug in Bun, not your code", and
• asks the user to file a crash report for what is actually local commit-memory exhaustion.

A graceful startup error along the lines of failed to commit JS VM stack memory: insufficient system commit (close other applications or increase pagefile size) would turn a scary panic into a self-diagnosable condition.

Repro

1. Windows machine with commit charge near the limit (e.g., fixed-size pagefile nearly full; a large process holding mostly-paged-out commit reproduces this while RAM looks free).
2. Launch claude.
3. Bun panics with Stack overflow in JSC::preCommitStackMemory instead of reporting an allocation failure.