Per-tool-call helper process (claude.exe) leaks to 11.6GB anon RSS and is OOM-killed during a slow sandboxed Bash command

Status Closed — duplicate
Reported on v2.1.226
Maintainer reply None cached
Activity 3 comments · opened Aug 17, 2026 · closed Aug 17, 2026

What's Wrong?

During normal interactive use, an ephemeral per-tool-call helper process (comm claude.exe — the CLI binary before it sets its process title) ballooned to 11.6 GB anonymous RSS in ~2 minutes and was OOM-killed by the kernel at the container's 12 GB cgroup ceiling. The interactive session itself stayed small and healthy (~430 MB RSS) — only the helper leaked.

This has now happened twice on two different Claude Code versions (2026-08-13 on a ~2.1.226-era build, 2026-08-17 on 2.1.233), so it is not a regression introduced by a single release.

In both cases the helper was spawned alongside the shell pipeline of a sandboxed Bash tool call. In the 2026-08-17 case the triggering command is known precisely: a long-running grep -o -i with bounded-repetition regex ([^"]\{0,200\}...[^"]\{0,300\}) over ~13 MB JSONL files containing lines up to 1.2 MB, piped to head -8. The command was slow (hit the 2-minute Bash tool timeout, exit 143); while it ran, the helper's anon memory grew ~100 MB/s until the OOM kill. The grepped files total under 14 MB, so the 11.6 GB cannot be explained by the command's own data — the allocation happened inside the helper.

Side effect worth noting: because the session ran inside a systemd service's cgroup with default OOMPolicy=stop, the kernel kill also stopped the parent service (Restart=always recovered it). Harmless here, but the helper's blast radius extends to whatever unit contains the session.

Possibly related: on the same host, sandboxed Bash calls intermittently fail immediately with:

apply-seccomp: write /proc/self/uid_map: Operation not permitted

(This host is itself an unprivileged LXC container, so nested user-namespace setup is restricted — the sandbox works some of the time and fails at other times within the same session.)

What Should Happen?

Per-tool-call helper processes should stay bounded (or at least be killed/recycled by the CLI when they exceed a sane ceiling), and a slow/timeout-bound sandboxed command should not cause unbounded memory growth in the wrapper shepherding it.

Error Messages/Logs

Kernel OOM record, 2026-08-17 01:58:03 UTC (host is a Proxmox node; the session runs in an unprivileged LXC with a 12 GB memory limit):

kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0,oom_memcg=/lxc/106,task_memcg=/lxc/106/ns/system.slice/claude-launch.service,task=claude.exe,pid=2385553,uid=100000
kernel: Memory cgroup out of memory: Killed process 2385553 (claude.exe) total-vm:12915576kB, anon-rss:11639608kB, file-rss:4kB, shmem-rss:0kB, UID:100000 pgtables:23120kB oom_score_adj:0

Task dump at kill time (excerpt) — the interactive sessions are the two claude rows and are healthy; the leaked helper is the claude.exe row sitting next to the bash/head remnants of the timed-out pipeline:

[2236332] ... 110906 rss ... claude        <- interactive session A (~433 MB, survived)
[2236354] ...  61102 rss ... claude        <- interactive session B (~239 MB, survived)
[2385549] ...     88 rss ... bash          <- Bash tool call (outer)
[2385551] ...     89 rss ... bash          <- Bash tool call (inner)
[2385552] ...     27 rss ... head          <- the `| head -8` of the pipeline
[2385553] ... 2909903 rss ... claude.exe   <- leaked helper, 11.6 GB anon, killed

Prior occurrence, same signature (from our OOM monitor): 2026-08-13T02:50:03Z CT 106: 1 killed (claude.exe ×1).

Steps to Reproduce

Not deterministic, but both occurrences match this shape:

  1. Interactive Claude Code session (launched inside a systemd unit / tmux) on an unprivileged Debian 12 LXC, npm global install, node v22.
  2. Session runs a sandboxed Bash tool command that is slow enough to hit the 2-minute tool timeout — in the confirmed case, a case-insensitive bounded-repetition grep -o over JSONL files with ~1 MB lines, piped to head.
  3. While the command runs, a claude.exe helper process (child of the tool call) grows anonymous memory at ~100 MB/s until the cgroup OOM-kills it.

Environment

  • Claude Code Version: 2.1.233 (also observed on the version current as of 2026-08-13)
  • Platform: Linux — Debian 12 unprivileged LXC on Proxmox VE 9, cgroup v2, 12 GB memory limit
  • Install method: npm global (/usr/local/lib/node_modules/@anthropic-ai/claude-code), node v22
  • Model: claude-opus-5
  • Regression: No — observed across at least two versions

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗