Forking sandboxes

What does a fork copy?

A fork copies the disk and nothing else. If the source is running, its filesystem is frozen for the instant of the copy, so files written just before the fork are included, and the source keeps running. Sandboxer's snapshots docs list what the fork gets:

• The full disk, as a reflink copy, so forking a 100 GB sandbox is as quick as forking a 1 GB one
• The source's size, environment version and per-sandbox variables, unless you pass your own
• A new id, new subdomain, new machine-id and new SSH host keys

It does not inherit the source's auto-stop setting. The default one hour applies unless you pass a TTL, so forking a never-stopping sandbox does not create another one by accident.

Can you fork a running sandbox with its memory?

No. Sandboxer's guide on forking a running sandbox is direct about this: the copy boots fresh, so no RAM and no running processes come across. Files written up to the fork are there.

To keep memory, stop and resume the same sandbox instead, as described in pause and resume. If services must come back in every copy, run them as enabled systemd services, which start on boot.

How do you fork a sandbox?

Use sbx fork with the source id. You can pick a bigger size, add variables and set a TTL in the same call.

sbx fork <sandbox-id>
sbx fork <sandbox-id> --type large -e TENANT=acme --ttl 600

From the TypeScript SDK, fork() returns a new sandbox once it is ready, which makes parallel attempts short to write:

const attempts = await Promise.all(
  ["approach A", "approach B", "approach C"].map(async (hint) => {
    const fork = await base.fork({ ttlSeconds: 3600 });
    return fork.prompt(`Fix issue #42 using ${hint}`, { provider: "codex" });
  }),
);

Forks can only be made larger than the source, not smaller. A fork also counts as one start against your plan's start limits.

When should you use a named snapshot instead?

Use a named snapshot when many sandboxes should start from one fixed state, and a fork when you want to branch from a sandbox you are using now. A named snapshot is independent of its source, so it still works after you delete the original.

sbx snapshot <sandbox-id> web-stack   # save a template
sbx new --from web-stack              # start from it, as often as you like

For results you want to reproduce later, Sandboxer's eval guidance suggests a named snapshot with a version in its name, because a fork points at a sandbox that may be gone.

What are forks good for?

Forks suit any job where you want several tries from the same starting point. The docs name parallel attempts, per-user copies of a prepared environment, and safe experiments on a copy of real data. Sandboxer's guides add two patterns:

• Best-of-N agent attempts: fork once per attempt, run the tests in each, keep the best diff.
• Baseline comparisons: score unchanged code and an agent's change on the same forked disk.