Extreme memory consumption on Windows (13GB RSS, 47GB commit) with Bun Canary
Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 14 comments · opened Feb 10, 2026 · closed Apr 7, 2026
Description
Claude Code consumes an extreme amount of memory on Windows, reaching 13.21GB RSS and 47.17GB virtual memory commit on a machine with 42.56GB total RAM.
Environment
- Runtime: Bun Canary v1.3.9-canary.51 (d5628db2) Windows x64 (baseline)
- OS: Windows 11 (MINGW64_NT-10.0-26200 3.6.3)
- CPU: SSE4.2, AVX, AVX2
- Machine RAM: 42.56GB
Diagnostic Output
Elapsed: 347852ms | User: 35265ms | Sys: 21281ms
RSS: 13.21GB | Peak: 13.21GB | Commit: 47.17GB | Faults: 3758826 | Machine: 42.56GB
Features: Bun.stderr Bun.stdin(2) Bun.stdout(3) abort_signal(20) fetch(87) jsc spawn(73) standalone_executable process_dlopen yaml_parse(19)Key Observations
- RSS: 13.21GB — extremely high for a CLI tool
- Commit: 47.17GB — exceeds total machine RAM, causing heavy swap pressure
- Page Faults: 3,758,826 — indicates constant disk I/O due to memory pressure
- Elapsed vs User time: 347s vs 35s — ~90% of time spent waiting on I/O/swap, not computing
- fetch(87), spawn(73): High number of network requests and subprocesses during the session
Expected Behavior
Memory usage should remain reasonable (< 1-2GB) even during extended sessions.
14 Comments
Additional Impact: System-wide instability
This memory consumption also causes other applications to become unresponsive. For example, Opera browser stops functioning when Claude Code's memory usage spikes.
This is expected given that the process commits 47.17GB of virtual memory on a 42.56GB machine — Windows is forced to aggressively page out other applications' memory to disk, causing system-wide memory starvation.
This elevates the severity from a simple resource leak to a system stability issue.
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Impossible to help you when you leave the single most critical piece of information out of your report... the version of claude code this occurs on.
Claude Code version: 2.1.39 (auto-update enabled)
This issue occurs repeatedly when using Opus 4.6. Never experienced this with Sonnet — the memory consumption only became severe after switching to Opus 4.6.
I won't have instructions for this, so, good luck... I'm sure they're out there, but... downgrade. 2.1.39 has a bug on linux systems that does something similar during launch. 2.1.39 is from the
latestbranch. You wantstablewhich is v 2.1.29. Again, I wish I could help with the OS specific approach to this, but shifting to a non-breaking build would be where I'd start.Thank you, I saw others has the same issue I hope they fix it as soon as possible.
there's effectively zero realistic difference between whatever is
latestand the laststablebranch. You don't have to rely on "hope". Just use a different version.bro just calm down, I know what you mean I'm using the latest version and getting updates automatically. So I won't use the stable version and I'll hope.
I'm experiencing the same issue on Windows 10.0.26100.7840 with Claude Code v2.1.41
My symptoms:
Full crash log:
"claude"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(46) fetch(180) jsc spawn(217) standalone_executable proc
ess_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: stream" "node: timers/promises" "node:tls" "node:tt
y" "node:url" "node:util" "node:zlib" "node: worker_threads" "undici" "ws" "node:http2"
Elapsed: 784286ms | User: 93843ms | Sys: 49906ms
RSS: 20.52GB | Peak: 21.39GB | Commit: 0.07TB | Faults: 8631806 | Machine: 34.28GB
panic(main thread): Illegal instruction at address 0x7FF60CC90CFB
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_26d2fefbmgEuhogC2vms2C0qyqtC67gnxCmq/mxCgj1mxCyr3j78215sCy1wniD_A3s//B2vmk5M
Still hitting this on latest stable (Claude Code v2.1.69, Bun 1.3.11, Windows 11 Pro 10.0.26200).
Crash manifests as an OOM panic during HTTP/SSL operations after extended sessions with heavy context (large file reads, long diffs). Bun crash report: https://bun.report/1.3.11/e_1548644amgkgEuhogCovrpfuhpwMm3q8U8ky8Uov+s1B8k5w1Biw+j4Bqn5/3B6h3/3Bu5g5W4oyuRCYKERNEL32.DLLut0LCSntdll.dll4oijBA9
Stack trace shows memory allocation failure → async HTTP callback → progress update → SSL data handling → event loop. Machine has plenty of RAM — this is JSC heap pressure, not system OOM.
Workaround:
BUN_JSC_maxHeapSize=4096as a user env var delays the crash but doesn't fix it. Please un-stale — still reproducible on latest.<img width="1476" height="430" alt="Image" src="https://github.com/user-attachments/assets/9672280d-92d1-457a-a537-a83103a070e1" />
Having the same issue here - multiple Claude instances left running for 8+ hours result in a total commit memory
usage of 70GB+.
I am also having crashes on Windows Server 2022, using Sonata 4.6.
Claude Code crashed with an illegal instruction panic after a very long session.
Crash output: Bun v1.3.11 (dea015ec) Windows x64 (baseline)
Windows v.win10_cu CPU: sse42 avx avx2 avx512 Args: "C:\Users\mikefarace\.local\bin\claude.exe" Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(126) fetch(1768) jsc spawn(382) standalone_executable process_dlopen(2) Elapsed: 268850585ms | User: 426859ms | Sys: 107859ms RSS: 8.06GB | Peak: 8.13GB | Commit: 17.28GB | Faults: 21862375 | Machine: 17.18GB panic(thread 69272): Illegal instruction at address 0x7FF63DECF90 Environment:
Observations:
Likely cause: Long-running session accumulated memory beyond physical RAM capacity, leading to memory corruption and an illegal instruction fault.
Steps to reproduce: Long-running session with heavy tool use on a machine with ~17 GB RAM.
Additional context:
Claude Code has automatic context compaction, which should compress prior messages as the conversation approaches context limits. Despite this, the process RSS grew to 8.06 GB over ~74 hours, suggesting either:
This suggests compaction may need to be paired with periodic memory reclamation (e.g., process.gc() or heap trimming) to be effective at preventing OOM crashes on long-running sessions.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.