Per §3.1 cancel a pending tool execution, aborting the signal passed to executeTool() removes the pending execution and rejects the caller's promise with the abort reason; the tool's own resolution is discarded.
Verified in Chrome 152 and again in Chrome 153: the caller gets AbortError with no cause, and the tool's own resolution is discarded.
Why it matters
For a long-running tool that applies changes incrementally (a batch edit landing item by item), the caller cannot learn what was applied before the abort. Partial progress is structurally unreportable on the caller's abort path, even though the tool knows exactly what it did.
This is not hypothetical for us. A sweep across a document is stoppable mid-run by design, and the agent has to be able to say what landed, or the person is left to diff the document by eye.
What we had to do instead
A page-owned AbortController, combined with the caller's via AbortSignal.any() when execute receives one, so the tool resolves normally with a CANCELLED payload carrying applied / remaining / stoppedBy. This works around the reporting gap; it is not a substitute for cancellation itself.
Correction (2026-09-12). An earlier revision of this section claimed that a tool cannot observe the caller's abort at all, and split this issue around that. That described Chrome 152, not the spec: the draft passes ToolExecuteCallbackOptions.signal to execute, Chromium threads it in CL 8025300, and on Chrome 153 the signal arrives and a loop that checks it stops partway. Thanks to @mysticalseeker24 for measuring the 152 behaviour and to @mlmrx for pointing out on #308 that it was implementation lag rather than a spec gap. On a build without the signal the loop runs to completion while the caller receives AbortError, which is worth knowing while 152 is still in use, but it is not what this issue asks the spec to change.
Proposal
Allow execute to observe signal.aborted, finish promptly, and have that settled value delivered to the caller. Two shapes that would both work:
- reject with an
AbortError whose cause carries the tool's result, or
- resolve if the tool settles within the same task as the abort.
Either keeps cancellation semantics, since the caller still learns it was aborted, while making partial progress reportable.
Notes from the build: https://github.com/minjikim89/redline/blob/main/docs/findings.md · live: https://minjikim89.github.io/redline/
Per §3.1 cancel a pending tool execution, aborting the
signalpassed toexecuteTool()removes the pending execution and rejects the caller's promise with the abort reason; the tool's own resolution is discarded.Verified in Chrome 152 and again in Chrome 153: the caller gets
AbortErrorwith nocause, and the tool's own resolution is discarded.Why it matters
For a long-running tool that applies changes incrementally (a batch edit landing item by item), the caller cannot learn what was applied before the abort. Partial progress is structurally unreportable on the caller's abort path, even though the tool knows exactly what it did.
This is not hypothetical for us. A sweep across a document is stoppable mid-run by design, and the agent has to be able to say what landed, or the person is left to diff the document by eye.
What we had to do instead
A page-owned
AbortController, combined with the caller's viaAbortSignal.any()whenexecutereceives one, so the tool resolves normally with aCANCELLEDpayload carryingapplied/remaining/stoppedBy. This works around the reporting gap; it is not a substitute for cancellation itself.Correction (2026-09-12). An earlier revision of this section claimed that a tool cannot observe the caller's abort at all, and split this issue around that. That described Chrome 152, not the spec: the draft passes
ToolExecuteCallbackOptions.signaltoexecute, Chromium threads it in CL 8025300, and on Chrome 153 the signal arrives and a loop that checks it stops partway. Thanks to @mysticalseeker24 for measuring the 152 behaviour and to @mlmrx for pointing out on #308 that it was implementation lag rather than a spec gap. On a build without the signal the loop runs to completion while the caller receivesAbortError, which is worth knowing while 152 is still in use, but it is not what this issue asks the spec to change.Proposal
Allow
executeto observesignal.aborted, finish promptly, and have that settled value delivered to the caller. Two shapes that would both work:AbortErrorwhosecausecarries the tool's result, orEither keeps cancellation semantics, since the caller still learns it was aborted, while making partial progress reportable.
Notes from the build: https://github.com/minjikim89/redline/blob/main/docs/findings.md · live: https://minjikim89.github.io/redline/