[BUG] Background workers crash-loop under memory pressure but CLI only reports "exit 1 before init"

Summary

When the system is under heavy memory pressure, claude -p -bg "<prompt>" can fail by repeatedly spawning background workers that crash within ~10 seconds. The user-facing output only reports:

worker crashed (exit 1) — respawning…

However, the daemon log shows that the daemon already detects the actual cause: low memory. That diagnosis is not propagated into the job state or user-facing error, so the failure looks like a generic runtime or worker-init bug instead of an environmental low-RAM condition.

Environment

• Claude Code version: 2.1.197
• OS: macOS, Apple Silicon
• RAM: high-memory Apple Silicon machine
• System state during failure:
• severe memory pressure
• very low free physical memory
• compressed memory and swap active
• heavy swapouts

Steps to Reproduce

1. Put the machine under heavy memory pressure, for example by running a large Electron editor plus other memory-heavy apps until physical memory is nearly exhausted.
2. Run:

``bash
claude -p -bg "ping"
``

1. Observe the background worker crash-loop.

Interactive claude and foreground claude -p continued to work in the same environment.

Actual Behavior

The user sees only a generic crash-loop message:

worker crashed (exit 1) — respawning…

The job state reports:

{
  "state": "failed",
  "detail": "exit 1 before init",
  "template": "bg",
  "intent": "ping",
  "cwd": "<redacted>",
  "backend": "daemon"
}

But ~/.claude/daemon.log shows that the daemon has already identified low memory:

[bg] bg: low memory (151MB free) — retiring settled workers before spawning <worker-id>
[bg] bg spawned <worker-id> (shell)
[bg] bg settled <worker-id> (crashed)
[bg] bg: low memory (86MB free) — retiring settled workers before spawning <worker-id>
[bg] bg spawned <worker-id> (shell)
[bg] bg: low memory persists after shedding non-pinned — retiring pinned settled workers as a last resort
[bg] bg settled <worker-id> (crashed)

So the daemon detects the low-memory condition, but the CLI/job state does not surface it.

Expected Behavior

When a background worker fails to initialize while the daemon has detected low memory, the user-facing error should include that diagnosis, for example:

Cannot start background worker: insufficient free memory, 86 MB free.
Free up memory and retry, or run in the foreground with `claude -p`.

The daemon should also avoid respawning indefinitely into the same low-memory condition. After repeated init failures correlated with low memory, it should back off or mark the job as failed with an actionable memory-related error.

Why This Matters

The current error makes the failure look like the generic exit 1 before init / embedded runtime issue reported elsewhere, when in this case the root cause is environmental and already known to the daemon.

This makes the problem hard to diagnose for users because the actionable cause is only visible by manually inspecting ~/.claude/daemon.log.

Suggested Fix

• Propagate the daemon's existing low-memory signal into:
• the user-facing worker failure message
• ~/.claude/jobs/<id>/state.json
• any CLI status output for background jobs
• Add backoff or halt behavior when consecutive background-worker init failures occur while low memory is detected.
• Prefer an explicit failure such as insufficient_memory_before_init over the generic exit 1 before init when the daemon has that context.

Related Issues

• #59652 / #59653: similar exit 1 before init symptom, reportedly related to embedded Bun runtime in older versions. This report is on 2.1.197 and appears tied to memory pressure instead.
• #33963: broader "no memory self-monitoring / graceful degradation" issue. This report is specifically about the background-worker path and error surfacing.