[BUG] remote-control mode SIGTERMs its own background Bash tasks ~30-90s after launch (sender confirmed via siginfo)

Summary

In --remote-control mode, the claude process SIGTERMs its own Bash-tool background tasks (run_in_background: true) ~30–90 seconds after launch, while the session is still active and no user stop was issued. Confirmed with a kernel-level signal trace: the SIGTERM sender PID is the session's own claude process.

Related: #25188 (closed as duplicate), #22882 (closed NOT_PLANNED). Both describe background-task cleanup on session end/compaction. This report adds hard evidence of the sender and shows the kills also happen mid-session in remote-control mode, repeatedly, on a live conversation.

Environment

• Claude Code 2.1.216, Linux x86_64 (GCP VM, Ubuntu, kernel 6.17)
• Session launched as claude --remote-control <name> --session-id <uuid> inside tmux (persistent session, driven from the claude.ai app)
• Long-lived conversation that had been auto-compacted earlier (large context)

Evidence

Python canary launched via the Bash tool with run_in_background: true, blocking in signal.sigtimedwait to capture siginfo:

13:56:44 canary start pid=390780 pgid=390780 sid=390760
13:57:14 alive
13:57:15 GOT signal=15 FROM pid=1044 uid=1001
         cmd=claude --remote-control claude1 --session-id 5a7df6c7-… --dangerously-skip-permissions

pid 1044 is the claude process hosting the very session that launched the task. Over one afternoon this killed: 2 full Playwright e2e runs (25 min expected, killed at 11s and ~100s), a shell canary (SIGTERM at 78s), the python canary above (31s), and ~24 consecutive 15s-poll watcher loops — each new background task died ~30–90s after launch. The task wrapper .output files are empty (a trailing echo EXIT=$? never ran), i.e. the whole process group is TERM'd, not just the child.

Ruled out: OOM (no oomd/earlyoom, nothing in dmesg), other sessions (only idle ones present), user action (no stop issued), cron/system services.

Pattern

• Kills land shortly after an assistant turn completes; a 12-minute background run survived earlier in the same session while the remote client was actively connected.
• Strongly correlated with remote-client idle/reconnect and/or post-compaction cleanup in a large session — matches the #25188 mechanism, but firing repeatedly mid-session rather than only at session end.

Expected

Background tasks launched with run_in_background: true should survive at least until the session ends, or there should be a way to exempt a task from cleanup (the persistent: true proposal from #25188).

Workaround

Launch outside the tracker: setsid nohup <cmd> & — the detached process is untouched (a 25-minute test suite completed fine this way while tracked watcher tasks kept being reaped alongside it).