Cross-session message delivery kills the recipient session's in-flight background Bash tasks

Summary

In a multi-session setup (several interactive Claude Code sessions on one machine, coordinating via cross-session messaging), delivering a message to a session appears to kill that session's in-flight background Bash tasks. The session itself survives; its tracked background tasks (long-running CLI subprocesses) are terminated as a unit. The sender's own background tasks likewise die when replies are delivered back to it.

This silently killed long-running background jobs across four sessions, six separate times in ~90 minutes, and was hard to diagnose because it looks like a random external process killer.

Environment

• Claude Code 2.1.252 (terminal), macOS 26.5.1 (Apple Silicon, 24 GB)
• 4 interactive sessions on one machine, same project, messaging each other via the cross-session agent-messaging feature
• Each session runs long-lived background Bash tasks (CLI subprocesses taking 5–30 min)

Observed behavior

• Six kill events over ~90 min. In every event, the background tasks of exactly the session(s) that had just been sent a cross-session message (0–3 min earlier) were terminated. Broadcast batches to 3 sessions produced multi-session wipes; single messages produced single-session wipes. The coordinator's own background watcher task died at the moment several replies were delivered back to it.
• A 10-second-resolution ps sampler captured two events: a total wipe of every tracked background subprocess across all sessions within ~20 s, split into two ~10 s sub-waves (consistent with per-recipient delivery order), and an identical second wipe ~8 min later.
• Kill signature: crosses process groups, parent shells, and working directories simultaneously — inconsistent with a PGID signal, parent-cascade, or OOM. nohup-detached/disowned processes survive every event; only harness-tracked background tasks die. No user input was delivered to the affected sessions at kill time (verified: one session received the kill while a system notification confirmed no human input since the last user message).
• Ruled out by testing: user interrupts (user confirmed not present at several events), jetsam/memory kills (no memorystatus records in log show), cron/launchd, same-subprocess-account contention (controlled A/B experiment), any pkill/TaskStop by the sessions (verbatim command audits of all four sessions).

Expected behavior

Inbound cross-session messages should queue for the recipient without interrupting it in a way that terminates its in-flight background tasks — or, if task termination on wake is intended, it should be documented and the task result should say why it was stopped.

Repro sketch

1. Session A: run a long background Bash task (run_in_background), e.g. a 10-minute CLI job.
2. Session B: send A a cross-session message while A is idle (between turns) or mid-turn.
3. Observe A's background task state. In our environment it is reported "stopped"/killed shortly after delivery, while a nohup-disowned control process survives.

Happy to provide the sampler logs and the per-event timeline privately (also submitted via /feedback from the affected machine).