Reset the sandbox and keep it isolated

Before you reset

Reset discards everything the sandbox made. If you want to keep a sample bundle or a mock quote to read later, save a copy first.

Keep it as a note to yourself, not as evidence. A sandbox artifact says nothing about a live run, and no live operation will accept one.

Reset the sandbox

lithi sandbox reset

This returns the sandbox to the state it had when you opened it. Synthetic jobs, mock quotes, simulated approvals and sample bundles are all discarded together. Nothing is left half-cleared.

You can reset as often as you like, and reopening the same scenario always starts from its first step.

When a sandbox expires on its own

Each sandbox has an expiry, and the expiry is stated when you open it. After that it closes by itself and its contents are discarded, exactly as a reset would discard them.

An expired sandbox is not an error. Open a new one and continue.

What never persists

Nothing in the list below survives a reset or an expiry:

• Sandbox job identifiers and their status history.
• Mock quotes, including the maximum charge and expiry they displayed.
• Simulated approvals and any spend they appeared to reserve.
• Synthetic inputs, sample result bundles and sample receipts.

There is also nothing to bill afterward. A sandbox produces no usage line, no statement entry and no invoice.

Isolation goes further than storage. The sandbox has no authority to act outside itself. It cannot write to a registered destination, call a webhook, or fire a schedule occurrence. It cannot create, rotate or reveal a credential. It cannot move money or open a payment.

This holds regardless of what you type into it, which is why the next section matters.

Why production identifiers are refused

Point a --sandbox command at a real source, destination, credential reference or live job identifier and it is refused. It is never quietly accepted, and it never partially applies.

The refusal is typed. It carries a safe reason and a next action, so you can tell a rejected identifier apart from a workflow that simply cannot run. Fix the reference, or open the same work as a live request instead.

This is deliberate. A sandbox that silently accepted a production destination would be able to cause the one effect it promises never to cause.

Confirm the sandbox is clean

Open the sandbox again after a reset:

lithi sandbox open --scenario ai-eval-team-v1

Success looks like this. The scenario starts at its first step, and none of your earlier sandbox jobs is listed. Asking for one of those job identifiers returns a typed not-found rather than stale data.

If something still looks stale

If a reset appears not to have cleared something, do not keep resetting. Reopen the scenario once, and check whether you are reading a saved local copy of an old bundle rather than the sandbox itself.

If it still looks wrong, see what to do when a sandbox reset does not clear. Describe what you saw and quote the job identifier shown on screen. Never send an input file, a key or a signed link to support.

When the sandbox is behaving and you are ready for a real result, read moving to live work.