# Sandbox limits and errors

## Limits

- One timeout bounds one execution attempt after provider startup, including package preparation, staging, and execution. Queueing, Box startup, and retry delays can make the full `runSandbox()` call take longer.
- Pass an `AbortSignal` to `runSandbox()` when the caller owns a cancellation boundary. Cancellation stops cancellable provider work and preserves the caller's abort reason. The Definition timeout remains an independent per-attempt limit, and queueing or provider startup can make the full call take longer.
- Vercel closes each Box session after success or failure. Cloudflare creates and closes a unique Box for each run unless you set `sandboxId`.
- A Cloudflare `sandboxId` shares one Box. ViteHub deletes invocation-local files after each attempt, caches prepared projects by digest, and serializes runs with the same ID in one isolate. Separate Worker isolates can still enter the Box at the same time.

## Production checks

A Definition name and its payload select work. They are not a permission boundary. Code inside the Box can use the filesystem, environment, network, credentials, and child processes that the provider exposes.

Inspect that authority before execution when your policy depends on it:

```ts [server/sandbox-authority.ts]
import { resolveSandboxRunner } from '@vite-hub/sandbox'

const runner = await resolveSandboxRunner('release-notes')
console.log(runner.executionAuthority)
```

Apply provider controls such as Vercel `networkPolicy`. Keep secrets in server environment or provider configuration. Do not treat container execution alone as authorization for untrusted code.

Run `vitehub inspect definitions` to list discovered Sandbox Definitions without starting a server.