Long-running background Bash tasks are SIGTERMed (exit 143) at unpredictable times during long interactive sessions

Environment

• Claude Code 2.1.221 (interactive CLI)
• macOS (Darwin 23.6.0), zsh
• Long-lived interactive session (24h+), multiple compactions over its lifetime

Summary

Background Bash tasks (run_in_background: true) with long runtimes (10–60+ minutes: headless claude -p / codex exec subprocess runs, and even a caffeinate keep-awake) are repeatedly terminated with SIGTERM (task notification: failed with exit code 143) at unpredictable times. The user confirmed they did not kill them. This happened multiple times across two days of unattended overnight operation, killing engine runs mid-work.

Evidence that it is the harness, not the OS or the user

• Exit code is consistently 143 (clean SIGTERM), not 137 (SIGKILL).
• No JetsamEvent reports in /Library/Logs/DiagnosticReports for any kill window → not the macOS memory killer (jetsam uses SIGKILL and leaves a report).
• No crash reports (.ips) for the killed processes → not crashes.
• macOS unified log shows no trace of the signal (expected — ordinary kill() is not audited), so the sender cannot be identified from outside the harness.
• Controlled experiment: armed a canary background task (sleep 7200) immediately before a manual /compact, then compacted. The canary survived compaction — so compaction alone is not the trigger, but the kills still occur at other, unpredictable points.

Impact

Unattended multi-agent orchestration (long engine subprocesses launched as background tasks) is unreliable: runs die mid-edit, partial work has to be recovered and re-verified, and we have had to abandon background/headless operation entirely in favour of the user manually launching every long-running process in foreground terminals.

Ask

1. Document the background-task lifecycle policy: is there a maximum task lifetime, an idle-session reaper, or teardown tied to specific harness events?
2. If there is a reaper, make long-running tasks survive until completion (or make the limit configurable).
3. When the harness does terminate a background task, surface the reason in the task notification / logs — exit code 143 with no cause is currently indistinguishable from an external kill.