Bun runtime unsuitable for long sessions: mimalloc crashes after 12-24h, ~1GB/h memory growth, system-wide stuttering

[kolkov]

Summary

Bun runtime (v1.3.11) is not suitable for long-running Claude Code sessions. The mimalloc memory allocator crashes with "Illegal instruction" after 12-24 hours of continuous use, regardless of other fixes applied. This is a fundamental runtime limitation, not a Claude Code application bug.

Evidence: Two crashes, different causes, same mimalloc panic

Metric	Crash #1 (v2.1.76)	Crash #2 (v2.1.79)
Session duration	12.4 hours	23.7 hours
RSS	2.58 GB	1.73 GB
Committed memory	13.81 GB	15.40 GB
Page faults	27 million	67 million
Auto-updater	Enabled (memory leak)	Disabled (DISABLE_AUTOUPDATER=1)
Claude Code version	2.1.76	2.1.79
Crash address	0x7FF641918940	0x7FF7A3A98940
Error	mimalloc scavenger panic	mimalloc panic

Crash #1 was partially explained by the auto-updater memory leak (fixed in v2.1.77). Crash #2 occurred with auto-updater disabled — the mimalloc allocator itself leaks committed memory at roughly 0.6-1 GB/hour during active Claude Code sessions.

Crash details

Crash #1 (v2.1.76, 12.4 hours)

Bun v1.3.11 (a2743b6d) Windows x64 (baseline)
Elapsed: 44576556ms | RSS: 2.58GB | Commit: 13.81GB | Faults: 27235766
allocator->scavenger_data.is_in_use = yes
panic: Illegal instruction at address 0x7FF641918940

Crash #2 (v2.1.79, 23.7 hours)

Bun v1.3.11 (a2743b6d) Windows x64 (baseline)
Elapsed: 85278850ms | RSS: 1.73GB | Peak: 1.93GB | Commit: 15.40GB | Faults: 67347099
panic(thread 59820): Illegal instruction at address 0x7FF7A3A98940

Both crashes share the same pattern: mimalloc's scavenger (garbage collector) encounters an inconsistent state after hours of memory fragmentation → "Illegal instruction" → process terminates. In some cases the IDE (GoLand/VS Code) crashes along with it; in others the IDE survives but becomes sluggish due to memory pressure before the crash.

Impact

• All unsaved work is lost — no graceful shutdown, no session save
• IDE crashes too — if Claude Code runs inside GoLand/VS Code terminal, the IDE terminal tab dies
• No warning — memory grows silently in the background, crash is sudden
• System-wide impact — before crash, mimalloc garbage collection causes system-wide stuttering: mouse lag, keyboard input delays across ALL Windows applications, not just Claude Code
• Affects autonomous agents — overnight agent runs (a key Claude Code use case) are unreliable
• Debug log evidence: Slow PostToolUse hooks: 2319ms, Slow render: 143ms with full-screen damage, Edit tool validation error: File has not been read yet (tool result loss due to memory pressure)

Why this matters

Claude Code's value proposition includes long autonomous sessions — Rakuten famously ran a 7-hour autonomous refactoring of a 12.5M line codebase. But with Bun crashing after 12-24 hours, overnight and multi-hour autonomous sessions are a gamble.

Root cause

Bun v1.3.11 uses mimalloc as its memory allocator. During long-running sessions with many tool calls (thousands of Bash, Read, Edit, Write invocations), memory fragmentation accumulates. mimalloc's scavenger thread eventually encounters inconsistent allocator state, triggering a hardware trap (illegal instruction).

This is not specific to Claude Code — it's a Bun runtime issue. Related: oven-sh/bun#27690.

Suggested mitigations

1. Short-term: Warn users after N hours of continuous session (e.g., "Session running for 12h — consider restarting to prevent crash")
2. Short-term: Auto-save session state periodically so crash recovery is possible
3. Medium-term: Upgrade Bun or switch mimalloc configuration to reduce fragmentation
4. Long-term: Consider a more stable runtime — Node.js doesn't have this issue, and a Go rewrite would eliminate it entirely

Environment

• Claude Code: v2.1.76 (crash Create SECURITY.md #1), v2.1.79 (crash I want to use openrouter #2)
• OS: Windows 10 Home 10.0.19045
• RAM: 40 GB
• Bun: v1.3.11 (bundled with Claude Code)

Related issues

• Auto-updater memory leak crashed 12-hour session (v2.1.76) — 13.81 GB committed, Bun panic #35171 — Auto-updater memory leak (partially fixed in v2.1.77, but mimalloc issue remains)
• [BUG] Crash: "Illegal instruction" (Bun panic) after extended use - memory leak (~20GB RSS) #26174 — 20GB RSS → Illegal instruction crash
• [BUG] illegal hardware instruction - bun has crashed (segfault) #30223 — Bun segfault
• SSE streaming hangs indefinitely (no timeout) + ESC cannot fully cancel (queue auto-restart) — root cause analysis with fix proposals #33949 — Root cause analysis of streaming hangs (separate issue, but compounds the problem)
• oven-sh/bun#27690 — Bun panic during Claude CLI usage

[github-actions]

Found 3 possible duplicate issues:

1. Auto-updater memory leak crashed 12-hour session (v2.1.76) — 13.81 GB committed, Bun panic #35171
2. Extreme memory consumption on Windows (13GB RSS, 47GB commit) with Bun Canary #24840
3. Bun segfault after long session (~14h) on macOS Silicon #29474

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

[kolkov]

Not a duplicate. Each issue documents a different aspect:

• Auto-updater memory leak crashed 12-hour session (v2.1.76) — 13.81 GB committed, Bun panic #35171 (ours) — auto-updater memory leak specifically. Fixed in v2.1.77. Our new issue proves the problem persists without auto-updater
• Extreme memory consumption on Windows (13GB RSS, 47GB commit) with Bun Canary #24840 — reports extreme memory consumption but no root cause analysis
• Bun segfault after long session (~14h) on macOS Silicon #29474 — macOS Silicon specific segfault

This issue is unique because:

1. Two crashes compared — with and without auto-updater, proving mimalloc itself is the problem
2. Memory growth rate quantified — ~0.6-1 GB/hour of committed memory
3. System-wide impact documented — mouse lag, keyboard delays across ALL Windows apps (mimalloc GC pauses)
4. Debug log evidence — Slow PostToolUse hooks: 2319ms, Slow render: 143ms with full-screen damage
5. Actionable mitigations proposed — session duration warning, auto-save, runtime alternatives

[kolkov]

Update: Process memory analysis — 7 CLI instances = 5.3 GB RSS, 7.9 GB commit, 87 GB virtual

Ran PowerShell analysis on all claude.exe processes. Found 19 processes total:

Claude Code CLI (Bun) — 7 processes

PID	RSS (MB)	Commit (MB)	Virtual (GB)
71792	964	1,448	12.6
119128	821	1,423	12.9
9400	826	1,103	12.5
102472	779	1,077	12.3
61848	733	900	12.3
108592	623	797	12.1
22860	573	1,124	12.8
TOTAL	~5.3 GB	~7.9 GB	~87 GB

Claude Desktop (Electron) — 12 processes

~1.5 GB RSS additional (gpu, renderer×5, network, audio, crashpad) — just for monitoring usage limits.

Why this matters

1. Task Manager hides the problem — it shows RSS (Working Set), not Commit. Users see ~700-900 MB per process and think "that's fine." The real commit is 1-1.4 GB, and virtual reservation is 12+ GB per process (mimalloc).

2. Commit → pagefile → system-wide lag — the 7.9 GB commit minus 5.3 GB RSS = ~2.6 GB in pagefile. mimalloc's scavenger constantly touches these pages → page faults → mouse stuttering, keyboard lag across ALL Windows applications.

3. No RAG, no vector DB — we checked cli.js for SQLite, embeddings, vector databases. None found. This is pure Bun/mimalloc runtime overhead for what is essentially a terminal app that sends HTTP requests.

4. Go comparison — an equivalent Go CLI would use ~50 MB per process. 7 instances = 350 MB vs 5,300 MB. 15x less memory.

To see the real picture: Task Manager → Details tab → right-click column header → Select columns → enable "Commit size"

[kolkov]

Update: 2 more crashes + GoLand IDE crash — all from memory pressure, not mimalloc panic

Running 7 parallel CLI agents on v2.1.80 with DISABLE_AUTOUPDATER=1. Memory growth over 4 hours:

~11:00  7 CLI procs  RSS: 2.8 GB  Commit: 5.5 GB   ← OK
~13:00  7 CLI procs  RSS: 6.4 GB  Commit: 26 GB    ← system-wide lag starts
~15:30  Crash #1 (gogpu/gg agent) — silent death
~15:40  Crash #2 (freicon agent) — silent death
~15:45  GoLand IDE crashed — had to reboot

These crashes are different from mimalloc panics — no Bun error output, no panic message. Just red line in terminal and dead process. Debug logs reveal the cause:

Crash #1: "Tool bash not found"

11:10 [ERROR] "Tool bash not found"      ← tools registry corrupted!
11:42 [ERROR] Request timed out
11:51 [DEBUG] idle_prompt → silence → dead

Crash #2: Windows ERROR_PARTIAL_COPY

12:26 [ERROR] cygheap read copy failed, Win32 error 299 (ERROR_PARTIAL_COPY)
  → Windows cannot fork bash: not enough memory for child process
12:28 [DEBUG] idle_prompt → silence → dead

Root cause: 26 GB commit from 7 CLI processes

Each Bun process grows ~3-5 GB/hour in commit. With 7 processes:

PID	RSS (MB)	Commit (GB)
77848	1,200	6.1
13372	951	5.8
70040	1,236	5.6
12948	239	3.5
14000	862	2.6
102472	192	1.6
41492	804	1.9
TOTAL	5.3 GB	26 GB

26 GB commit on a 40 GB RAM machine → Windows constantly swapping via pagefile → mouse stuttering, keyboard lag across ALL apps → eventually fork() fails (error 299) → agents die silently → IDE crashes.

Recommendation

Do not run more than 3-4 CLI agents simultaneously. Each agent accumulates 3-6 GB commit within hours. With 7 agents, the system degrades within 2-4 hours and crashes are inevitable.

This is a fundamental Bun/mimalloc limitation — the allocator reserves enormous virtual address space (12+ GB per process) and never releases committed memory back to the OS.

[kolkov]

Crash #6: mimalloc panic while agent was IDLE — not even doing anything

Elapsed: 28,943,283ms (8 hours)
RSS: 1.81GB | Peak: 1.81GB | Commit: 10.60GB | Faults: 22,439,155
panic(thread 49412): Illegal instruction at address 0x7FF671E78940

This is the most telling crash yet. The agent had finished all its tasks and was sitting in standby — no API calls, no tool execution, just idle. Debug log shows the last activity was lspRecommendation spam (8 identical "Skipping gopls-lsp (already installed)" checks in 100ms), then silence, then crash.

10.6 GB committed memory accumulated over 8 hours of mostly doing nothing. mimalloc's scavenger thread crashed during its own garbage collection cycle while the agent was idle.

Crash summary (6 crashes in 4 days)

#	Version	Hours	Commit	Mode	Cause
1	v2.1.76	12.4h	13.8 GB	Active	auto-updater + mimalloc
2	v2.1.79	23.7h	15.4 GB	Active	mimalloc
3	v2.1.79	~8h	~5 GB	Active	WebFetch 3.5h hang
4	v2.1.80	~6h	~5 GB	Active	Silent death (Win32 error 299)
5	v2.1.80	~6h	~5 GB	Active	Silent death (cygheap fork fail)
6	v2.1.80	8h	10.6 GB	Idle	mimalloc panic in standby

Crash #6 proves this is not about workload — mimalloc leaks and crashes even when the process is doing nothing. The scavenger thread encounters corrupted state from accumulated memory fragmentation regardless of activity.

This makes Bun fundamentally unreliable for any long-lived process — active or idle.

[kolkov]

Update: Switched from native (Bun) to npm (Node.js) — dramatic stability improvement

After 6 Bun crashes in 4 days, 26 GB commit from 7 processes, IDE crashes, and system deadlocks — we decided to switch back from the native installer (Bun 1.3.11) to the npm package (Node.js v22.17.0). Same cli.js, same settings, different runtime.

# How we switched (keep your settings!)
cp -r ~/.claude ~/.claude-backup          # backup first
rm ~/.local/bin/claude.exe                # remove native binary (NOT claude uninstall!)
npm install -g @anthropic-ai/claude-code  # install npm version

Results after first hours on Node.js

Memory — night and day:

Metric	Bun (native)	Node.js (npm)
Commit per process	1-15 GB (grows forever)	300-500 MB (stable)
Commit ≈ RSS ratio	Commit 10-15x larger than RSS	Commit ≈ RSS
5 processes total	26 GB commit	1.6 GB commit
System RAM used	70%+ (constantly swapping)	47% (21 GB free)
Memory over time	Grows 0.6-5 GB/hour	Flat or decreasing

Stability:

• 0 mimalloc crashes (impossible on Node.js)
• 0 "Tool bash not found" (no memory corruption)
• 0 system deadlocks
• 0 IDE crashes from memory pressure
• V8 GC actually returns memory to OS (mimalloc never did)

What still remains (cli.js / server-side):

• Streaming stalls — still happen (server-side issue)
• Tool result loss — insertMessageChain() for-loop still non-atomic

What ALSO disappeared (we thought it was Ink, it was Bun):

• Scroll resets (Full reset (scrollback changes)) — 316 per session on Bun → 0 on Node.js
• Input field rendering corruption — text appearing below prompt, garbled input — gone
• Scrolling history back and forth works smoothly — no jumps, no discomfort
• We originally attributed all of this to Ink's renderer (Terminal Scrolling Uncontrollably During Claude Code Interaction #3648, 👍694). Debug logs prove it was Bun/mimalloc corrupting render state.

The theory: Bun/mimalloc was THE root cause

We originally identified 3 separate root causes (#33949). But switching runtimes suggests many symptoms may have been one root cause — mimalloc memory corruption:

• "SSE connection dies" → corrupted HTTP client state
• "Tool result lost" → corrupted JSONL write buffer (partially — for-loop bug is real too)
• "Scroll jumps" → corrupted render state
• "Tool bash not found" → corrupted tools registry
• "21-thread deadlock" → corrupted event loop / mutex state
• "System freeze" → mimalloc scavenger blocking all threads

All of these disappear or dramatically reduce on Node.js/V8.

Recommendation

If you're experiencing crashes, memory bloat, or instability — try the npm install. You lose ~200ms startup time and auto-updates, but gain a runtime that's been stable for 15+ years. The native Bun installer is the default, but the npm package is still fully supported (v2.1.83).

Note: You'll see an "npm deprecated" banner on each launch — it's just a message, ignore it.

[junaidtitan]

The JSONL session file is a compounding factor here — as it grows across a long session, every turn re-parses it and the in-memory footprint compounds with the Bun leak.

We built Cozempic to keep session files lean: it prunes bloat like tool output noise, progress bars, and stale reads down to the meaningful content. A guard daemon does this automatically every 30s in the background.

pip install cozempic && cozempic guard

Won't fix the Bun memory leak itself, but reducing the JSONL load size meaningfully cuts the per-turn memory overhead. We use it internally on 12h+ sessions.

Curious whether it moves the needle on your crash timeline — would be useful data.