[BUG] Bun 1.3.14 JSC GC segfault (SlotVisitor::drain) on AMD Ryzen 5 5500 / Linux x86_64_baseline — all platform binaries identical

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27497
2. https://github.com/anthropics/claude-code/issues/52614
3. https://github.com/anthropics/claude-code/issues/22632

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

This is NOT a duplicate. Previous issues were closed as stale
without being fixed. This report adds critical new findings
not present in any prior issue:

1. Reproduced on Bun 1.3.14 (prior issues were 1.3.10/1.3.13)
2. All platform packages ship IDENTICAL binaries (BuildID:

1c6448151b04aed46579bf7429d8704f6f2be83d) — no workaround
possible via platform package selection

1. Reproduced on kernel 6.17.0-23-generic specifically
2. Crash is deterministic at LOW context (under 30K tokens),

not just long sessions

1. Auto-updater destabilizes live sessions by swapping symlink

mid-session

Closing this as a duplicate of issues that were never fixed
and are now locked is not acceptable. This bug is actively
blocking paying Claude Max subscribers from using CC on Linux.

👎 auto-closure

Checking behavior this morning and it lasted 34 seconds before crashing. ▐▛███▜▌ Claude Code v2.1.133
▝▜█████▛▘ Sonnet 4.6 · Claude Max
▘▘ ▝▝ ~/workspace

❯ /context ⎿ Context Usage
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ Sonnet 4.6
⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ claude-sonnet-4-6
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ 18.4k/200k tokens (9%) ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Estimated usage by category ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System prompt: 6.3k tokens (3.1%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System tools: 9.7k tokens (4.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Memory files: 1.7k tokens (0.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Skills: 721 tokens (0.4%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀ ⛁ Messages: 8 tokens (0.0%)
⛁ Compact buffer: 3k tokens (1.5%)
⛶ Free space: 178.6k (89.3%)

MCP tools · /mcp (loaded on-demand)

Available
├ mcp__claude_ai_Gmail__create_draft
├ mcp__claude_ai_Gmail__create_label
├ mcp__claude_ai_Gmail__delete_label
├ mcp__claude_ai_Gmail__get_thread
├ mcp__claude_ai_Gmail__label_message
├ mcp__claude_ai_Gmail__label_thread
├ mcp__claude_ai_Gmail__list_drafts
├ mcp__claude_ai_Gmail__list_labels
├ mcp__claude_ai_Gmail__search_threads
├ mcp__claude_ai_Gmail__unlabel_message
▐▛███▜▌ Claude Code v2.1.133
▝▜█████▛▘ Sonnet 4.6 · Claude Max
▘▘ ▝▝ ~/workspace

❯ /context
⎿ Context Usage
⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ Sonnet 4.6
⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ claude-sonnet-4-6
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ 18.4k/200k tokens (9%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ Estimated usage by category
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System prompt: 6.3k tokens (3.1%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ System tools: 9.7k tokens (4.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Memory files: 1.7k tokens (0.8%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ Skills: 721 tokens (0.4%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀ ⛁ Messages: 8 tokens (0.0%)
⛁ Compact buffer: 3k tokens (1.5%)
⛶ Free space: 178.6k (89.3%)

MCP tools · /mcp (loaded on-demand)

Available
├ mcp__claude_ai_Gmail__create_draft
├ mcp__claude_ai_Gmail__create_label
├ mcp__claude_ai_Gmail__delete_label
├ mcp__claude_ai_Gmail__get_thread
├ mcp__claude_ai_Gmail__label_message
├ mcp__claude_ai_Gmail__label_thread
├ mcp__claude_ai_Gmail__list_drafts
├ mcp__claude_ai_Gmail__list_labels
├ mcp__claude_ai_Gmail__search_threads
├ mcp__claude_ai_Gmail__unlabel_message
├ mcp__claude_ai_Gmail__unlabel_thread
├ mcp__claude_ai_Gmail__update_label
├ mcp__claude_ai_Google_Calendar__create_event
├ mcp__claude_ai_Google_Calendar__delete_event
├ mcp__claude_ai_Google_Calendar__get_event
├ mcp__claude_ai_Google_Calendar__list_calendars
├ mcp__claude_ai_Google_Calendar__list_events
├ mcp__claude_ai_Google_Calendar__respond_to_event
├ mcp__claude_ai_Google_Calendar__suggest_time
├ mcp__claude_ai_Google_Calendar__update_event
├ mcp__claude_ai_Google_Drive__copy_file
├ mcp__claude_ai_Google_Drive__create_file
├ mcp__claude_ai_Google_Drive__download_file_content
├ mcp__claude_ai_Google_Drive__get_file_metadata
├ mcp__claude_ai_Google_Drive__get_file_permissions
├ mcp__claude_ai_Google_Drive__list_recent_files
├ mcp__claude_ai_Google_Drive__read_file_content
└ mcp__claude_ai_Google_Drive__search_files

Memory files · /memory
└ CLAUDE.md: 1.7k tokens

Skills · /skills

❯ give me the last task you remember doing?
✢ Spinning…
⎿  Tip: Share Claude Code and earn $10 of extra usage · /passes

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ ============================================================
Bun v1.3.14 (050219c1) Linux x64 (baseline)──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Linux Kernel v6.17.0 | glibc v2.39tab to cycle) · esc to interrupt
CPU: sse42 popcnt avx avx2
Args: "claude" "--dangerously-skip-permissions"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(14) fetch(74) jsc spawn(10) standalone_executable yaml_parse claude_code
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:dns" "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:readline" "node:stream" "node:stream/consumers" "node:stream/promises" "node:string_decoder" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:vm" "node:zlib" "ws" "node:http2"
Elapsed: 34103ms | User: 2741ms | Sys: 756ms
RSS: 75.04MB | Peak: 0.34GB | Commit: 75.04MB | Faults: 0 | Machine: 33.51GB

panic: Segmentation fault at address 0x20
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.14/B_1050219cmgggkEuhogC4koo4E+ypR48u/4EsvsyqF2zqyqF4ryyqF+j+jqF89kuqFmrpuqFkiwo4EmqlnB2muqCA2AgC

Illegal instruction (core dumped)

Update: tested 2.1.138
New BuildID confirmed: 1bfa5e34 (previously 1c6448151b04aed46579bf7429d8704f6f2be83d). A different Bun binary shipped with this version.
Still crashing. Same panic family, different address:
Bun v1.3.14 (1bfa5e34) Linux x64 (baseline)
panic(main thread): Segmentation fault at address 0x6C
Illegal instruction (core dumped)
Crash report: https://bun.report/1.3.14/B_11bfa5e3mgggkEuhogC4kpo4E+ypRk7r75Euwxi6E2zni6Eknvi6E2ttj5E08miqF06ihqF4j0nqF6r7vqFyhznqF6p9xnE+3nh0Cgp/g1CwkkqxCm232tEsny4wCyk/qpC6zzqpCA2A4G
Notably: elapsed time before crash was 412 seconds, up from ~34 seconds on the previous binary. The crash occurred while the user was typing, with no inference load active. This suggests the GC bug fires on a background sweep or heartbeat, not under inference pressure.
Hardware: x86_64 baseline, Linux 6.17.0, RTX 3060 12GB, 33GB RAM.

Found a workaround that's held up for me. Setting BUN_JSC_numberOfGCMarkers=1 before launching CC appears to sidestep the parallel GC race entirely.
I wrapped it in a shell function in .bashrc so it fires automatically:
bashclaude() {
BUN_JSC_numberOfGCMarkers=1 command claude --dangerously-skip-permissions "$@"
}
Tested two concurrent instances this morning, one sitting completely idle and one actively running tasks. Both survived 60+ minutes without a crash. Without the flag I was getting segfaults in under 7 minutes consistently across 2.1.133, 2.1.136, 2.1.137, and 2.1.138.
No idea if this is officially supported or if it has other side effects, but it's the difference between CC being unusable and being able to actually work. Hope it helps someone while we wait on a real fix.

Follow-up to my earlier comment. The workaround helps but doesn't fully fix it.
After about 11.5 minutes (688 seconds) under actual workload, it crashed again at a different address: 0x4 instead of 0xD0. A concurrent idle instance also died around the same time.
New crash report: https://bun.report/1.3.14/B_11bfa5e3mgggkEuhogC4kpo4E+ypR08miqF06ihqF4j0nqF6r7vqFyhznqF6p9xnE+3nh0Cgp/g1CwkkqxCm232tEsny4wCyk/qpC6zzqpCy8wK0oxK6ixqpCA2AI
So the picture is: BUN_JSC_numberOfGCMarkers=1 appears to suppress one race path but there's at least one other. The flag buys meaningful time (34-412s without it, 688s with it under load) but it's not a fix. Updating my earlier comment accordingly so nobody burns time thinking this is solved.
Still keeping the flag in place since longer-lived sessions are better than nothing, but wanted to correct the record.

Second update. The mitigation is working but not complete.
Added BUN_JSC_useParallelMarkingConstraintSolver=false alongside BUN_JSC_numberOfGCMarkers=1. Session survived 2708 seconds (45 minutes) under real workload: active file reads, Postgres writes, ~85k tokens of context. Previous best with single flag was 688 seconds. Baseline without flags was 34-412 seconds.
New crash address: 0xFFFFFFFFFFFFFFAD (signed: -83). Third distinct address across all crashes.
Crash report: https://bun.report/1.3.14/B_11bfa5e3mgggkEuhogC4kpo4E+ypR2j3j0F+g2j0Fsg8o0F0rtyqFqxryqF4rzyqFsn0hqFg4ihqF4j0nqF6r7vqFyhznqF6q4nqF69yw/DonuuyFis6/iE2otp/Ek9us2F_A2DnF
Pattern across all three crashes:

No flags: 0xD0, crashes in under 7 minutes
numberOfGCMarkers=1: 0x4, crashes at ~688 seconds
numberOfGCMarkers=1 + useParallelMarkingConstraintSolver=false: 0xFFFFFFFFFFFFFFAD, crashes at ~2708 seconds

Each flag appears to suppress one race path and expose another. The bug isn't in a single location. Next test will be BUN_JSC_useConcurrentGC=false to disable the concurrent GC pipeline entirely. Will report back.

👎Update:
Added ClientAliveInterval 60 / ClientAliveCountMax 10 / TCPKeepAlive yes to Oberon's /etc/ssh/sshd_config last night. This morning I ran a single CC session from 6:53 AM to 9:58 AM CDT — 175 minutes, four discrete work sessions with /clear between them — before it finally crashed while writing an end-of-session log. Not mid-task. Cleanup.
For context: previous best with JSC flags alone was ~45 minutes in a fresh SSH session. As low as 59 seconds in a session that had been running all day through multiple crashes and failed operations.
My read: the GC race in Bun 1.3.14 is real, but degraded SSH pipe state was the primary accelerant. When stdout/stderr go stale in a long-running remote session, Bun's JSC hits the race path far more frequently. Fix the connection stability first, then tune the JSC flags.
What's working:

SSH keepalives on the server (/etc/ssh/sshd_config):

TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 10

JSC flags as belt-and-suspenders:

bashclaude() {
BUN_JSC_numberOfGCMarkers=1
BUN_JSC_useParallelMarkingConstraintSolver=false
BUN_JSC_useConcurrentGC=false
command claude --dangerously-skip-permissions "$@"
}
Sixth distinct crash address this run: 0x7219. The underlying race is still there. But 175 minutes of productive work before a crash is a completely different operational reality than 34 seconds.
If you're running CC over SSH and hitting this, fix your keepalives before chasing JSC flags. That may be most of your problem.
Still on 1.3.14. Will update if behavior changes.

❯ ============================================================
Bun v1.3.14 (1bfa5e34) Linux x64 (baseline)──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Linux Kernel v6.17.0 | glibc v2.39
CPU: sse42 popcnt avx avx2 (shift+tab to cycle)
Args: "claude" "--dangerously-skip-permissions"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(14) fetch(141) jsc spawn(127) standalone_executable yaml_parse claude_code
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:constants" "node:crypto" "node:dns" "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:readline" "node:stream" "node:stream/consumers" "node:stream/promises" "node:string_decoder" "node:timers/promises" "node:tls" "node:tty" "node:url" "node:util" "node:vm" "node:zlib" "ws" "node:http2"
Elapsed: 3776546ms | User: 68137ms | Sys: 4488ms
RSS: 102.04MB | Peak: 0.43GB | Commit: 102.04MB | Faults: 0 | Machine: 33.51GB

panic(main thread): Segmentation fault at address 0x0
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.14/B_11bfa5e3mgggkEuhogC4kpo4E+ypR2k63rFk7r75E6wxh6E2zl/4Eo3lmqF8q2lqFoljwqF8j2vqF4vzw/D0izy3Fy7x0sF070ssF______A2AA

Illegal instruction (core dumped)

Happened again this time after 62 minutes.

Confirming this on a second AMD Ryzen platform — Ryzen 9 5900X (Zen 3, 12C/24T), Ubuntu 24.04.4 LTS, kernel 6.8.0-111-generic, microcode 0xa201213, 65GB RAM. Same SlotVisitor::visitChildren segfault, same Bun 1.3.14 (build 1d298914), same baseline x86_64 binary.

7 crashes in 22.5 hours across 5 different projects (cook-law-email × 2, hds-website, email-triage, hermes-res, koby-paperclip) on 2026-05-20. Project-agnostic. Uptime to crash ranged 3 – 90 minutes — no useful predictor from session content.

Big thanks to @aik-rocket — your bisection of BUN_JSC_numberOfGCMarkers=1 + useParallelMarkingConstraintSolver=false + useConcurrentGC=false plus the SSH keepalive finding was the most actionable signal in this thread.

Update 2026-05-21 — Tier 1 mitigations applied, did not hold

Applied @aik-rocket's full flag stack at 03:30 UTC plus SSH keepalives (ClientAliveInterval 60, ClientAliveCountMax 10, TCPKeepAlive yes). Two crashes today with all mitigations confirmed active in the wrapper environment:

Crash #8 — 2026-05-21 11:56 UTC

• Uptime: 54 minutes
• Workload: high-throughput JSON polling (smoke_matrix.sh dispatching 8 parallel API tasks + repeated wait_for_terminal status checks)
• Fault: panic(main thread): Segmentation fault at address 0x800000000
• Notable: fault moved from parallel-marker thread to main thread. Setting numberOfGCMarkers=1 funnels GC work onto the main thread; the bug follows. Address 0x800000000 (bit 35 set) is a corrupted JSC NaN-boxed pointer tag.
• bun.report: https://bun.report/1.3.14/B_1d298914mgggkEuhogC4wvo4E+ypR203itFkny75E6js/4EokqmqF4z+lqFoxpwqFg22uqFq8pw0F25o61C0iph0Cgxgh1Cw1lqxCmg+2tEsk04wCy5/qpC6z0qpCy8wK0oxKA2QA

Crash #9 — 2026-05-21 14:38 UTC

• Uptime: 5 min 49 sec
• Workload: interactive coding session in a different repo (dev-infra)
• Fault: panic(main thread): Segmentation fault at address 0x71BE6517EAE8 — different fault address, same root.
• bun.report URL captured but not flushed to wrapper log file before terminal redraw — happy to share screenshot/raw report on request.

Verdict on Tier 1: the 54-min uptime was variance, not a fix. Mean uptime under the mitigated configuration on this hardware is back in single-digit minutes for JSON-heavy work. Tier 1 changes the thread where the crash manifests (parallel marker → main) but does not change the rate in any reliable way.

Observations to add to the corpus

1. The bug crosses Ryzen models (your 5500, my 5900X) and kernel versions (your 6.17, my 6.8). Common factor: x86_64-baseline build + JSC GC + Ryzen + Linux 6.x.
2. Same Bun build hash crashes deterministically. Build 1d298914 produces identical stack signatures across 5+ projects on this machine.
3. Mitigations relocate the bug, not eliminate it. Forcing single-threaded marking moves the segfault to the GC main thread. That's strong evidence the corruption is intrinsic to the SlotVisitor mark logic, not a parallel-marker race specifically — which matches WebKit #200863's class of defect.

Anthropic team — given the Bun acquisition (Dec 2025), is there internal coordination happening on this? WebKit #200863 has been open since 2019. For Linux-on-Ryzen CC users this is currently a daily-blocking issue with no working mitigation. Moving to mosh transport + shorter sessions as an ergonomic workaround, but the bug needs an upstream fix.

Update 2026-05-21 — Tier 2 (THP=never + mosh transport) — first signal that moves the needle

Followed up on my own loose-end ("moving to mosh transport + shorter sessions as an ergonomic workaround"). Posting the data because it's the first intervention to produce a measurable lifetime delta on this hardware (Ryzen 9 5900X / Ubuntu 24.04.4 / kernel 6.8.0-111).

What changed

Added on top of the full Tier 1 stack from my prior comment:

1. echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled (THP off — JSC's bmalloc and 2 MB hugepages are a known pathological combo; speculative).
2. Transport switched from SSH to mosh for all interactive CC sessions. WezTerm default_prog on the Mac Mini launches mosh ripordie -- tmux attach -t <session> so every dev-* pane is mosh by default. Suspended/roaming-resilient, UDP/SSP, no stdout staling.

JSC flags + SSH keepalives from Tier 1 still active as belt-and-suspenders.

Results — per-session lifetime distribution (n=9, post Tier 2 activation 16:35 UTC)

Dropping 2 fast-restart-loop outliers (≤5 min, clearly re-crashes on relaunch):

| Sample (min) | 31 | 55 | 57 | 63 | 65 | 68 | 72 | 137 | 150 |
|---|---|---|---|---|---|---|---|---|---|
| Status | crash | crash | crash | crash | crash | crash | crash | crash | crash |

• Median: 65 min · Mean: 78 min · Max: 150 min
• Tier 1 baseline (from prior comment): 5.8 min + 54 min → mean ~30 min
• Improvement: ~2x median session lifetime, ~5x increase in max observed uptime.

Two sessions cleared 2+ hours — territory I never saw under Tier 1 on this box.

Crash signature unchanged

Same panic(main thread): Segmentation fault at a varying high-bit address. Today's reported one: 0x800000000. Bun still 1.3.14 (1d298914). The relocation pattern @aik-rocket observed ("each flag suppresses one race path and exposes another") continues to hold — Tier 2 didn't change the fault class, just the cadence.

Operational read

Mosh transport seems to be acting as a stronger version of @aik-rocket's SSH-keepalive finding. Where keepalives prevent stdout from going stale, mosh's SSP layer eliminates the entire transport-layer accelerant: the client can suspend, the laptop can sleep, the network can flap, none of it reaches Bun's event loop. Whatever interaction between stale stdio and JSC's GC was punching the crash rate up under SSH appears largely defanged under mosh.

Verdict: still not a fix. The underlying SlotVisitor race is intact. But 2x median uptime + 2.5-hour max are a different operational reality than what I had under Tier 1. Reporting in case it helps anyone else triaging this on Ryzen / Linux 6.x.

Open question for Anthropic

Six weeks of progressive bisection by community members (@aik-rocket, myself, others) has produced workarounds that relocate the bug across thread / address / cadence but never eliminate it. Given the Bun acquisition closed Dec 2025, is there any internal coordination on the WebKit #200863 class of defect? Happy to provide raw crash logs, bun.report URLs, or run a specific repro for the team. The thread will keep generating new addresses indefinitely otherwise.

Update 2026-05-26 — Two crash classes in same hour, Tier 2 still holding cadence

Five-day check-in. Same Ryzen 9 5900X / Ubuntu 24.04 / kernel 6.8.0-111 box, same Tier 2 stack (mosh transport + THP=never + full JSC flag set from aik-rocket), still on CC 2.1.142 / Bun 1.3.14 (1d298914).

Two distinct crash classes observed in 43 minutes this morning

| Time UTC | Class | Address | Elapsed | bun.report |
|---|---|---|---|---|
| 12:38:02 | panic(main thread): Segmentation fault (SlotVisitor variant) | 0x7D8869C210E8 | 2,390,713 ms (~40 min) | https://bun.report/1.3.14/B_1d298914mgggkEuhooC4wvo4E+ypRkny75E683h6E2/r/4EojsmqF828lqFoxpwqF8v8vqF4v5w/D0u5y3Fyn40sF0n7ssF__msoy+Dipq9zFu988zF8hm24F44pzkEA2w4+Bwuoo4pD |
| 12:43 (×3 in 7 s) | respawn-loop crashes on relaunch | — | <5 s each | — |
| 13:21:00 | SIGILL / Illegal instruction — startup UD2 panic | n/a | <2 s | https://bun.report/1.3.14/Sg1d298914mgggkEuhogC4wvo4E+ypRkny75E683h6E2/... (full URL in crash log) |

Why this matters

The 12:38 crash is the long-running SlotVisitor SIGSEGV this thread has been tracking since May 10. The 13:21 crash is a different failure mode — SIGILL in Bun's startup signal-handler installer, fires <2 s into /continue, no GC pressure, no inference load. I'd seen the SIGILL variant twice in a single cluster on 2026-05-23 (both during /continue startup, identical bun.report URL prefix — file-read burst as trigger). It is not the same class as the SlotVisitor segfault, but it appears in the same wrapper telemetry and the same Bun build.

Filing both here rather than splitting issues because (a) same Bun version, same hardware, same machine state, and (b) the operational impact for end users is identical — claude exits 132, session dies. Happy to split if Anthropic prefers.

Tier 2 cadence still holds

The 12:38 crash uptime (~40 min) lands in the middle of the distribution I posted last week (31–150 min, median ~65 min on n=9). Adding today's data points keeps the median in the same band; mosh+THP+JSC flags continue to relocate but not eliminate.

CC version note

I flipped autoUpdates back to true on 2026-05-23 after pinning to 2.1.142 during the SIGILL cluster. The 2.1.144 binary is on disk (~/.local/share/claude/versions/2.1.144) but hasn't been promoted — launcher still resolves to 2.1.142. So everything above is pre-autoupdate data on the same binary as my prior comments.

Ask

5 days since my last update, no movement in the thread. Given the Bun acquisition closed Dec 2025, can someone on the Anthropic side confirm whether the SlotVisitor class is on a roadmap or stuck behind WebKit #200863? I can keep generating addresses indefinitely, but the value of new bun.report URLs is approaching zero unless there's an upstream owner to send them to.

Raw crash logs available on request.

Corroborating this on Linux with a clean version boundary that points squarely at the Bun 1.3.14 baseline bump.

Environment

• ASUS ROG Zephyrus G14, Linux kernel 7.0.5 (linux-g14), glibc 2.43
• CPU is AVX2-capable (sse42 popcnt avx avx2) — yet the bundled binary runs the baseline Bun, consistent with the "all platforms ship the identical baseline binary" finding here.

Crash (every fresh interactive launch, any directory)

Bun v1.3.14 (521eedd6) Linux x64 (baseline)
panic(main thread): Segmentation fault at address 0x24
oh no: Bun has crashed.

Dies ~79ms in, RSS ~42MB — i.e. during startup, before any real work.

Version boundary (same machine, same ~/.claude, native install)

• claude-code 2.1.150 (older bundled Bun) → launches fine.
• claude-code 2.1.152 (Bun 1.3.14 baseline) → SIGILL every time.

So on this box it's strictly the 2.1.150→2.1.152 Bun bump, not config/state.

Repro nuance that may help narrow it: <versions>/2.1.152 --version exits 0 cleanly — the crash only happens on full interactive startup. Reproducible headlessly:

script -qec "<versions>/2.1.152" /dev/null </dev/null   # panics
script -qec "<versions>/2.1.150" /dev/null </dev/null   # clean

Confirming the auto-updater point (#5 above): the ~/.local/bin/claude symlink got repointed to 2.1.152 despite "autoUpdates": false in ~/.claude.json. Rolling the symlink back to 2.1.150 alone does not hold — the launcher re-selects the newest downloaded version (2.1.152) on each start, and even recreates a 0-byte 2.1.152 stub if the binary is moved.

Workaround that actually holds on Linux (for others blocked here):

1. Quarantine the bad binary so it can't be re-selected: mv ~/.local/share/claude/versions/2.1.152 ~/.local/share/claude/versions/2.1.152.broken
2. Repoint to the last good version: ln -sfn ~/.local/share/claude/versions/2.1.150 ~/.local/bin/claude
3. Disable the updater so it stops re-staging it: export DISABLE_AUTOUPDATER=1 (in your shell profile).

Bun crash report dump: https://bun.report/1.3.14/B_1521eeddkggggEggggC4wvo4E+u0Pui25uFgrhlvF0s62uFo8umvF00t0uF48m1uFo4i0uF8kh0uF88v2uFyv70uFo4i0uF8kh0uFsjpnvFiytr6Eyo1y3Fw/jxrF462qjEgn9pjEA2AoC

Update 2026-05-28 — New Bun build 1521eedd ships in 2.1.144/2.1.145, bug persists

Quick data point after letting the stable channel auto-updater carry me through 2.1.142 → 2.1.143 → 2.1.144 → 2.1.145 (retired my pin on 2.1.142). Still same Ryzen 9 5900X box, Ubuntu 24.04, kernel 6.8.0-111-generic, Tier 2 mitigation stack still loaded (mosh transport, THP=never, full JSC flag set from @aik-rocket).

Key new finding: Anthropic shipped a new Bun build, crash persists

| CC version | Bun build ID | Status |
|---|---|---|
| 2.1.133 | 1c644815 | crashing |
| 2.1.138 | 1bfa5e34 | crashing |
| 2.1.142 | 1d298914 | crashing |
| 2.1.144 / 2.1.145 | 1521eedd | crashing |

That's a third distinct Bun binary in 5 months still hitting the same SlotVisitor/JSC GC family. Whatever's being rebuilt upstream isn't catching this.

5 crashes in the 2.1.144/2.1.145 cohort

All AMD Ryzen 9 5900X, same box, Tier 2 mitigation active:

| # | Uptime | RSS / Peak | Address | Build | Working dir |
|---|---|---|---|---|---|
| 12 | 24 min | — | heap | 1521eedd | save-pipeline |
| 13 | 4.8 min | — | heap | 1521eedd | various |
| 14 | 43 min | — | heap | 1521eedd | various |
| 15 | 2.7 min | 0.20/0.43 GB | 0x75DAE61E3C68 (heap) | 1521eedd | donnie-hermes |
| 16 | 40.5 min | 0.29/0.51 GB | 0x0 (NULL deref) | 1521eedd | cook-law-email |

Worth flagging: crash #16 hit address 0x0 (NULL deref) — structurally different from the prior heap-address pattern. Likely the same GC bug visiting an already-freed slot (NULL after sweep), but could also be a sibling bug riding the same JSC marker path. Stack trace was lost to PTY/ANSI wrapping noise (claude-wrapper limitation, working on it).

crash #16 bun.report:
https://bun.report/1.3.14/B_1521eeddmgggkEuhogC4wvo4E+ypR___+stzhGsoyzhG4yl0hG8060hGmqlnB2muqCA2AA

Channel context for anyone landing on this issue

• stable channel head = 2.1.145 (crashing)
• latest channel head = 2.1.153 (also has open crash reports, e.g. #62809 on 2.1.149 Intel macOS)

No fix shipped in either channel as of today. Auto-update channel choice doesn't get you out of this bug family.

Tier 2 mitigation: still partially holding, not fixing

5 crashes in this cohort with uptimes 2.7 / 4.8 / 24 / 40.5 / 43 min. Earlier (2.1.142) pre-Tier-2 baseline was ~5 crashes/22h on this box; current cadence is roughly comparable. Tier 2 buys longevity, not elimination — concurs with @aik-rocket's original "mitigation, not fix" framing.

Ask

@bcherny — has anyone on the CC team looked at the JSC build flags being passed when these Bun binaries are produced? Three rebuilds in 5 months hitting the same bug family suggests the upstream JSC patch (Bun #27312 / WebKit #200863) isn't making it into the bundled build, OR the bundling step is overriding it. Happy to test a custom build or run instrumented sessions if useful.

Update 2026-05-29 — Two more crashes on 2.1.156 (current stable), ~11 h apart

Increment on my 2026-05-28 post. The stable auto-updater has since carried this box 2.1.145 → 2.1.156 (current default model is now Opus 4.8 / 1M ctx — irrelevant to a JSC bug, noted only to confirm this is the stock GA config). Same hardware and mitigation stack as every prior update:

• Box: Ryzen 9 5900X (Zen 3, 12C/24T), Ubuntu 24.04.4, kernel 6.8.0-111-generic, microcode 0xa201213, 65 GB RAM
• Tier 2 stack still loaded: mosh transport, THP=never, and @aik-rocket's full JSC flag set — BUN_JSC_numberOfGCMarkers=1, BUN_JSC_useParallelMarkingConstraintSolver=false, BUN_JSC_useConcurrentGC=false — all three confirmed active in both crashing processes' env.

Both crashes are the same SlotVisitor GC family, both mid-session, both on Bun 1.3.14 build 1521eedd (the build that ships in 2.1.144/2.1.145 and is carried forward into 2.1.156):

| # | Time (UTC) | Project | Segfault addr | Uptime | exit | bun.report |
|---|---|---|---|---|---|---|
| 1 | 2026-05-28 22:17 | email-triage | 0x798C69C62FE8 | — * | 132 | …/B_1521eeddmgggkEuhogC4wvo4E+ypRkny75E6js/4EojsmqF828lqFoxpwqF8v8vqF4v5w/D0w5y3Fyn40sF0n7ssF________A2448Bw+344pD |
| 2 | 2026-05-29 09:51 | ca-website | 0x79DDE654CC68 | ~9.1 min | 132 | …/B_1521eeddmgkgkEuhogC4wvo4E+ypRkny75E683h6E2/r/4EokqmqF4z+lqFoxpwqFg22uqFq+pw0F25o61C0iph0Cgxgh1Cw1lqxCmg+2tEsk04wCy5/qpC6z0qpCy8wK0oxKA2698Bx55s1Z |

\* uptime not reliably recoverable for crash 1 (the in-process Elapsed field in that capture was a stale render); crash 2's was clean at 545219 ms. Memory at crash 2: RSS 0.26 GB / Peak 0.72 GB / 0 faults / 65 GB free — system healthy, no pressure.

Full URLs (line-wrap-safe):

• https://bun.report/1.3.14/B_1521eeddmgggkEuhogC4wvo4E+ypRkny75E6js/4EojsmqF828lqFoxpwqF8v8vqF4v5w/D0w5y3Fyn40sF0n7ssF________A2448Bw+344pD
• https://bun.report/1.3.14/B_1521eeddmgkgkEuhogC4wvo4E+ypRkny75E683h6E2/r/4EokqmqF4z+lqFoxpwqFg22uqFq+pw0F25o61C0iph0Cgxgh1Cw1lqxCmg+2tEsk04wCy5/qpC6z0qpCy8wK0oxKA2698Bx55s1Z

Running tally (this box, since 2026-05-19)

• 19 confirmed crashes in ~10 days, all exit 132, all the SlotVisitor::visitChildren / drainFromShared GC family
• CC versions hit: 2.1.142, 2.1.144, 2.1.145, 2.1.156 — every stable release in the window, including current
• Bun builds hit: 1d298914 (2.1.142) and 1521eedd (2.1.144 → 2.1.156) — both 1.3.14
• Tier 1 JSC flags don't prevent it — they relocate the fault toward the main thread (numberOfGCMarkers=1 funnels GC work main-thread-ward and the bug follows; I've caught addresses like 0x0 and 0x800000000, i.e. fully-corrupted NaN-boxed pointer tags). Tier 2 (THP=never + mosh) only extends idle / low-throughput session lifetime (one ~10-day and one ~11-day idle survivor); throughput-heavy and short interactive sessions still die in single-digit minutes (crash 2 above = ~9 min).
• Three independent Linux reporters in this thread now (myself, @aik-rocket, @f4mrfaux), all on the baseline x86_64 binary.

Ask

Nothing actionable on your side beyond awareness that the current stable (2.1.156) still ships the crashing Bun 1.3.14, and the JSC env-flag mitigations don't stop it. Still happy to provide a core dump or test a CC build against a canary Bun — caveat unchanged: Bun is bundled inside the CC binary, so bun upgrade --canary isn't directly available; this would need a CC build linked against canary Bun, or an extract-and-swap of the bundled runtime.

Adding another datapoint: 4 crashes today on the same signature (multiple threads segfaulting, ends with Illegal instruction (core dumped)), on the latest CLI.

Environment

• Claude Code: 2.1.173 (native installer, Bun v1.3.14 2a41ca97, Linux x64 baseline)
• Kernel: Linux 6.8.0-124-generic, glibc 2.39
• CPU features: sse42 popcnt avx avx2 avx512
• RAM: 27.11 GB

Both crashed sessions were long-running with heavy fetch/spawn activity, consistent with the ReadableStream/Response.body finalizer theory in oven-sh/bun#31159:

| Session | Elapsed | fetch | spawn | RSS / Peak |
|---|---|---|---|---|
| 1 | 27.5 min | 310 | 75 | 120 MB / 0.45 GB |
| 2 | 2.26 hr | 550 | 93 | 124 MB / 0.53 GB |

Crash reports (bun.report)

Session 1 (3 panics, addresses 0x7C6139FB4020, 0x3C6539FB4020, 0x0):

• https://bun.report/1.3.14/B_12a41ca9mgggkEuhogC4wzo4E+ypRs73yqFq91yqF439yqF+vpkqF8pwuqFm30uqFku7o4EmqlnB2muqCA2im+Bgigt/5B
• https://bun.report/1.3.14/B_12a41ca9mgggkEuhogC4wzo4E+ypRs73yqFq91yqF439yqF+vpkqF8pwuqFm30uqFku7o4EmqlnB2muqCA2qmegigt/5B
• https://bun.report/1.3.14/B_12a41ca9mgggkEuhogC4wzo4E+ypRs73yqFq91yqF439yqF+vpkqF8pwuqFm30uqFku7o4EmqlnB2muqCA2AA

Session 2 (2 identical panics at 0x3BA9B1F74020):

• https://bun.report/1.3.14/B_12a41ca9mgggkEuhogC4wzo4E+ypRs73yqFq91yqF439yqF+vpkqF8pwuqFm30uqFku7o4EmqlnB2muqCA2y6dh+/ihuC

Hitting what looks like the same underlying bug class on WSL2 (Claude Code 2.1.198–2.1.201, Bun v1.4.0 — so this isn't fixed even in 1.4.0, not just 1.3.14).
Different crash site than the one in this issue (JSC GC concurrency in general seems to be the common thread across all these reports), but same failure mode: null/invalid pointer deref inside JSC's garbage collector during a background GC thread, not tied to memory pressure or any specific user action.

My case: SIGSEGV at address 0x0, inside JSLock.cpp:55
(RefPtr<JSC::VM>::refIfNotNull), reached via
JSC::LocalAllocator::allocateSlowCase → JSC::MarkedBlock::Handle::sweep,
triggered during a TCPSocket.upgradeTLS() call racing against a Rust-side
socket Handlers::drop.

Filed upstream with full stack trace:
https://github.com/oven-sh/bun/issues/33387

10 crashes captured in one session; traced one back to a live bun.report capture via script -c "claude" ~/log to preserve stderr through the pty (the WSL2 crash .dmp files themselves are useless for diagnosis — they just show Bun's crash handler re-raising SIGSEGV via pthread_kill after the fact, not the original fault site).

Environment: WSL2 Ubuntu, Windows 11, Claude Code 2.1.198–2.1.201,
Bun 1.4.0 (commit 63bb0ca).