Environment
- OS: Windows 11 (10.0.26200)
- claude-mem: 12.3.9
- Bun: located at
C:\Users\<user>\.bun\bin\bun.exe (on PATH)
- Claude Code: 2.1.158 (VSCode extension)
- Host project: Next.js 16.2.6 (Turbopack), React 19.2, Node v24.14.0
Summary
claude-mem launches its MCP server and worker daemon via bun (not Node). Under host memory pressure — specifically when the active project runs next dev (Turbopack), which spikes ~2-4 GB during first compile — the claude-mem Bun workers cascade-OOM, with worker-service respawning replacements that also OOM, flooding stderr. The cascade has been correlated with a STATUS_STACK_BUFFER_OVERRUN (0xC0000409) crash of claude.exe itself shortly after.
Process tree observed (3 live bun.exe)
bun PID 16308 cmd: bun .../claude-mem/12.3.9/scripts/mcp-server.cjs
parent: claude.exe (Claude Code native)
bun PID 24596 cmd: bun.exe .../scripts/worker-service.cjs --daemon
bun PID 14540 cmd: bun.exe .../scripts/mcp-server.cjs
parent: bun.exe PID 24596 (worker-service spawning replacements)
Error signatures (verbatim from cascade stderr)
# Fatal process out of memory: Re-embedded builtins: set permissions
----- Native stack trace -----
1: node::MultiIsolatePlatform::DisposeIsolate+5341
2: v8::base::FatalOOM+54
...
9: v8::Isolate::Initialize+662
10: node::SetIsolateUpForNode+749
Also during the same cascade:
FATAL ERROR: Zone Allocation failed - process out of memory
FATAL ERROR: Committing semi space failed. Allocation failed - JavaScript heap out of memory
# Fatal JavaScript out of memory: MemoryChunk allocation failed during deserialization.
Reproduction
- claude-mem 12.3.9 active (bun MCP + daemon workers running).
- Open a Next.js 16 project (Turbopack) with a moderately heavy homepage (many lucide-react imports + a large
public/ SVG works as catalyst).
- Run
npm run dev.
- Trigger first compile of
/ (browser visit or Turbopack prefetch).
- Observe bun stderr cascade and eventual
npm run dev exit (exit 127 here). Second occurrence in the same session: Claude Code parent process exited with 0xC0000409.
Current workaround
Use next start (production build) instead of next dev — no Turbopack, no memory spike, no Bun cascade. HMR is the loss.
Suggested improvements
- Optional Node runtime for MCP server / worker — an env flag (e.g.
CLAUDE_MEM_RUNTIME=node) that runs the same .cjs scripts under Node instead of Bun. Node degrades more gracefully under memory pressure on Windows (no STATUS_STACK_BUFFER_OVERRUN on stack guard violation; clean V8 OOM with cleanup).
- Backoff on worker respawn — when worker-service detects N OOM exits in T seconds, stop respawning and surface the error instead of cascade-flooding stderr.
- Document Windows + heavy-compiler interaction in README.
Happy to provide full crash dumps or test patches.
Environment
C:\Users\<user>\.bun\bin\bun.exe(on PATH)Summary
claude-mem launches its MCP server and worker daemon via
bun(not Node). Under host memory pressure — specifically when the active project runsnext dev(Turbopack), which spikes ~2-4 GB during first compile — the claude-mem Bun workers cascade-OOM, with worker-service respawning replacements that also OOM, flooding stderr. The cascade has been correlated with aSTATUS_STACK_BUFFER_OVERRUN(0xC0000409) crash ofclaude.exeitself shortly after.Process tree observed (3 live bun.exe)
Error signatures (verbatim from cascade stderr)
Also during the same cascade:
Reproduction
public/SVG works as catalyst).npm run dev./(browser visit or Turbopack prefetch).npm run devexit (exit 127 here). Second occurrence in the same session: Claude Code parent process exited with 0xC0000409.Current workaround
Use
next start(production build) instead ofnext dev— no Turbopack, no memory spike, no Bun cascade. HMR is the loss.Suggested improvements
CLAUDE_MEM_RUNTIME=node) that runs the same.cjsscripts under Node instead of Bun. Node degrades more gracefully under memory pressure on Windows (noSTATUS_STACK_BUFFER_OVERRUNon stack guard violation; clean V8 OOM with cleanup).Happy to provide full crash dumps or test patches.