ctx.signal, prevents a handler from starting after cancelled input validation, and suppresses late responses. Application work stops only if it observes the signal.
When the signal aborts
- A stdio
notifications/cancelledmessage cancels the matching request. - HTTP caller/disconnect signals propagate through
handle()and the adapters. - Transport close, stdin EOF, and server close abort active work.
- A
handle()caller may pass its ownAbortSignal.
AbortError reasons for Toolgrain-owned cancellation: client cancellation, connection close, or server close. A caller’s own handle() abort reason is otherwise preserved. Inspect ctx.signal.reason if your application needs the distinction.
Cancelled late failures do not trigger diagnostics. A handler that ignores cancellation can still consume resources; on stdio its request ID remains reserved until it settles.
Set an application deadline
applicationService is your application operation, which must actually honor the signal. A timeout rejection becomes an unexpected tool failure unless your handler intentionally converts it into safe public feedback. Do not merely race a promise and assume the underlying operation has stopped.
Client timeouts are not guaranteed to send cancellation or disconnect promptly. The interoperability report reproduces this in the tested Codex direct-call API. Toolgrain has no built-in per-tool timeout setting.
Legacy HTTP cancellation notifications are advisory in the independent-request design; they do not introduce a session-wide request map. HTTP disconnects still abort the affected handler. Do not infer cancellation behavior from the arrival of a notification alone.