Headless -p session leaks to 10-15GB RSS while idle on long-running background Bash tasks (v2.1.205, Linux)

Summary

Headless (-p) sessions on v2.1.205 intermittently leak to 10–15GB anon RSS while the session is idle-waiting on a long-running background Bash task. On an 18GB Linux server this swap-thrashed the machine (load avg 68, sshd/tailscaled unresponsive) until the kernel's global OOM killer intervened — twice in one afternoon.

Environment

• Claude Code 2.1.205 (native installer, ~/.local/share/claude/versions/…)
• Ubuntu Linux, kernel 7.0.0-27-generic, 18GB RAM, headless
• Sessions spawned as:

claude --agent <custom-agent> -p "<prompt>" --model <model> --max-turns <N> --dangerously-skip-permissions --output-format stream-json --verbose, stdout piped through tee to a log

• Several such sessions run concurrently (autonomous worker fleet)

What happened

Kernel log, two kills ~30 min apart (process comm is the CLI's retitle to its version string):

Out of memory: Killed process 2284641 (2.1.205) total-vm:14939048kB, anon-rss:10436836kB ...
Out of memory: Killed process 2295138 (2.1.205) total-vm:21231208kB, anon-rss:15693456kB ...

Both processes were claude CLI sessions. RSS grew from a normal ~0.5GB to 10GB+ within roughly 15–25 minutes.

Why this looks like a CLI leak, not workload

• The killed session's transcript .jsonl was 726KB; its background-task .output files were ~1MB. Nothing session-side is within orders of magnitude of the heap size.
• Healthy sessions running the identical workload sit at 0.3–0.5GB stable.
• The same fleet/workload ran v2.1.203/v2.1.204 for the two days prior with zero OOM events in the journal. v2.1.205 was auto-installed the evening before both incidents.

Trigger pattern (both incidents)

In both cases the session's last activity before ballooning was launching a long-running Bash tool call with run_in_background: true and then sitting idle waiting on it:

• incident 1: a polling script (… --max-wait 2700) run as a background task (~45 min expected runtime)
• incident 2: a docker build --no-cache + test run as a background task

So the suspect area is background-task output polling / stream buffer retention while the session is otherwise idle. It is intermittent — ~20 comparable sessions since (same version, same background-task pattern) have not reproduced it, so timing/output conditions seem to matter.

Workarounds in place

Cgroup memory caps (systemd-run --user --scope -p MemoryMax=…) + an RSS watchdog; sharing in case it helps others hitting mystery host freezes with worker fleets.