# A Stop Request Is Not a Stop

During the long native Codex Work Room test, the operator pressed **Stop**
while Codex was still running. The old browser path immediately looked stopped.
That made the screen feel fast, but it left the only important question
unanswered: had the Host actually found that exact provider process and asked
it to stop, or had the browser merely changed its own state?

The first tempting repair was another optimistic message: “Stopping…”. It
looked a little more honest, but it still allowed the client to move on without
knowing whether the target invocation was live, whether the Host had accepted
the request, or whether the connection had dropped before it arrived. A green
or red card cannot turn uncertainty into an operating-system fact.

The turning point was treating Stop as a small protocol transaction. The
browser now gives each request an ID. The Host checks its live provider
invocation registry, forwards an interrupt only for that exact active
invocation, and answers with an explicit accepted or rejected acknowledgement.
The React client waits for that acknowledgement. A rejection restores a retry
action; a lost acknowledgement asks the operator to reconnect rather than
pretending the provider stopped. Only a terminal provider lifecycle event
changes the Work Room to **Stopped**.

The acceptance run follows the same distinction. It proves an accepted Stop
targets the current Codex invocation without cancelling the outer turn, proves
a Host refusal leaves an enabled retry action, and exercises the browser at
desktop and phone widths. The protocol tests also reject an interrupt for a
provider invocation that is no longer live.

The reusable rule is simple: a UI request is intent, an acknowledgement is
delivery, and a terminal event is outcome. They belong to different states and
should never be rendered as if they were the same fact.