v2.1.227: headless `claude -p` process non-deterministically balloons to 14–15.6 GB RSS (~60 MB/s) during a single generation turn

Environment

• Version: 2.1.227 (Claude Code), native binary (claude.exe via npm package)
• Install: npm global, nvm Node v22.12.0
• OS: Amazon Linux 2023, kernel 6.1.131, x86_64 (EC2, 30 GB RAM)
• Auth: Max plan
• Mode: headless — claude -p --model opus --allowedTools WebSearch WebFetch Read Write < prompt.txt

Summary

Since auto-updating to 2.1.227 (2026-08-11 11:26 UTC), headless -p runs of a long-standing batch pipeline non-deterministically balloon in RSS at ~60 MB/s until they exhaust the machine (or hit a cgroup cap when we added one). The first-ever occurrence was 13 minutes after the auto-update; the same pipeline had run hundreds of identical batches on the previous version with zero incidents. On 2.1.227 we've seen 2 balloons in ~75 batches (~3%).

What the pipeline does

Each batch is a fresh claude -p process (typical lifetime 3–4 min, RSS ~390 MB): it Reads a ~24 KB prompt file, does some WebSearch/WebFetch lookups, Writes a small JSON result, exits. Batches run strictly one at a time.

Occurrence 1 — 2026-08-11 11:39 UTC (fatal)

• 11:39:13 process start; 11:39:20 Read of the 24 KB input file.
• Then a single generation turn with no tool calls for ~4 minutes, during which RSS grew to ~14 GB (kernel OOM dump at 11:43:42 — that's ~60 MB/s).
• The bloated process remained functional (it performed WebSearch calls at 11:43:48 and 11:51:45) and reached 15.6 GB RSS, while the kernel OOM killer — with claude at oom_score_adj 0 — killed unrelated production services instead; the host ended up rebooting twice.
• No large payloads anywhere: input 22–24 KB, tool results ~2 KB.

Occurrence 2 — 2026-08-11 17:02 UTC (contained)

After the first incident we wrapped each batch in a systemd scope (MemoryMax=8G, MemorySwapMax=0). A second batch ballooned the same day: it saturated the cap, took 34.5 min wall-clock with only ~4 min of CPU (the host thrashed: page cache evicted, swap storm, load 59 on 4 vCPU, SSH logins hung), and still completed successfully with a valid result — so the runaway allocation doesn't even correlate with a wrong answer.

Non-determinism

• Re-running the exact same batch (same prompt file, same flags) completed normally: ~390 MB RSS, 3 min.
• 2 balloons out of ~75 batches on 2.1.227; 0 out of hundreds on the prior version (same prompts, same flags, same machine).

What we have if useful

• The full headless session transcript (.jsonl) of occurrence 1, and the kernel OOM dumps with per-process RSS at two points in time (which is where the ~60 MB/s growth rate comes from).
• Happy to share both privately.

Workarounds we applied (in case they help others)

• systemd-run --scope -p MemoryMax=4G -p MemorySwapMax=0 -p RuntimeMaxSec=1800 around each headless run.
• DISABLE_AUTOUPDATER=1 for the batch environment to keep the runtime version a deliberate choice.