00Worked guide / sandbox cleanup
How to Verify Cleanup After a Coding-Agent Sandbox Run
A sandbox can finish its task while its host, runner registration or temporary key still exists. A useful completion record shows what happened to each owned resource and when that observation was made.
01Ownership
Identify the resources this execution is allowed to remove.
Before starting the run, record the exact host or resource group, runner identity, execution attempt and temporary credential locations. Bind that inventory to the execution and retain the controller’s version. A shared resource needs an explicit ownership rule; similarity in its name is insufficient authority to delete it.
Design cleanup for successful, failed and cancelled work. The controller should retain its terminal outcome even when teardown encounters an error. Keep execution and cleanup states separately visible so a successful task cannot hide an unresolved resource.
- Record immutable resource identifiers where the provider supplies them
- Use a unique run association and an explicit ownership inventory
- Keep the original cleanup attempt and its errors
- Set a bounded resource lifetime before execution
02Evidence
Retain the required results before destroying their only copy.
Define which reports and logs the run must return, with bounded file sizes and an allowed path list. Validate their run and source bindings while the originals are available. Preserve the exact bytes needed for later review, together with collection failures. A cleanup routine must still run when validation refuses a result.
Decide what cancellation can return. A broken connection may leave the task outcome unresolved even after the owned host is removed. Record that limitation explicitly. An absence check performed later cannot reconstruct a missing execution report.
03Observation
Check the provider’s state after the controller reports cleanup.
Use a separate read-only observation to check the exact owned host or group. Check runner registration independently, because removal of a VM does not by itself establish removal of the registration. Verify that the temporary local private key is absent as another recorded condition.
A failed API request is an unavailable observation. Retain the response or timeout and inspect again through the same scoped observation path; do not translate a permission error, rate limit or incomplete listing into resource absence. When searching a list, verify its completeness or follow pagination before concluding that an identifier is missing.
Keep the observation time. A successful absence check establishes the checked state at that time. It does not prove there were never earlier leftovers, that all unrelated resources were removed, or that a provider bill has settled.
04Worked example
The task passes, but cleanup remains open for another observation.
Consider this illustrative record: attempt A runs on owned host H with runner R and temporary local key K. Its required artifact is collected and checked. The task returns success at 10:00. At 10:02 the controller requests host deletion, but the separate host observation still reports H present. The task result can remain successful while cleanup stays pending.
At 10:04 a fresh host check reports H absent. A complete runner inventory no longer contains the recorded R identity, and a local check finds K absent. Store the original 10:02 observation alongside the later checks. The final cleanup record should identify A, H, R and the private location used to check K without publishing any credential value.
If the runner-list request instead fails at 10:04, record host absent and runner state unknown. Keep the cleanup gate open until the runner observation is resolved. Do not start a second copy of attempt A merely because its cleanup is still being checked. These times and identifiers illustrate the method; they are not TraceAxiom production measurements.
05Accounting
Release the workload reservation after cleanup, then reconcile actual charges.
A reservation is a planning control for work that may still consume resources. Release it according to the recorded policy after the required cleanup observations pass. Preserve a separate allowance for delayed charges when that is part of the budget.
The final invoice or provider usage record establishes billed cost. Host absence cannot prove zero cost or settle storage, network and other charges. Keep the modeled maximum, reservation, observed resource lifetime and reconciled usage as separate fields. If billing is still pending, label the figure provisional and retain the missing measurement.
06Review
Make the remaining uncertainty easy to find.
A reviewable record connects the source and run to the ownership inventory, original task outcome, collected artifacts, cleanup attempt, independent observations and accounting state. Each failed or unavailable observation remains visible with the action that resolved it. This makes it possible to distinguish an execution defect from a collection, cleanup or measurement problem.
This guide describes the review method; it does not report a TraceAxiom production result.
- Task outcome: success, failure, cancelled or unresolved
- Artifact collection: complete or explicitly missing
- Cleanup: verified per required resource or still unresolved
- Usage: estimated, pending or reconciled
Design partners
Close the cleanup gate with observed resource state.
Use the CI artifact guide to check the retained result and the cost guide to reconcile the work’s complete cost. Keep each decision tied to its own evidence.
Join the waitlist