Claude Code CLI reached ~14.6 GiB RSS and triggered a host-wide OOM kill

Version: 2.1.231 (native installer, Linux x64); still present in 2.1.232 as far as can be determined
Platform: WSL2 (Ubuntu 26.04, kernel 6.18.33.2-microsoft-standard-WSL2), 16 vCPU, 15.4 GiB RAM, 4 GiB swap
Date of incident: 2026-08-13, 23:12 UTC
Severity: The process consumed the entire VM, so the OOM was global — it took down the co-resident VS Code Remote server, not just Claude Code.

The session ID is omitted here since this is a public tracker. Happy to provide it privately if it helps you correlate server-side logs.

---

Summary

A long-running interactive CLI session grew to ~14.6 GiB resident (~18.3 GiB virtual, ~2.2 GiB swapped) over roughly 2.5 hours and was killed by the kernel OOM killer. The conversation context was small (4.37 MB transcript, 430 messages), so this was not context growth. No memory limit flags were set.

Because the binary runs on JavaScriptCore rather than V8, there was no engine-level heap ceiling to fail against — instead of a self-contained JavaScript heap out of memory crash at ~4 GB, the process grew until the kernel intervened and killed the machine's other workloads as collateral.

Kernel evidence

Out of memory: Killed process 19202 (2.1.231)
  total-vm:19194956kB  anon-rss:15314688kB  file-rss:568kB  shmem-rss:0kB
  pgtables:34924kB  swapents:583392
  constraint=CONSTRAINT_NONE, nodemask=(null), global_oom, task_memcg=/init.scope, uid=1000

comm=2.1.231 is the native binary at ~/.local/share/claude/versions/2.1.231.

From the OOM task table, the second-largest process on the machine was 22 MB. This was a single-process blowup, not memory pressure from co-resident work:

[19202] 1000 19202  4798739  3828814 ...  583392  2.1.231     <- 14.6 GiB
[ 2775] 1000  2775  5037416     5640 ...   90720  MainThread  <- 22 MB

A second Claude Code process (the VS Code extension's own copy, comm=claude) was running concurrently at 197 MB and was unaffected. Only the terminal CLI session leaked.

This is the only OOM kill in the machine's entire journal history across all boots.

Session profile

Session ran 20:37:11Z → 23:10:17Z (2h33m). Last transcript entry is ~2 minutes before the kill.

• 84 tool calls total: 48 Bash, 11 Read, 9 Edit, 3 Write, 8 ToolSearch, 3 Skill, 2 Artifact, 11 MCP
• 3 remote MCP connectors in use
• 5 plugins enabled, including playwright and a video-authoring plugin
• 4 background Bash tasks, each npx --yes hyperframes render / hyperframes browser ensure, spawning provisioned Chromium
• Several very long turns: 752s, 686s, 493s
• Working directory was a large tree in the user's home directory
• Workload: authoring and rendering a HyperFrames motion-graphics video (headless Chromium + ffmpeg)

Exactly one tool call in the session has no result — the final Bash call at 23:10:17Z — marking the moment the process died.

Causes investigated and eliminated

Listed because the negatives are probably more useful than the positives here.

| Hypothesis | Verdict | Evidence |
|---|---|---|
| Context/transcript growth | Ruled out | Full transcript 4.37 MB, 430 messages, 6 retained images totalling 1.5 MB base64 |
| Runaway tool loop | Ruled out | 84 tool calls over 2.5h, no repetition pattern |
| Large file read into memory | Ruled out | Largest Read result was 543 KB (a PNG) |
| Buffered subprocess output from renders | Ruled out | All 4 background render jobs pipe through \| tail -8 / \| tail -30; only a few lines ever reach the agent |
| The command in flight at death | Ruled out | A grep -rhiE over a 2.4 MB directory of markdown and small mp3s; no symlinks, longest line 20 KB |
| Raised heap limit masking a normal ceiling | Ruled out | No NODE_OPTIONS, no --max-old-space-size in any shell rc, profile, or environment |
| Recursive file-watcher leak on a large tree | Ruled out | Live process holds 1 inotify instance / 2 watches. Claude Code does not recursively watch the tree, so the 17,728 files created under the working directory during the session generated no watcher load |
| MCP response payloads | Ruled out | Largest MCP result 28 KB; last MCP call was 30 min before the kill |

What is not yet explained

No single allocation site could be identified from the on-disk artifacts. Transcripts record logical events, not allocations.

A comparison measurement on the current version narrows it further: a 2.1.232 session on the same machine, same working directory, doing bash/read/grep investigation work grew from 581 MB → 648 MB over 29 minutes (~2.3 MB/min). Extrapolated across 2.5 hours that is ~350 MB — roughly 40× short of the observed 14.6 GiB.

So this is not a constant background leak. It scales with something the video-rendering session did that ordinary tool-use work does not. The untested candidates, in rough order of suspicion:

1. Background-task lifecycle — 4 background Bash tasks, each spawning and provisioning Chromium; the only major subsystem exercised by the failing session and not by the comparison session
2. Repeated subprocess spawn/teardown at scale (npx invocations resolving a 712 MB package tree)
3. Work performed against a DrvFs/9p mount (/mnt/c) in the final 15 minutes — a project copy, a rebuild, and an ffprobe run, all on the Windows filesystem

Reproduction

Not reproduced. It occurred once, in the first session on this machine that used a video-rendering toolchain.

Suggested mitigation on the product side

The specific leak aside, the failure mode is worth separating from the leak: a runaway agent process taking down the entire host is much worse than the process dying alone. A self-imposed RSS ceiling that aborts the session with a diagnostic — rather than letting the kernel choose a victim — would have contained this to Claude Code and left the user's editor session alive.

As a local workaround I now launch Claude Code inside a transient systemd scope with MemoryMax=8G and MemorySwapMax=2G. That converts a global OOM into a contained one: the session dies, the VM and the VS Code server survive. It does not address the leak.

Environment detail

• Claude Code 2.1.231 native install, auto-updated to 2.1.232 the following morning
• No .wslconfig; WSL2 defaults (50% of host RAM)
• The 2.1.231 changelog contains one unrelated MCP OAuth fix, and no memory fix appears in the surrounding releases, so the defect is likely still present in 2.1.232