fix(agent-runtime): stop waiting for tools host-core cannot cancel

[liubai0106]

What

Stop now ends the turn even when the running tool cannot be cancelled, and the stop RPC always returns.

Two independent holes in packages/agent-runtime/src/runtime.ts:

1. The tool executor ignored the stop for every tool but Bash / GenerateImages. The abort listener returns immediately unless the tool is one of those two (runtime.ts:3470 on main), and tools.execute is awaited with no deadline and no race (runtime.ts:3517). One report measured a Grep running 21m39s after six Stop clicks, with the abort applying in the same millisecond it finished.

2. abort() waits for the turn settlement with no bound. It ends with await settlement (runtime.ts:9100 on main), and the settlement only resolves once the turn unwinds. A tool that never yields therefore keeps the agent.abort RPC pending forever — and the renderer awaits that RPC before it clears the running state (apps/desktop/src/stores/slices/transcript-slice.ts:501, await Promise.allSettled([api.abort(sessionId), ...])), so the session stays at "processing" even after the ledger has recorded the turn as aborted. The ledger and the UI disagree, and only a restart reconciles them.

Changes

1. The listener applies to every tool. The (!isBash && toolName !== "GenerateImages") guard is gone.
2. The wait races the signal. tools.execute is raced against an abort promise.
   • Bash / GenerateImages: still send tools.abort, then wait a bounded 10s grace window for the partial output the host collected before the kill.
   • Every other tool: abandon the wait the instant the signal fires and return TOOL_ABORTED.
3. Losing the race abandons the wait, not the host call. The orphaned tools.execute settles on its own; its result is discarded and never surfaces.
4. abort() drives the in-flight tools directly. It walks the active abort handlers and runs the same path a signal abort would, instead of relying only on the signal each tool was handed. A stop must not depend on a signal the runtime does not own: if the signal never fires, the stop is a silent no-op and abort() blocks on the settlement, which is the failure in point 2 above.

Why non-cancellable tools do not send tools.abort

tools.abort only clears a pending approval and kills a Bash / GenerateImages process — for anything else host-core answers found: false and the tool keeps running. On top of that, an abort for a call id with no active cancellation registers a 60s tombstone in pending_bash_aborts (crates/host-core/src/state.rs), which a later Bash reusing that id would inherit as an immediate kill. So the RPC cannot help the in-flight call and can only hurt a retry, which matches the note in the issue: send tools.abort for Bash/image tools as today, rely on the local race for the rest, and require a distinct id on retry.

Docs

• docs/adr/tool-abort-abandons-host-call.md — new ADR: the abandoned call keeps consuming host resources, the result is discarded, a retry must carry a fresh tool call id, and abort() releases tools itself rather than trusting the signal.
• docs/spec/03-runtime/03-tools-and-permissions.md §3 — the stop contract, including the 10s grace window for cancellable tools and the guarantee that the stop RPC returns.

Tests

packages/agent-runtime/src/runtime.test.ts:

• ends the turn when a stop lands while a tool host-core cannot cancel runs — a Grep whose host call never resolves rejects with TOOL_ABORTED, no tools.abort is sent, and the orphaned call settling later produces no second result.
• stops waiting for a Bash call that ignores tools.abort once the grace window closes — a hung Bash sends tools.abort and rejects with TOOL_ABORTED when the 10s window closes.
• releases an in-flight tool when the stop lands without the tool signal firing — abort() ends a pending Grep whose signal is never aborted, and the signal is still un-aborted afterwards, so the release came from abort() and not from the signal.

332 tests pass in runtime.test.ts, as do pnpm typecheck, pnpm lint, pnpm check:pr-base, and pnpm check:agent-policy.

No E2E scenario: it needs a tool that reliably runs longer than the test budget, and no built-in tool can be made to hang on demand without a host-core fixture.

Residual

A non-cancellable tool keeps running in host-core after the stop. That is real work, not a stuck UI, and the durable fix stays on the Rust side — teach tools.execute an abort token so Grep and friends can actually be cancelled. A Grep that can run 21 minutes is worth filing on its own, as the issue notes.

Process-tree reclamation is a separate host-core gap: tools.abort terminates the job it owns, but a shell launcher that re-executes the real interpreter can leave the grandchild running. Out of scope here.

Fixes #1767