Create a persistent, resumable Vercel Sandbox that survives across process runs using Sandbox.getOrCreate(), with one-time setup and per-resume hooks.

Documented steps

1. Use a stable, unique `name` and `Sandbox.getOrCreate()` rather than `Sandbox.create()` for long-lived sandboxes: `const sandbox = await Sandbox.getOrCreate({ name: 'my-sandbox', onCreate: async (sbx) => { await sbx.runCommand('git', ['clone', repoUrl, '.']); await sbx.runCommand('npm', ['install']); }, onResume: async (sbx) => { await sbx.runCommand({ cmd: 'npm', args: ['run', 'dev'], detached: true }); } })`. Docs: https://vercel.com/docs/sandbox/concepts/persistent-sandboxes
2. Understand default behavior: persistence (`persistent: true`) is on by default, so filesystem state auto-snapshots on stop and auto-restores on the next resume — no manual snapshot calls required.
3. By default `getOrCreate` does NOT resume an existing sandbox immediately; the session resumes lazily on the first SDK call (e.g. `runCommand`), and `onResume` fires at that point. Pass `resume: true` if you need `onResume` awaited before `getOrCreate` resolves.
4. In a later process, reconnect with `const sandbox = await Sandbox.get({ name: 'my-sandbox' })` — this auto-resumes on the next SDK call that needs a running VM.
5. Tune snapshot retention to control storage cost: pass `snapshotExpiration` (ms, default 30 days, `0` = never expire) and/or `keepLastSnapshots: { count: 1-10, expiration?, deleteEvicted? }` to `Sandbox.create()`/`getOrCreate()`/`sandbox.update()`.
6. For one-off/CI jobs that don't need to resume, opt out of persistence entirely: pass `persistent: false` to `Sandbox.create()` (or `--non-persistent` in the CLI) to avoid Snapshot Storage charges.