[BUG] Claude Code aborts (SIGABRT, no message) when thread/process creation fails with EAGAIN; Desktop loses live background tasks (Linux)

Summary

When creating a thread or process fails with EAGAIN (e.g. a container's cgroup pids.max or a
RLIMIT_NPROC is reached), Claude Code does not report or retry: the Bun runtime calls abort()
and the process exits with SIGABRT (exit code 134). In a mid-task run, stdout and stderr are both
empty, so the user gets no explanation and the work is lost. Under Claude Desktop the session is
"torn down with 1 live background task(s) — settling as stopped (exited)".

Reproduced deterministically with Claude Code 2.1.294 (see below).

Related, but different:

• #94462 Bun SIGABRT/SIGSEGV on startup on Ubuntu 26.04.1 / glibc 2.43, intermittent, with no limit.

Same OS here, but without a limit Claude Code started fine 10/10 times; with the limit it aborted 5/5.

• #43131 (closed) MCP servers fail with EAGAIN when spawning inside Docker containers.

Environment

• Claude Code 2.1.294 (native installer), Bun 1.4.3, Linux x64
• Ubuntu 26.04.1 LTS, glibc 2.43, kernel 6.18.15
• Railway container: cgroup v2 pids.max=1000, 4 vCPU, 7 GB RAM
• Originally observed through Claude Desktop (Linux, official apt repo) with its bundled Claude Code 2.1.284–2.1.293

Deterministic reproduction (2026-10-08, Claude Code 2.1.294 CLI)

claude runs as a dedicated, otherwise unused uid, so RLIMIT_NPROC counts only the test's own tasks.
When the limit is reached, fork/clone fail with EAGAIN, the same errno as a cgroup pids.max.
A helper of the same uid (normal limit) starts idle threads to push the uid over the limit mid-task.

| # | Scenario | Runs | Result |
|---|----------|------|--------|
| 1 | No limit, claude -p "Reply with the single word: hi" | 10 | 10× exit 0, prints hi (peak 9 tasks) |
| 2 | Same, with ulimit -u 3 | 5 | 5× exit 134, panic(main thread): abort() called (Bun crash report) |
| 3 | Control: ulimit -u 49, two Bash tool calls (sleep 25 && echo first-ok, then echo second-ok) | 1 | exit 0, both outputs reported |
| 4 | Same as 3, plus 79 idle threads started by the same uid 15 s in | 2 | 2× exit 134, 0 bytes stdout, 0 bytes stderr from Claude Code |

In the control run the first command ran as a background task, so scenario 4 is also the
"background task lost" case.

Bun's stderr in scenario 2 (trimmed):

Bun v1.4.3 (eecfd55de) Linux x64
Args: "./claude" "-p" "Reply with the single word: hi"
panic(main thread): abort() called
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

Repro script available on request.

Observed in practice (Claude Desktop + Chrome in a 1000-PID container)

Metrics sampled every 30 s from the cgroup on 2026-10-06 (UTC+3):

| Time | pids.current | Note |
|----------|--------------|------|
| 16:52:23 | 695 / 1000 | baseline (Desktop ≈ 400 threads, Claude Code sessions ≈ 50) |
| 16:52:33 | 915 / 1000 | Chrome started (≈ 188 threads) |
| 16:52:53 | 971 / 1000 | Chrome ≈ 230 threads |
| 16:52:59 | — | Desktop log: Claude Code process terminated by signal SIGABRT |
| 16:53:24 | 701 / 1000 | pids.peak=1000, pids.events max=7 (fork rejected 7 times) |

Desktop main.log on 2026-10-03 13:23 (Failed to spawn Claude Code process: ... EAGAIN also appears on 2026-09-25):

[error] Session <id> query error: Claude Code process terminated by signal SIGABRT
[info]  [CCD] Session <id> torn down with 1 live background task(s) — settling as stopped (exited)
[warn]  [CCD] refreshSdkMcpStatuses failed: Failed to spawn Claude Code process: spawn .../claude EAGAIN
[error] [GitStatusService] Failed to check git status: spawn git EAGAIN

Memory was not the cause: oom_kill=0, anonymous memory 1.4–3.3 GB of 7 GB.

Expected

• Treat EAGAIN from thread/process creation as transient: back off and retry (bounded) instead of aborting.
• If Claude Code has to exit, print a clear reason (e.g. "process/thread limit reached") instead of a bare SIGABRT.
• Desktop: mark the session's background task as failed with that reason instead of "stopped (exited)".

Actual

Immediate abort, no message, no retry; running and background work is lost.

Workaround

Keep the container's PID/thread count well below its limit (e.g. avoid starting Chrome next to running sessions).