When a cloud machine may be deleted

What it is

A machine is a shared resource: one cloud VM can hold many sessions at once, and their work lives only on its disk until it comes home. So "may this machine go?" is not a per-session question.

machineDeleteVerdict answers it once, for the whole machine. It reads every session bound to the machine's remote — with no cap — plus each session's capture debt, plus the provider's own seat list when the provider reports one. It says yes only when all of that is clean.

On 27 October 2026 a shared pool machine holding 136 sessions was deleted from a shell after a capped read showed only the four most recently closed seats, all archived and home. Sixteen sessions that had taken a turn that day still had nothing home, and their work went with the disk. This guard exists so that cannot happen again, on any road.

Where to find it

• In the app — nothing to click. The app's own delete roads (the lifecycle sweeper's retire arm and the Machine Lifecycle V2 seam) prove a machine home on their own and are unchanged.
• In a shell — running box delete, boat delete, box rm, box archive, or a force-stop from a Bash or PowerShell tool call in an agent session is checked before it runs.
• As a read — GET /machines/delete-verdict/:provider/:machineId on the local control server answers the same question for anything else that wants to ask. Reading it never raises a card.
• In the guard catalog — npm run dev:bypass -- list lists it as cloud-machine-delete.

How it behaves

A yes needs all of this:

• every session on the machine is archived or ended;
• every one of them is proven home — a handback mark, the machine's retire-probe stamp, a capture stamp, or a preserved branch, each covering the session's last turn and the machine's last resume (a landed cloud return alone is not proof: it says nothing about turns taken after it);
• no capture is owed on any of the machine's remotes;
• the provider's seat list, when it reports one, names no seat this app cannot account for. No provider reports a seat list today, so in practice the app's own record of the machine's sessions is what decides; the seat arm is there for the day a provider starts reporting one.

Anything else is a no, and the answer names each blocking session with what it is missing: not-finished, not-home, capture-owed, or seat-unaccounted.

A plain stop is allowed. It snapshots the machine before stopping, so nothing is lost. Only a force-stop is refused, and only on the same verdict.

An app that cannot answer is a refusal. The shell guard refuses when the verdict is false and when the app does not answer — no verdict, no delete. Two unreadable answers are named for what they are: provider-seats-unread and verdict-unreadable.

Every refusal is visible. It logs metric=machine_delete_refused with the machine, the reason and the blocking sessions, and the refusal the agent sees names each blocking session. The read raises no inbox card, so a hook that polls it cannot flood the inbox.

A person can lift it for one machine. The guard is a data-safety rule, so the master bypass switch never stands it down. A human who has checked the machine by hand lifts that one row with npm run dev:bypass -- off cloud-machine-delete.

Related

• Reading a cloud session's state
• Cloud returned work