[BUG] Repeated Bun panic "switch on corrupt value" on Windows 11 x64 during long sessions (v2.1.50 / Bun 1.3.10)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Description
Claude Code crashes with panic(main thread): switch on corrupt value during extended sessions. This has happened twice on the same machine, both times during sessions involving multiple subagent spawns (worktree orchestration with 5-7 parallel agents). The crash is non-deterministic — it occurs at different points in the session.
This appears related to #26763, #26590, #26531, #27086, and #27095. Filing separately to add another data point with full crash output and session context.
Environment
| Detail | Value |
|--------|-------|
| Claude Code version | 2.1.50 |
| Bun version | 1.3.10 (1423d3c8) |
| OS | Windows 11 Pro 10.0.26200 (x64) |
| CPU | x64 baseline (sse42, avx, avx2) |
| RAM | 33.78GB (reported by Bun — actual is 32GB) |
| Shell | Git Bash |
Session context at time of crash
| Metric | Value |
|--------|-------|
| Elapsed time | ~37 minutes (2,255,367ms) |
| Peak RSS | 1.56GB |
| Page faults | 7,700,941 |
| Session activity | Orchestrating 5-7 parallel worktree agents via Task tool |
Reproduction
Not deterministic, but both crashes shared these conditions:
- Windows 11 x64, Claude Code 2.1.50
- Session running 20-40 minutes
- Heavy use of
Tasktool withisolation: "worktree"spawning multiple parallel subagents (5-7 concurrent) - Each subagent performing file reads, writes, git operations, and bash commands
- High I/O churn — creating branches, editing files across worktrees, running linters
The crash has not occurred during simpler sessions (single-agent, no worktrees, shorter duration).
Expected behaviour
Session should remain stable regardless of duration or number of subagents.
Actual behaviour
Bun panics with switch on corrupt value after ~20-40 minutes of heavy multi-agent use. All unsaved session state is lost. Work in progress across worktrees is left in an inconsistent state (some branches created, some not merged).
Impact
- Session state is lost on crash (no auto-recovery)
- Worktree branches may be left in partial states requiring manual cleanup
- Forces users to limit session length and agent concurrency as a workaround
- Particularly impacts orchestration workflows that rely on parallel agents
Notes
- RAM is not exhausted at crash time (0.84GB RSS, 1.56GB peak, 33.78GB machine)
- Bun reports machine RAM as 33.78GB when actual is 32GB — possible GC threshold miscalculation (noted in oven-sh/bun#27099)
- The root cause appears to be in Bun's string deinitialization during event loop cleanup (
string.zig:885per oven-sh/bun#27099 stack trace) - Since Anthropic now owns Bun, this may be fixable in a future Claude Code release without waiting for an upstream Bun release
Potential Similar issues
- anthropics/claude-code#26763 — switch on corrupt value on Windows 10
- anthropics/claude-code#26590 — Recurring Bun crash on Windows
- anthropics/claude-code#26531 — Bun panic during Bash tool execution (v2.1.45)
- anthropics/claude-code#27086 — Bun panic during Explore agents on Windows 11
- anthropics/claude-code#27095 — BUN crash switch on corrupt value
- oven-sh/bun#27138 — switch on corrupt value, Claude Code on Windows x64
- oven-sh/bun#27099 — switch on corrupt value in string.zig (includes stack trace)
What Should Happen?
Runs without any errors.
Error Messages/Logs
### Crash output
Bun v1.3.10 (1423d3c8) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2
Args: "claude"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(286) fetch(1250) jsc spawn(310) standalone_executable process_dlopen(2) yaml_parse(35)
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:path/posix" "node:path/win32" "node:perf_hooks" "node:process" "node:stream" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:zlib" "node:worker_threads" "undici" "ws"
Elapsed: 2255367ms | User: 223093ms | Sys: 53968ms
RSS: 0.84GB | Peak: 1.56GB | Commit: 1.77GB | Faults: 7700941 | Machine: 33.78GB
panic(main thread): switch on corrupt value
oh no: Bun has crashed. This indicates a bug in Bun, not your code.Steps to Reproduce
Run Claude with worktree agents > 5 with run time longer than 30 mins.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
v2.1.50
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
_No response_
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.
What's happening: Bun 1.3.10 runtime memory corruption on Windows x64 triggered by sustained high-concurrency workloads. The 'switch on corrupt value' panic originates in Bun's internal tagged-union dispatch (likely the GC or event loop scheduler) when memory pressure from 5-7 parallel subagent processes causes heap corruption. The 7.7M page faults and 1.56GB RSS indicate extreme memory churn. This is a known Bun-on-Windows stability issue — the same panic signature appears in #26763, #26590, #26531, #27086, and #27095, all involving long sessions or heavy parallelism on Windows.
What worked for us:
This is a Bun runtime bug, not a Claude Code application bug. Mitigations: (1) Reduce parallel subagent count to 3-4 max on Windows to lower memory pressure, (2) Restart Claude Code sessions before they exceed ~30 minutes of heavy orchestration, (3) Monitor for Bun updates — this class of panic is actively tracked upstream. There is no application-level code fix since the corruption occurs inside Bun's native runtime layer.
Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞
---
<sub>🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.</sub>
Same root cause as #21875 (N-API race condition, Bun v1.3.10). See #21576 for 23 reproductions with full damage report (config corruption, computer lockups, lost trading data). Upstream: oven-sh/bun#26984.
Thanks for the precise root cause link, @ThatDragonOverThere. The N-API race condition in oven-sh/bun#26984 is a much more specific diagnosis than the generic "memory corruption under pressure" framing I used. And #21576 with 23 reproductions is a solid damage report — config corruption and lockups are far worse than just lost session state.
Updated our tracking to point to oven-sh/bun#26984 as the canonical upstream issue. Hopefully the impact on Windows users running parallel agents gets this prioritized.
Cross-Link: Another Manifestation of the Bun v1.3.10 Windows Crash Family
This 'switch on corrupt value' panic is another symptom of the same underlying Bun v1.3.10 instability on Windows documented in #21576 (26+ crashes in 30 days) and root-cause analyzed in #21875 (27 memory dumps, N-API race condition identified via WinDbg).
Same environment: Windows 11 Pro Build 26200, Bun v1.3.10. The different panic messages (segfault at 0x18, segfault at 0xFFFFFFFFFFFFFFFF, SIGILL, switch on corrupt value) are all different corruption outcomes from the same race condition. 4 full computer lockups requiring hard reboot.
v2.1.53 shipped 4 Windows crash fixes — none targeted the N-API race condition. Still crashing on v2.1.55.
Fixed in v2.1.53
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.