Bug: Workflow tool — a worker relaunched via SendMessage is never re-registered in the workflow's tracking (and the inactivity watchdog kills legitimately-silent workers)

Summary

Two symptoms of the same subsystem — the Workflow tool used for fan-out orchestration. Both make a
still-working worker indistinguishable from a dead one from the orchestrator's point of view, which
is why they are filed together.

(a) The inactivity watchdog kills legitimately-silent workers. A worker running a long, output-free
command (a full test suite, npm ci + build) is killed after ~180 s without output even though it is
making progress. Workarounds exist on our side (force a progress reporter, delegate the heavy suite to
CI), but they are conventions a worker has to remember, not guarantees.

(b) A worker relaunched via SendMessage is never re-registered in the workflow's own tracking.
When a worker stalls without dying (no API error, no watchdog message), sending it a message on its
agentId does resume it — verifiably: it continues, commits, and opens its PR. But the workflow's
internal tracking never marks that task as done. The end-of-run report shows the task as never
completed, so the orchestrator cannot distinguish "resumed and working" from "dead".

Impact

The orchestrator has to TaskStop the whole workflow and re-dispatch the remaining tasks as individual
agents, then reconcile the run manifest by hand. In the run that prompted this report, 3 of 9 tasks were
completed that way. No work was lost, but the fallback was improvised, and the workflow's final report
contradicted the actual git state (3 merged PRs the manifest never showed).

Shape of a repro

1. Launch a Workflow fan-out with ~9 tasks (waves of ~6 concurrent workers).
2. One worker stalls — no explicit error surfaced, no watchdog kill message.
3. SendMessage to its agentId. The agent resumes (visible in its own transcript) and completes its

task, pushing a branch and opening a PR.

1. The workflow's tracking never transitions that task to done — before or after the agent finishes.

Expected

Either the resumed agent's completion is picked back up by the workflow's tracking, or the workflow
surfaces explicitly that "this task's agent was resumed out-of-band and is no longer tracked" — so the
orchestrator can take over deterministically instead of inferring it from a silence that looks
identical to a crash.

Environment

• Claude Code 2.1.259, macOS (darwin 25.5.0), zsh.
• Fan-out via the Workflow tool with isolation: "worktree" agents.

Related

• #79748 — same subsystem (isolation: 'worktree' branch renaming / primary worktree left on a run

branch).