Extreme memory consumption on Windows (13GB RSS, 47GB commit) with Bun Canary

[arikusi]

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.

[arikusi]

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.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Memory leak in windows #24827
2. Segmentation fault crash on Windows x64 (Bun Canary v1.3.9-canary.51) #24378
3. # [BUG] Extreme memory and CPU usage on WSL2 causing system instability #18048

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

[briankelley]

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.

[arikusi]

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.

[briankelley]

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 latest branch. You want stable which 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.

[arikusi]

Thank you, I saw others has the same issue I hope they fix it as soon as possible.

[briankelley]

there's effectively zero realistic difference between whatever is latest and the last stable branch. You don't have to rely on "hope". Just use a different version.

[arikusi]

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.