[BUG] CLI self-aborts (SIGABRT) at ~6 GB RSS during long background Workflow runs — reproduced on 2.1.160 and 2.1.161 (WSL2)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code reliably aborts itself (signal 6 / SIGABRT, "core dumped") during long-running background Workflow runs (multi-agent orchestration), once the host process reaches ~6 GB RSS — while the system has ~28 GB of free RAM and the Linux OOM-killer is never involved. Reproduced 3 times across two versions (2.1.160 ×2, 2.1.161 ×1). Each crash kills the interactive session and the in-flight background workflow.

Environment

• Claude Code 2.1.160 and 2.1.161 (2.1.161: GIT_SHA 6a550aea7c747b1b0ddd8bb61dbe199c4ad41320, BUILD_TIME 2026-06-02T01:45:55Z), native binary install (~/.local/share/claude/versions/<ver>, Bun-compiled ELF x86-64, ~243 MB)
• WSL2, kernel 6.6.87.2-microsoft-standard-WSL2, Windows 11 host
• 32 logical CPUs, 30.2 GiB RAM (MemTotal 31643772 kB), 8 GiB swap (unused)
• Workload: interactive session + one background Workflow orchestrating ~30–100 subagents over 1–3 h; subagents run Bash heavily (go build/test, git worktrees, docker compose)

Forensics already done (so you don't have to redo it)

• Deliberate abort(), not a segfault, not OS OOM: kernel register dump shows ORIG_RAX = 0xea (tgkill), RDX = 6 (SIGABRT), RIP in libc raise; no oom-kill entries in dmesg; ~28 GiB available; swap untouched.
• Core dump (5.9 GB, 16 threads): crashing thread's stack unwinds into the claude binary near the NAPI exports; deeper symbolication impossible on our side (binary exposes only 556 text symbols, no debug info, no gdb in env).
• No Zig panic banner and no bun.report URL anywhere in the 5.9 GB core (full grep -a) → not a recoverable Bun/Zig panic(); no glibc heap-corruption messages either. JSC OutOfMemoryError / out of memory strings present in process memory. Net: looks like an OOM-style hard abort in the JSC/native layer at ~6 GB despite ample system memory.
• User-facing memory knobs are dead ends (verified, not assumed):
• Binary is Bun/JSC → NODE_OPTIONS=--max-old-space-size is accepted but inert (verified by diffing BUN_JSC_dumpOptions=1 output with/without). The bundled --max-old-space-size=8192 is only applied when CLAUDE_CODE_REMOTE === "true".
• BUN_JSC_* options are live (bogus names rejected), but defaults are already unlimited: gcMaxHeapSize default 0 (no cap), forceRAMSize default 0 (real RAM ≈ 30 GB) → no user-raisable ceiling explains an abort at ~6 GB.
• The string BUN_FEATURE_FLAG_SYNTHETIC_MEMORY_LIMIT exists in the binary — if some internal/synthetic limit sits around ~6 GB for the host process, it would match the observed behavior exactly.

Related issues (checked before filing — believed NOT duplicates)

• #4953 (grows to 120+ GB then OOM-killed by the kernel): same family (host memory accumulation in long sessions) but different failure mode — ours self-aborts at ~6 GB with plenty of free RAM, no oom-kill. If the root accumulation is the same, this adds the data point that an internal ~6 GB abort fires long before system OOM.
• #64832 (~115 node subprocesses exhaust RAM on 2.1.160): multiple child processes → system OOM; ours is a single process aborting internally.
• #60215 (Bun segfault on Linux): segfault with a panic banner at 0.22 GB RSS; ours is a panic-less abort at 5.9 GB.

What Should Happen?

• The CLI should not self-abort at ~6 GB RSS on a 30 GB machine. Long background Workflow runs should be able to use available memory, or be bounded gracefully.
• Subagent transcripts/state from completed agents should be released (or spilled to disk) during the run instead of accumulating in the host process for the run's lifetime.
• If an internal memory ceiling genuinely must exist, hitting it should produce a graceful degradation (pause the workflow, checkpoint, surface a clear error to the user) and a clear fatal message — not a silent SIGABRT that kills the interactive session and the in-flight run.

Error Messages/Logs

**Kernel log**

[Wed Jun  3 00:20:37 2026] 2.1.160: claude: potentially unexpected fatal signal 6.
[Wed Jun  3 00:21:48 2026] 2.1.160: claude: potentially unexpected fatal signal 6.
[Wed Jun  3 00:21:48 2026] WSL (CaptureCrash): Capturing crash for pid: 1093, executable: !home!crash!.local!share!claude!versions!2.1.160, signal: 6, port: 50005
[Wed Jun  3 12:12:33 2026] 2.1.161: claude: potentially unexpected fatal signal 6.
[Wed Jun  3 12:12:33 2026] WSL (CaptureCrash): Capturing crash for pid: 1044, executable: !home!crash!.local!share!claude!versions!2.1.161, signal: 6, port: 50005

Three WSL crash dumps preserved under `%LOCALAPPDATA%\Temp\wsl-crashes\` (5.9 GB ELF core analyzed; dumps contain private project data — available selectively on request).

Steps to Reproduce

Reproduction pattern (3/3 crashes)

1. Launch a long background Workflow (dozens of subagents, hours of wall-clock).
2. Host claude process RSS grows steadily as the run progresses.
3. At ~6 GB RSS the process aborts (SIGABRT). Early identical phases pass fine; the crash correlates with process age / cumulative memory, not with a specific operation (in our runs it always lands on a late "integration" phase that captures larger tool outputs).
4. Restart + resume works; the next run advances further and aborts again at the same ceiling.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.161

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_