[BUG] Bun has crashed

Status Closed — not planned
Maintainer reply None cached
Activity 11 comments · opened Feb 8, 2026 · closed Mar 20, 2026

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?

---
Title: crash: Bun Canary segfault when accepting edits on multiple files (50+ files)

Labels: bug, crash, platform:windows, area:core, has repro

---
Description

Claude Code crashes with a Bun segmentation fault when accepting edits on a large number
of files (~50 files). The crash occurs with Bun Canary v1.3.9-canary.51 (bundled with
Claude Code) on Windows 11.

Environment

  • Claude Code version: (Check with claude --version)
  • Bun version (bundled): v1.3.9-canary.51 (d5628db2)
  • OS: Windows 11 x64
  • CPU features: sse42 avx avx2

Crash Details

⏵⏵ accept edits on (shift+tab to cycle) · 50 files +798 -159
============================================================
Bun Canary v1.3.9-canary.51 (d5628db2) Windows x64 (baseline)
Windows v.win11_zn
CPU: sse42 avx avx2
Args: "C:\Users\user\.local\bin\claude.exe"
Elapsed: 8306506ms | User: 337015ms | Sys: 300906ms
RSS: 1.74GB | Peak: 2.42GB | Commit: 3.13GB | Faults: 12241916

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

Crash Report: https://bun.report/1.3.9/e_2d5628dbmgkgEuhogCgm+2W88outB4s+mqC49uiqC6ssiqCy
7sqXozg0U23wN2/tgUm17jOimsjOw0vxvDCYKERNEL32.DLLg+pFCSntdll.dll2lkBA2DD

Root Cause Analysis

  1. Bun Canary Build: The bundled Bun is using an unstable canary build (v1.3.9-canary.51)

instead of stable (v1.3.8)

  1. No File Batching: 50 files are processed concurrently without any backpressure or

batching

  1. Memory Pressure: 12M+ page faults indicate severe memory pressure
  2. Invalid Address: 0xFFFFFFFFFFFFFFFF suggests NULL pointer dereference or

use-after-free

Steps to Reproduce

  1. Ask Claude Code to make edits across ~50 files (~800 line changes)
  2. Accept the edits
  3. Claude Code attempts to process all files concurrently
  4. Crashes with segfault

Expected Behavior

Either:

  • Files are edited successfully
  • Graceful error handling with retry logic
  • Files are processed in smaller batches automatically

Actual Behavior

Hard crash with segfault, all progress lost.

Related Issues

Suggested Fixes

  1. Switch to Stable Bun: Bundle Bun stable (v1.3.8) instead of canary builds
  2. Implement File Batching: Automatically split large edit operations into smaller

batches (5-10 files at a time)

  1. Adaptive Concurrency: Detect runtime type and adjust concurrency limits:
  • Bun (Canary): 3-5 files
  • Bun (Stable): 5-8 files
  • Node.js: 10-15 files
  1. Memory Awareness: Check available memory before batch operations
  2. Checkpoint System: Save progress so failed operations can be resumed

What Should Happen?

Bun has crashed

Error Messages/Logs

============================================================
  Bun Canary v1.3.9-canary.51 (d5628db2) Windows x64 (baseline)
  Windows v.win11_zn
  CPU: sse42 avx avx2
  Args: "C:\Users\user\.local\bin\claude.exe"
  Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(325) fetch(1356) jsc
   spawn(11287) standalone_executable process_dlopen yaml_parse(1845)
  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: 8306506ms | User: 337015ms | Sys: 300906ms
  RSS: 1.74GB | Peak: 2.42GB | Commit: 3.13GB | Faults: 12241916 | Machine: 68.30GB

  panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF
  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.9/e_2d5628dbmgkgEuhogCgm+2W88outB4s+mqC49uiqC6ssiqCy7sqXozg0
  U23wN2/tgUm17jOimsjOw0vxvDCYKERNEL32.DLLg+pFCSntdll.dll2lkBA2DD

Steps to Reproduce

-

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

-

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

11 Comments

freeng · 6 months ago

+1

freeng · 6 months ago

There is a certain condition that triggers the issue: when the Claude extension for VS Code (including the Insiders version) is enabled and a directory is opened, launching Claude simultaneously in PowerShell 7 within the same directory will trigger it. Other scenarios have not been tested yet.

freeng · 6 months ago

Some new clues: related to context7, MCP, and PowerShell 7.

CMD + context7 MCP = normal
PowerShell 7 + context7 MCP = error
PowerShell 7 + context7 MCP disabled = normal

freeng · 6 months ago

something new:
disable pencil mcp,PowerShell 7 + context7 MCP is ok

jpbroeders · 6 months ago

I got it also a lot, more with new Opus 4.6 than with the Sonnet 4.5. But it occurs in both models. Sometimes even when I just do a simple /init

I have a windows machine with 64GB memoery and Node 24.x

jruckert · 6 months ago

Ive had this a lot also, when I closed down VS Code insiders and also any open windows explorers, it started to work again.

sitefinitysteve · 6 months ago

I'm just hosed completely right now I can't load CC anywhere in Parallels

MartinWickman · 6 months ago

This still happens in latest version v2.1.49. Claude Code for Windows (or WSL) is not reliable enough to be used in a professional setting atm.

sitefinitysteve · 6 months ago
This still happens in latest version v2.1.49. Claude Code for Windows (or WSL) is not reliable enough to be used in a professional setting atm.

Not usable in any setting, the irony is the release that caused it touting Windows stability.

github-actions[bot] · 5 months ago

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

github-actions[bot] · 5 months ago

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.