# Arm the deadline before the tool returns

A coding provider can finish perfectly and still leave its user stranded.

The public `1.7.0rc9` acceptance run asked Claude Code to build a bounded C11
stack. Claude returned successfully after 132.8 seconds. The harness compiled
and ran the project independently. Then the parent conversation stopped moving:
no final answer, no approval, and no composer.

RC9 already contained a 90-second deadline for the model call that settles a
native provider result. The small tests passed. The real Work Room did not see
that deadline. The mistake was temporal: provider identity was discovered only
after the hosted tool path returned. Plugins and event observers are allowed to
normalize the in-memory call while that path runs, so a safety property derived
after execution was weaker than the durable fact recorded by execution itself.

We considered putting a larger timeout around the release harness. That would
only make the test stop sooner; it would not restore the user's conversation.
We also considered relying on the original call object and adding more logging.
That would make the same ordering assumption easier to diagnose, not correct.

The parent deadline is now armed from the model decision before provider work
starts. At the next iteration, Core also checks the durable trace for a completed
`codex` or `claude_code` tool result since the latest model call. Either fact is
enough to bound settlement. The trace records the applied timeout so a hosted
acceptance run can prove the safety boundary was active, rather than infer it
from elapsed wall time.

The first installed-wheel smoke refined the boundary again. Claude returned,
the parent quickly called `glob`, then the following model response requested
another tool and stalled before that tool reached a visible execution or
approval state. The LLM calls were fast; timing only those calls could never
close the turn. Post-provider settlement is therefore terminal-only. The parent
may summarize the recorded provider result, but it cannot open a new outer tool
chain. One attempted tool batch is discarded with a final-only reminder; a
second attempt fails explicitly so the Host can publish a terminal outcome and
restore the composer.

The tradeoff is deliberate: every remaining model call in that provider turn is
bounded, including the single grounded recovery attempt. A very slow but healthy
settlement may be abandoned. That is preferable to an indefinitely unusable
Work Room, and the provider result remains recorded for the retry.

Unit coverage now changes the observed ToolCall name after execution and proves
the already-armed deadline still fires. It also proves the durable trace can
re-arm the boundary while an unrelated later tool batch cannot inherit an old
provider deadline. The release claim still depends on the harder evidence: a
new public candidate must repeat the complete browser, compiler, provider,
permission, Stop, reconnect, and responsive Work Room journey.

We would revisit the 90-second value if production measurements show legitimate
settlement calls routinely need longer. We would not revisit the ordering rule:
a deadline that protects the result of a tool must exist before that result can
cross a mutable hosted path.