Let unattended-handoff survive a transient dispatch failure in its orchestrator #1984

What happened

An unattended-handoff run on a private fleet repository, scope develop, ended early at round 13 of its 20-round cap. Its first 12 rounds had worked normally, ending in 10 DONE and 2 PARKED lines. The orchestrator then tried to dispatch the round-13 picker and got the same error on three consecutive attempts:

The server-side auto mode classifier gave no verdict (error), so auto mode cannot determine the safety of Agent. This is a transient failure of the check, not a judgment about the action: a later response may get a verdict. You may try the action again once, as-is. Repeated attempts are slowed by a growing delay, and after 10 responses in a row without a verdict the turn stops.

Because the skill's loop has no defined path for a dispatch that cannot run, the orchestrator ended the run and gave the final report.

Diagnostics

• Environment: Claude Code 2.1.283 in auto mode on Linux. The orchestrator ran on Opus 5.5 (1M context), and workers ran on sonnet or opus as each pick named.
• The brief was byte-identical every time. Before the failures, the same picker brief (the verbatim text in "The Briefs") and worker brief had passed the classifier on 24 dispatches, 12 of each. So the content of the request did not trigger the failure.
• Orchestrator context was small. About 115k tokens had been used over the whole run, since the orchestrator only held one-line returns, as the skill intends. Context size is therefore an unlikely cause.
• The failure happened after roughly 6.5 hours of summed subagent run time. Each round took about 20 to 70 minutes. Two workers stopped partway while their own background tasks were still running, then resumed and reported normally. That behaviour is unrelated to this failure, but it is noted because step 4 of "The Worker" asks for foreground waits.
• No local evidence was available. ~/.claude/debug/latest was a dangling link, and the classifier runs on the server. The root cause is therefore not verified from this side. The error text describes itself as a transient failure of the check.

Assessment

This is most likely a transient failure of the Claude Code service rather than a defect in the skill. The skill does have a gap, though. "The Loop" defines the run's end states as NONE, STOP, the round cap, and the repeat stop, and none of them covers the orchestrator's own dispatch failing. So a temporary service failure ends an unattended run that could otherwise have continued hours later with no one present.

The orchestrator cannot start a fresh session for itself. Ending the run and asking the maintainer to restart it therefore does not solve the problem for a run nobody is watching.

Options

1. Bounded retry in the orchestrator. On a dispatch error that says it is transient, wait with one bounded background timer (for example 10 minutes, via a backgrounded shell command that wakes the session on exit), then re-dispatch the same brief. Give up after N waits, for example 3, and end the run with the dispatch failure named in the final report. The caveat is that the timer is itself a tool call, so if the classifier fails on every call the wait cannot start either, and this helps only against short outages.
2. Name the end state only. Add "the orchestrator's own dispatch fails" as an explicit end state with its own final-report line, so the report separates a service failure from STOP. There would be no retry.
3. No change. Treat this as a one-off outage and have the maintainer restart the run, naming the scope again per "Invocation and What It Authorizes".

The recommendation is option 1 with option 2's report line, because it keeps an unattended run alive through short outages and reports clearly when it cannot.

🤖 Generated with Claude Code