[BUG] Auto-update daemon transition reaps a live session's in-flight headless background tasks (status 'killed', no attribution) — Linux, 2.1.210→2.1.211

Environment

• Claude Code on Linux, native install
• A long-lived daemon-managed background session (agents view job), process running v2.1.210
• Auto-update installed v2.1.211 while the session was mid-work

What happened

Two background tasks spawned by the session's Bash tool (each a timeout 5400 claude -p --model sonnet ... headless run, launched with run_in_background) were killed 1-3 minutes after launch, with task status "killed", zero bytes of output, and no TaskStop issued by the session. A third identical launch the next morning completed normally.

Forensic timeline (all times local):

• 02:07 first headless task launched
• 02:10 the auto-updater finished installing the v2.1.211 binary (~/.local/share/claude/versions/2.1.211 mtime is exactly 02:10)
• ~02:10 first task killed; 02:10-02:11 second task launched
• 02:11:10 daemon log: [supervisor] another daemon is already running (pid=..., version=2.1.211, origin=transient; an on-demand daemon never displaces a running one) followed immediately by [bg] bg orphan-spare reap: 1
• ~02:12 second task killed
• No OOM (plenty of free memory), no timeout (both tasks were minutes into a 90-minute budget), nothing in the system journal

Collateral pattern: the session itself and a long-running Monitor task (armed hours earlier) survived untouched. Only the freshly-spawned headless child processes died. An ephemeral, never-requested task also flashed in and out of the session's task directory during the same window, which I take to be the updater/daemon machinery itself.

Reading

During the auto-update daemon transition, the new (or surviving) daemon's orphan/spare reaping appears to sweep up in-flight claude -p child processes that belong to a live session's background tasks, treating them as orphans. The session gets a "killed" task notification with no attribution, which reads exactly like the unexplained kills in #76249.

Related, but not the same shape: #73670 (supervisor shuts down for auto-upgrade and never restarts, workers watchdog-killed), #66358 (post-update version skew orphans old workers), #73332 (workers reaped mid-work on macOS). In our case the daemon transition itself went fine and the session survived; the casualties were the session's own in-flight headless child tasks.

Expected

In-flight background tasks owned by a live session should survive an auto-update daemon transition (or at minimum be terminated with an attributable reason surfaced to the session, so the agent does not have to forensically reconstruct what killed its work).

Suggestion

• Exempt processes that are registered children of live session tasks from orphan-spare reaping during the update transition, or
• Hand them over to the new daemon the way adopted sessions are, or
• If they must die, deliver a task notification that names the updater/daemon transition as the cause.