## TL;DR
A revert that crashes mid-operation leaves a VM between states: disks partially rolled back, snapshot files inconsistent, and the next test inheriting the mess. Stop trusting reverts for reset in the harness: recreate test VMs from a template or golden image per run where feasible, add a pre-test state verification that rebuilds anything suspect, and make cleanup run even when a test crashes.

```text
agent's VM snapshot revert crashed and left the sandbox in a dirty state, test failed
```

## Use this when
- Tests fail in new ways after one revert crash, on a VM that previously passed.
- Snapshot files or VM configuration look inconsistent after the crash.
- Manual rebuild of the VM makes the mystery failures vanish.

## Not for this skill when
- The production hypervisor has revert issues. Different estate and risk profile.
- Tests themselves corrupt the VM during a run and expect revert to fix it. That works until the revert is the thing that breaks.

## Steps
1. Quarantine the dirty VM and capture its state and logs before rebuilding. Verify: evidence of the crash state is preserved
2. Change the harness reset strategy to redeploy from template or golden image instead of reverting snapshots. Verify: a test run uses a freshly deployed VM
3. Add a pre-test verification of VM state: disks attached as expected, no leftover snapshots, guest responsive. Verify: a deliberately dirtied VM is caught and rebuilt
4. Ensure cleanup and rebuild run in a finally-style path even when tests crash. Verify: a forced test crash still leaves a clean sandbox
5. Run the full test set twice back to back. Verify: both runs start from verified clean state and pass

## Variant phrasings
### vm revert crashed dirty sandbox rebuild template
The rebuild phrasing.
### sandbox state corrupted failed revert cleanup
The cleanup variant.
### test environment not reset between runs agent
The reset wording.

Compatibility: Agent test harnesses on VMware and Hyper-V sandboxes using snapshot revert or template redeploy reset strategies.

## Why it happens
Revert feels like a free reset button, but it is itself a storage operation that can fail halfway, and its failure mode is silent state corruption rather than a clean error. Harnesses built on revert inherit that fragility at the worst moment, right between tests, where it contaminates the next result. Template redeploy trades a little time for a reset that is boring and dependable.

## Edge cases / pitfalls
- Golden images need patching discipline or tests drift from production reality. Version them.
- If revert must stay for speed, verify the revert result before trusting the VM. Trust but verify applies literally here.
- Track sandbox rebuilds per week. A rising count signals an underlying platform problem.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IFIuqe8EBcOKaDiNJ29omA