Parent
Problem
The current Web workbench can submit prompts and queue follow-up input, but it cannot stop an active model turn. The browser exposes only a Send action; WebRuntimeController has no interrupt/cancel operation, and the runtime only aborts sessions while disposing the whole Web host.
A long, stuck, or accidentally submitted turn therefore cannot be stopped without closing the workbench. Closing the host is not an acceptable per-turn control because it also tears down unrelated Web runtime state.
Value
- Let users recover immediately from a runaway or unwanted turn.
- Preserve the same cancellation lifecycle and terminal evidence as Pi instead of inventing a browser-only status.
- Establish the command/receipt boundary needed by future capability controls.
Approach constraints
- Reuse Pi AgentSession cancellation and lifecycle events as the source of truth.
- Bind every cancel request to the expected Web Session and current command/turn epoch.
- Define an exact receipt that distinguishes accepted, already settled, stale session, and failed cancellation.
- Do not infer cancellation from button state or optimistic UI.
- Keep queued follow-up prompt behavior explicit: cancellation must define whether queued input is retained or discarded.
- Preserve controller serialization, SSE resync, shutdown, and multi-client lease boundaries.
Acceptance criteria
Out of scope
Parent
Problem
The current Web workbench can submit prompts and queue follow-up input, but it cannot stop an active model turn. The browser exposes only a Send action; WebRuntimeController has no interrupt/cancel operation, and the runtime only aborts sessions while disposing the whole Web host.
A long, stuck, or accidentally submitted turn therefore cannot be stopped without closing the workbench. Closing the host is not an acceptable per-turn control because it also tears down unrelated Web runtime state.
Value
Approach constraints
Acceptance criteria
Out of scope