Daemon-adopted --reply-on-resume background fork wedges after daemon self-restart for upgrade (never starts its turn, holds bypassPermissions)

Summary

A background fork spawned by the claude daemon to answer a queued task-notification (--fork-session --resume <transcript> --reply-on-resume) wedged permanently after the daemon self-restarted for an auto-upgrade and adopted it. The worker ran for 45+ minutes with an empty transcript (2 metadata lines, zero turns), its job state frozen at "working", while holding --permission-mode bypassPermissions.

Environment

• Linux (Ubuntu, kernel 6.17), CLI versions involved: 2.1.170 → 2.1.172
• Daemon: transient origin

Timeline (from ~/.claude/daemon.log, times UTC)

1. 19:45:21.876Z daemon start version=2.1.170 (spawned by an interactive session)
2. 19:45:22.015Z [bg] bg spawned <id> (slash) — fork created to deliver a queued reply for a session whose SSH transport had just died (--reply-on-resume, model opus, bypassPermissions)
3. 19:50:55Z auto-update completes 2.1.170 → 2.1.172 (.last-update-result.json)
4. 19:51:21.937Z daemon: "binary changed — self-restarting for upgrade"
5. 19:51:22.260Z new daemon (2.1.172): bg adopt: adopted=1 respawned=0 dead=0 — adopts the v2.1.170 worker
6. For the next ~40 min: the fork's transcript stays at 2 no-timestamp metadata lines; no tool calls, no assistant turn; ~/.claude/jobs/<id>/state.json stays "state": "working". Its MCP child (a stdio server) is up, so the process tree looks healthy from outside.
7. Manual kill (SIGTERM) → daemon logs bg settled <id> (crashed) with exit 143; respawning in state.json, then idle 5s with no clients — exiting (no actual respawn happened).

Expected

The adopted fork either delivers its queued message and completes, or the adopting daemon detects a worker that has produced no turn within some grace period and kills/respawns/fails it loudly.

Actual

The fork sat in working indefinitely (45+ min observed), produced nothing, and held bypassPermissions the whole time. Nothing surfaced to the user; we found it only during incident forensics.

Notes

• The parent session's transport (SSH over Tailscale) had frozen moments before the fork was spawned — the fork may have been waiting on something tied to the dead client.
• Cross-version adoption (2.1.170 worker under 2.1.172 daemon) is the suspicious edge; can't rule out the fork was already wedged pre-adoption.
• Happy to provide scrubbed logs.