Bun segfault crash after extended session

Immediately after posting this I experienced the crash evoking Claude without --dangerously-skip-permissions

Same issue here — macOS (Apple Silicon)

Experiencing frequent crashes/disconnections on macOS Darwin 25.2.0 (arm64).

Environment

• Claude Code version: Latest (Opus 4.5)
• OS: macOS 15.x (Apple Silicon, M-series)
• Terminal: iTerm2
• Shell: zsh

Investigation Summary

We spent significant time investigating this. Here's what we ruled out:

| Suspected Cause | Result |
|-----------------|--------|
| --dangerously-skip-permissions flag | ❌ Crashes with AND without it |
| Custom hooks (PreToolUse, PostToolUse, SessionStart) | ❌ Crashes with hooks completely removed |
| statusLine (custom command) | ❌ Crashes with statusLine completely removed |
| Bare minimum config (no hooks, no statusLine, no custom anything) | ❌ Still crashes |

Confirmed Separate Issue (tty race condition)

We did find and fix ONE crash trigger: writing escape sequences to tty during TUI rendering (e.g., printf '\e]0;title\a' > /dev/tty from a background process). This causes 100% reproducible instant crash. But even after fixing this, random crashes continue.

Crash Pattern

• Happens after extended sessions (10-30+ minutes of active use)
• More frequent during heavy tool usage (multiple Bash calls, large outputs)
• No specific tool or action consistently triggers it
• Session just silently dies — no error output visible

Conclusion

This appears to be an internal runtime issue (Bun segfault as described in this issue), not caused by any user configuration. The memory leak / RSS tracking bug mentioned here aligns with our observations.

Would appreciate any updates on this. 🙏

Is this related? Now let me check the pipeline to make sure the local classifier results will be accepted.

──────────────────────────────────────────────────────────────────
-- INSERT -- ⏵⏵ bypass permissions on (shift+tab to cycle) Context left until auto-compact: 2%
============================================================
Bun v1.3.5 (1e86cebd) Linux x64 (baseline)
Linux Kernel v6.17.10 | glibc v2.42
CPU: sse42 popcnt avx avx2
Args: "claude" "--continue" "--chrome" "--dangerously-skip-permissions"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(246) fetch(336) jsc spawn(339) standalone_executable process_dlopen
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:querystring" "node:stream" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:zlib" "node:worker_threads" "undici" "ws" "node-fetch" "node:http2"
Elapsed: 1436015ms | User: 214656ms | Sys: 23567ms
RSS: 0.02ZB | Peak: 1.18GB | Commit: 0.02ZB | Faults: 11 | Machine: 67.18GB

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

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

https://bun.report/1.3.5/B_11e86cebmgEuhogCk0iruE+syP______________0rsk/Dqli3jFstpglEyjgy/CA2ij8Bgi/9sL

fish: Job 1, 'claude --continue --chrome --da…' terminated by signal SIGILL (Illegal instruction)

Update: Bun Issue Filed

I've filed this crash upstream to the Bun repository: https://github.com/oven-sh/bun/issues/26984

New Data Point: macOS Silicon (Feb 2026)

Adding another confirmed case to the pattern:

• Platform: macOS Darwin 26.2 (Apple Silicon)
• Bun Version: v1.3.9-canary.51 (d5628db2) ← Newer canary, still crashes
• Session Duration: Long-running (extended session)
• RSS Corruption: 0.02ZB ✓ (same as all other reports)
• Segfault Address: 0x30 (null pointer dereference)
• Corrupted Stats: Elapsed: 215683236ms (~2494 days)

Pattern Confirmation

This is 100% consistent with the pattern documented here:

• ✓ Extended session crash (10-30+ minutes)
• ✓ RSS showing 0.02ZB
• ✓ Multiple platforms affected
• ✓ Not configuration-dependent
• ✓ Bun v1.3.5 → v1.3.9-canary.51 (persists across versions)

The Bun team now has visibility via issue #26984. This is clearly an upstream runtime bug in Bun's standalone executable implementation.

Only a 10m run...
✻ Nesting… (10m 17s · ↓ 16.5k tokens · thinking)

============================================================
Bun Canary v1.3.9-canary.62 (6d2fefba) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2 avx512
Args: "claude" "--dangerously-skip-permissions"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(127) fetch(481) jsc spawn(367) standalone_executable process_dlopen yaml_parse(92)
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" "node:http2"
Elapsed: 6479382ms | User: 102500ms | Sys: 20093ms
RSS: 0.95GB | Peak: 1.51GB | Commit: 1.53GB | Faults: 2536281 | Machine: 0.21TB

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

Same issue on WSL2 + i9-13900K, Claude Code 2.1.45 (Bun 1.3.10-canary.63)

dmesg reveals these are invalid opcode traps, not random segfaults — same instruction pointer every time:

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

traps: claude[14647] trap invalid opcode ip:3050304 sp:7ffdbf230940 error:0 in 2.1.45[2aef000+3926000]
traps: claude[44890] trap invalid opcode ip:3050304 sp:7ffcfc448ac0 error:0 in 2.1.45[2aef000+3926000]
traps: claude[218109] trap invalid opcode ip:3050304 sp:7ffe034953c0 error:0 in 2.1.45[2aef000+3926000]
traps: JITWorker[218424] trap invalid opcode ip:3050304 sp:7e0d94435400 error:0 in 2.1.45[2aef000+3926000]
traps: claude[219853] trap invalid opcode ip:3050304 sp:7fffd5d76480 error:0 in 2.1.45[2aef000+3926000]
traps: claude[220183] trap invalid opcode ip:3050304 sp:7fffd5fc7100 error:0 in 2.1.45[2aef000+3926000]
traps: claude[221590] trap invalid opcode ip:3050304 sp:7ffd3fd20dc0 error:0 in 2.1.45[2aef000+3926000]
traps: claude[224263] trap invalid opcode ip:3050304 sp:7fff7ee1a540 error:0 in 2.1.45[2aef000+3926000]
traps: claude[224525] trap invalid opcode ip:3050304 sp:7fff8cbc1b40 error:0 in 2.1.45[2aef000+3926000]
traps: claude[290203] trap invalid opcode ip:3050304 sp:7fff9220a8c0 error:0 in 2.1.45[2aef000+3926000]

Environment:

• Claude Code 2.1.45 (native install)
• Bun v1.3.10-canary.63 (bundled)
• WSL2, Ubuntu 24.04, Kernel 6.6.87.2-microsoft-standard-WSL2
• CPU: Intel i9-13900K (flags: sse42 popcnt avx avx2, no avx512)
• RAM: 32GB, plenty free at time of crash

Reproduction: Happens on extended sessions and when resuming with (or without) --resume. Crashes are 100% reproducible over time — not sporadic.

Reproduces on Claude Code 2.1.50 (Bun v1.3.10) — Linux x64, ~3.4h session

Environment:

• Claude Code: 2.1.50
• Bun: 1.3.10 (1423d3c8)
• OS: Linux x64, glibc v2.39
• Kernel: 6.17.0
• CPU: sse42 popcnt avx avx2

Crash output:

Bun v1.3.10 (1423d3c8) Linux x64 (baseline)
Linux Kernel v6.17.0 | glibc v2.39
CPU: sse42 popcnt avx avx2
Args: "claude" "--dangerously-skip-permissions"
Elapsed: 12152163ms | User: 434539ms | Sys: 156933ms
RSS: 0.02ZB | Peak: 1.08GB | Commit: 0.02ZB | Faults: 20558 | Machine: 33.57GB

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

Bun crash report: https://bun.report/1.3.10/B_11423d3cmgkgEuhogC4oi5wE+ypRslpuiEslpuiEslpuiEslpuiEslpuiE____________m8q7hEA24//B3l9rj/B

Notable: RSS: 0.02ZB is clearly a garbage value (should be ~1GB), consistent with memory corruption after a long run. Session ran for ~3.4 hours before crashing. Same --dangerously-skip-permissions flag as other reports.

Also seeing this on v2.1.50 with the bundled Bun v1.3.10.

I only started a session and then stepped away for about 20 minutes. I hadn't even run any commands yet, but the session had already crashed when I got back. Seems like it's hitting this even when idle.

============================================================  
Bun v1.3.10 (1423d3c8) Linux x64 (baseline)  
Linux Kernel v6.17.0 | glibc v2.42  
CPU: sse42 popcnt avx avx2 avx512  
Args: "claude"  
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) fetch(8) jsc spawn(16) standalone_executable process_dlopen(2) yaml_parse(29)  
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: 1224796ms | User: 32786ms | Sys: 15719ms
RSS: 1.13GB | Peak: 0.41GB | Commit: 1.13GB | Faults: 0 | Machine: 32.83GB

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

Bun crash report:
https://bun.report/1.3.10/B_11423d3cmgEugogC4oi5wE+1vRslpuiEslpuiEslpuiEslpuiEslpuiEslpuiE____________A24//B36q/1zB

Cross-Platform Damage Escalation (Feb 24, 2026)

Linking this cross-platform Bun segfault tracker to the Windows-specific damage report:

On Windows (#21576), the Bun crash has escalated far beyond segfaults:

• 23 reproductions in 29 days
• Orphaned Bun processes from TUI escapes accumulate and exhaust system memory
• 2 full computer lockups, Microsoft Defender crashed, DNS policy table corrupted
• Config file (.claude.json) corrupted by mid-write truncation
• Lost live trading data during market hours

Root cause confirmed by @balandari on #21875: N-API race condition (double-free). 27 memory dumps analyzed. Upstream filed at oven-sh/bun#26984.

For macOS/Linux users here: Are you seeing orphaned processes after crashes? On Windows they accumulate silently and eventually brick the machine.

high-priority + oncall labels on #21875. Zero Anthropic comments anywhere. v2.1.52 shipped today with a VS Code fix.

Windows Data Point: 4 Full System Lockups from Bun Crashes

Cross-posting from #21576: 26+ Bun crashes in 30 days on Windows, 4 requiring hard reboot (entire system frozen). Crash address 0x18 (null pointer deref), orphaned Bun processes exhaust system resources. Damage includes config file corruption, DNS corruption, and lost data.

v2.1.53's 4 Windows crash fixes did not address the root cause (N-API race condition in Bun v1.3.10). Root cause analysis with 27 memory dumps on #21875 — still zero staff response after 30+ days with high-priority + oncall labels.

Another data point — same segfault on macOS Silicon after a ~14-hour session.

Bun v1.3.10 (d885ce7f) macOS Silicon
macOS v26.4
Elapsed: 51977907ms | User: 299231ms | Sys: 33790ms
RSS: 0.24GB | Peak: 0.53GB | Commit: 0.02ZB | Faults: 8913 | Machine: 17.18GB

panic(main thread): Segmentation fault at address 0x20006500680074

Bun crash report: https://bun.report/1.3.10/M_1d885ce7mgkgE+hogD_uiu3uB25r2Tmp9mRmqxid+9vtnB20w8Cu1z8C2mk+C__u78++Cu/l1qCu1j1qC+2qxqCm8p+uCuv8/B__u78++CA2qmggEonggN

Same 0.02ZB Commit value as OP. Session involved normal interactive usage (tool calls, file reads/writes, shell commands) over an extended period.

New data point: Bun v1.3.11, Windows x64, ~4-day session, non-main-thread crash

Confirms this bug persists in Bun v1.3.11 (latest bundled version, newer than any previous report in this thread).

Environment

• Bun: v1.3.11 (a2743b6d)
• OS: Windows 11 Home (10.0.26200), x64 (baseline)
• CPU: sse42 avx avx2
• Machine RAM: 16.86GB

Crash Details

Bun v1.3.11 (a2743b6d) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2
Args: "C:\Users\Duane\.local\bin\claude.exe" "--dangerously-skip-permissions"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) WebSocket(100) abort_signal(25) fetch(818) jsc spawn(420) standalone_executable process_dlopen(2) yaml_parse(2)
Elapsed: 343010811ms | User: 640968ms | Sys: 71656ms
RSS: 0.62GB | Peak: 1.50GB | Commit: 7.95GB | Faults: 7862636 | Machine: 16.86GB

panic(thread 41212): Segmentation fault at address 0x3E272010000

Bun crash report: https://bun.report/1.3.11/e_1a2743b6mgkgE+hogCgs2hyCmj2hyCm/0hyCs6xhyCwsho3BimhoGikx1do++sf0y5wMmvw9U8839Uotqx1B8ll11Biw2n4Bqixj4B68uj4Bu754W4glvRCYKERNEL32.DLLut0LCSntdll.dll4oijBA2k+BgggkgyD

Notable differences from prior reports

| Detail | This crash | Most prior reports |
|--------|-----------|-------------------|
| Bun version | v1.3.11 (latest) | v1.3.5 – v1.3.10 |
| Crash thread | thread 41212 (worker) | main thread |
| Session duration | ~343,011s (~3.97 days) | Minutes to hours |
| Commit memory | 7.95GB (on 16.86GB machine) | Usually < 2GB |
| Page faults | 7,862,636 | Varies |
| RSS corruption | No (0.62GB looks valid) | Common (0.02ZB) |

Analysis

• The crash occurred on thread 41212 (a worker thread), not the main thread — different from most reports here.
• ~4 days of uptime with 818 fetch calls, 420 spawned processes, and 100 WebSocket connections shows heavy sustained usage.
• Commit memory (7.95GB) is nearly half of machine RAM (16.86GB), suggesting significant virtual memory pressure / fragmentation over the multi-day session.
• RSS (0.62GB) is not corrupted in this case (unlike the 0.02ZB values seen in many other reports), suggesting a different corruption path.

Cross-ref: Windows-specific root cause analysis in #21875.

Still hitting this on the latest standalone release.

Environment:

• Claude Code: 2.1.92 (standalone binary)
• Bun: v1.3.11
• OS: Fedora 43, kernel 6.19.10
• glibc: 2.42
• CPU: x86_64 with AVX-512

Crash output:

Bun v1.3.11 (6f0a17c3) Linux x64 (baseline)
Linux Kernel v6.19.10 | glibc v2.42
CPU: sse42 popcnt avx avx2 avx512
Elapsed: 2388806ms | User: 156901ms | Sys: 72547ms
RSS: 1.06GB | Peak: 0.49GB | Commit: 1.06GB | Faults: 85 | Machine: 65.97GB

panic(main thread): Segmentation fault at address 0x0

Crash report: https://bun.report/1.3.11/B_16f0a17cmgggEuhogC4ovilF+oxGg0tw4FutmgyEk6nz2E03p0nDk9q5iE0ns10E__2i1hvE2i1hvE2i1hvE2i1hvE_2i1hvE_2i1hvE2i1hvE_A2AAIllegal

Session ran ~40 minutes before crashing. RSS reached 1.06GB (peak was only 0.49GB, so the growth happened late).

Environment

VPS: Debian, Linux x64
CPU: sse42 popcnt avx avx2
RAM: 12 GB
Claude Code: 2.1.96 (native installer)
Bun: 1.3.11

What happened

Claude Code ran for ~3.5 hours, Bun had a memory leak (RSS reported as 0.02ZB)
Bun crashed with Segmentation fault, saturating all system resources (fork: Resource temporarily unavailable)
After VPS reboot, the native binary crashes immediately with "Illegal instruction"
Reinstalling via install.sh also fails with "Out of memory"
Bun 1.3.11 installed separately works fine (bun --version responds)
Workaround: npm install works

Crash log

Bun v1.3.11 (6f0a17c3) Linux x64 (baseline)
panic(main thread): Illegal instruction at address 0x48363A4

Expected behavior

Native installer should recover/reinstall cleanly after a Bun crash.

New data point: macOS Apple Silicon + tmux multi-worker session (May 2026)

Scenario: Claude Code orchestrator pane dispatching tasks to 6 worker panes via tmux send-keys. After ~3 minutes of parallel processing, Claude Code crashed with a Bun segfault.

Error:

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

Crash report: https://bun.report/1.3.14/M_1d298914mgkgkEuhooC_mhu5yC2lu3yC+2t3yCurs3yCu2826C+jvx5C__________A2AohB

Environment:

• Claude Code version: 0.2.1.141 (Desktop)
• Bun: 1.3.14
• macOS: 26.3.1 (Apple Silicon)
• Context at crash: ~12.3k tokens

Notes:

• Reproducible with concurrent tmux worker sessions (heavy parallel tool usage)
• Consistent with the extended session + heavy tool usage pattern described in this issue

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