Background Bash task (run_in_background) SIGTERM'd by harness stop path with no user action, correlated with macOS memory-pressure warning

Environment

• Claude Code 2.1.246, native installer, macOS (Darwin 25.5.0), interactive terminal session
• Model: claude-fable-5

What happened

A run_in_background: true Bash task (a long-running deploy-watch shell script that polls gh run watch) was terminated after 17m29s with no user action (user explicitly confirms they did not stop it, no TaskStop tool call was made, no /tasks kill).

Evidence collected from the task output file and system logs:

1. The task's output file ends with the harness marker [killed] — the marker style the harness writes on its own stop path (normal completions in the same session end with [exited with code N]).
2. The whole process group received SIGTERM: bash printed Terminated: 15 for its gh run watch child, AND the parent script's TERM/EXIT trap ran (it released a lock ref). The child was wrapped in set +e … set -e, so a child-only kill could not have aborted the parent.
3. Ruled out: repo tooling (no pkill/killall anywhere), other local processes (cannot signal the group), macOS jetsam/memorystatus (unified log empty for the window; jetsam is SIGKILL), a runtime cap (sibling background tasks in the same session ran 13m36s and ~20m to normal completion, one of them an identical rerun of the killed command which then succeeded).
4. Correlation: the Claude desktop app's swift.log recorded Memory pressure transition: warning at kill+1 second, and its main.log [process-memory] line 4s before the kill showed sys_free_raw=60MB. An earlier identical pressure-warning transition (30 min prior) killed nothing.

Expected

Backgrounded tasks are not terminated by the harness without a user gesture or TaskStop; docs describe no auto-termination of backgrounded tasks.

Questions

• Does any harness path (memory pressure response, resource cap, desktop-app ↔ CLI supervision) SIGTERM background task process groups?
• What exactly does the [killed] output-file marker imply about the initiator?

Impact

The killed task was mid deploy-verification; it was recoverable only because the underlying script is idempotent. Silent kills of long-running background work are hard to distinguish from user action.

Timestamps (local, 2026-08-26): task started 10:39:22, killed 10:56:51 (17m29s); pressure warning 10:56:52; identical rerun 10:57:31 → completed successfully ~20m later.