An agent timeout is not a cancelled action

You walked away. The client timed out. Nest reconnects, or the run looks stuck in the UI. The instinct is to treat the pending action as cancelled — or to POST the same request again so it “definitely happens.” Neither is true.

A write-up of a real agent control plane puts the failure in the title: an agent timeout is not a cancelled action. The example is familiar even if you never used that stack: the agent asked to save a report, the operator left, the client timed out, the process restarted. Coming back, you do not know whether the write landed, is still in flight, or never started. Guessing and retrying is how you get a second write.

This is not yesterday’s gate. That piece is about not letting a free loop hold write and host-shell. This one is what to do after a tool call already left the client.

What actually stopped — and what did not

Soot is preview. You choose the access. You can Stop a run. Completed actions stay completed. The workspace is not an OS sandbox.

Two more facts that matter when the UI looks dead:

• Losing a connection or leaving watch does not Stop the run.
• Nest is the operator workspace, not the runtime. A save in Nest is not Active until the host acknowledges it.

Closing the tab, dropping the watch, or waiting out a client timeout is not a cancellation. If a file write or a host-shell command already finished on the host, Stop will not undo it. If it is still in flight, the host may still finish it while you are looking at a spinner.

The agent should not decide what it is allowed to do — that is a tool-layer decision, not a hope that the model will refuse the second POST. Accountability does not delegate when you walk away from the client. Permissions belong in the tool layer, not in a prompt you cannot prompt away (notes on that split).

If the outcome is uncertain, inspect the original run

After an uncertain submission, keep the original conversation and run IDs and any receipts you already have. Watch that run. Do not open a fresh conversation and POST the same tool call “to be sure.” A retry is not a rollback.

soot watch --conversation <conversation-id> --run <run-uuidv7>

Use the IDs from the run that already submitted the action. The tokens above are placeholders — copy the real conversation id and run uuid from that session.

While you watch:

1. Name the action. File path, command, or tool — not “it was doing something.”
2. Check the artifact, not the spinner. If the tool writes a file, ls / stat / a diff against a copy you did not give the agent. The UI can lag the host.
3. Do not Stop unless you mean to fence new work. Stop persists before cancellation and fences new effects and publication. It does not undo completed actions. It also does not make a half-finished write go away.
4. Do not spawn a twin. A second soot run with the same mission is a second attempt, not a query of the first.

If soot check --show still lists write or host-shell and you no longer need them, take them off for the *next* run. That does not retract what this run already did.

A short operator sequence

When the client times out or Nest reconnects:

1. Write down the conversation id and run id before you click anything else.
2. soot watch that pair. Wait until the host has a terminal state, or until you can see the artifact.
3. If you need the run to stop *new* work, Stop it — then still inspect what already landed.
4. Only then decide whether a new run is required, with a narrower mission that cannot repeat the same write.

We are not claiming a durable in-product approval queue that survives every server restart. The operator practice that survives a restart is the one the docs already describe: keep the IDs, inspect the original run, treat a retry as a new effect.

Default soot spawn is a general Soot with write and host-shell. It is not read-only. If timeout-and-retry is how you work, spawn with --empty or strip grants until a hung client cannot double-apply. That is the complementary control to Stop.

Next step

Read Stop and uncertain outcomes in the operation docs, then the same rules on the quick start. If the run can still write, look at soot check --show before you type the next command.