Memory-pressure reaper (2.1.193+) silently kills active background tasks — "idle" detection ignores child-process activity, and the kill is indistinguishable from a manual stop

Version: 2.1.198 (macOS 26.5, Apple Silicon)

Summary

Since v2.1.193 ("Added automatic memory-pressure reaping for idle background shell commands"), a long-running background Bash task (run_in_background: true) that is actively working can be killed mid-run. In my case: a Node orchestrator script that spawns a vitest child and drives ~4-4.5 hours of sequential live-API test turns. It was killed ~35 minutes in. The run has no resume; the whole night's work was lost.

Why "idle" detection is wrong here

The orchestrator writes its output to its own archival log file, so the background task's stdout goes quiet right after kickoff. But the process tree was fully active: the node parent was orchestrating, its vitest child was consuming CPU and making continuous network calls, and log files on disk were being written every few seconds. If idleness is inferred from task stdout, any well-behaved daemon-style script that logs to a file instead of stdout is classified as idle. Idleness should consider the child process tree (CPU time, running children), not just the stdout pipe.

Why the silent kill made diagnosis expensive

The task notification reported status killed / "Background command was stopped" — byte-identical to a manual TaskStop. There is:

• no log line or task-result annotation saying a memory-pressure reap fired,
• no notification to the user,
• no documented threshold or definition of "idle" in the release notes.

Ruling out everything else (OS jetsam events, crash reports, sleep, CLI restart, accidental manual stop) took an hour of forensics before the changelog entry surfaced as the only remaining mechanism. Users who have run the same overnight task for months will reasonably conclude the harness is unreliable.

Asks (any subset would help)

1. Make it opt-in, or at minimum exempt background tasks whose process tree has recent CPU/child activity — reap genuinely orphaned shells, not working ones.
2. Attribute the kill: the task result and notification should say "reaped due to memory pressure (idle Ns)" so it's distinguishable from a manual stop.
3. Document the idle definition, the memory-pressure trigger, and CLAUDE_CODE_DISABLE_BG_SHELL_PRESSURE_REAP=1 somewhere findable (the flag currently only appears in the release note).

Workaround that worked: CLAUDE_CODE_DISABLE_BG_SHELL_PRESSURE_REAP=1 in settings env.