# Can You Fork a Running Cloud Sandbox, Memory and All?

> No. sbx fork copies a running sandbox's disk into a new, independent sandbox in a few seconds, but 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, or run long-lived work as systemd services that save state to disk.

Source: https://sandboxer.com/guides/fork-a-running-sandbox-with-memory. Updated 2026-10-27.

**Short answer:** No. sbx fork copies a running sandbox's disk into a new, independent sandbox in a few seconds, but 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, or run long-lived work as systemd services that save state to disk.

## What a fork copies

| | Copied to the fork | Not copied |
| - | - | - |
| Disk | Everything: `/home/user`, `/etc`, installed packages, Docker images, enabled systemd units | |
| Memory | | RAM, open files, sockets, shell sessions |
| Processes | Enabled systemd services start at boot | Anything started by hand, with `exec --detach`, or in `tmux` |
| Settings | Size, environment version and per-sandbox env (unless you override them) | The source's TTL: the fork gets the default one hour |
| Identity | | Id, subdomain, hostname, machine-id and SSH host keys are all new |
| Hosted ports | | Routes and tokens: run `sbx host` on the fork |

The source is never touched and keeps running. The fork's disk is a copy-on-write reflink, so it takes about the same time for a large disk as for a small one, and uses no extra storage until the two diverge.

## Try it: a counter in memory, then a fork

We ran this on prod on 2026-10-27 with a `small` sandbox. The first process keeps its count only in memory and prints it to a log. The second is a systemd service that saves its count to a file each second.

```bash
sbx new --type small --name aeo-fork-1
src=sb_wq41n3fyb5    # the id sbx new printed

# 1. A counter that lives in memory (it logs each value, plus a random token picked at start)
sbx exec $src --detach "python3 -u -c 'import time,itertools,secrets;tok=secrets.token_hex(4);[print(i,tok) or time.sleep(1) for i in itertools.count()]' > ~/c.log"

# 2. A counter that saves its value to disk, as an enabled systemd service
sbx exec $src "sudo tee /etc/systemd/system/counter.service >/dev/null <<'U'
[Unit]
Description=counter that saves its value to disk
[Service]
User=user
ExecStart=/bin/bash -c 'n=\$(cat /home/user/n 2>/dev/null || echo 0); while true; do n=\$((n+1)); echo \$n > /home/user/n; sleep 1; done'
Restart=always
[Install]
WantedBy=multi-user.target
U
sudo systemctl daemon-reload && sudo systemctl enable --now counter.service"
```

Just before the fork, both counters were at 254, and we wrote the time to a file:

```bash
sbx exec $src 'tail -1 ~/c.log; echo n=$(cat ~/n); date -u +%T.%N | cut -c1-12 > ~/marker2; cat ~/marker2'
```

```text
254 cefc0bd0
n=254
02:05:36.141
```

Then we forked, at a bigger size, and timed it:

```bash
time sbx fork $src --type default --wait --json
```

```text
{"event":"forking","id":"sb_8lcd3t2t2o","source":"sb_wq41n3fyb5","sandbox":{…"memoryRestored":null,…}}
{"event":"state","id":"sb_8lcd3t2t2o","state":"provisioning"}
{"event":"ready","id":"sb_8lcd3t2t2o","state":"ready","url":"https://regal-daring-cricket.box.sandboxer.com",…}

real	0m3.354s
```

## What the fork had

```bash
c=sb_8lcd3t2t2o
sbx exec $c 'nproc; cat ~/marker2; tail -1 ~/c.log; pgrep -a python3 || echo "no python3"; echo n=$(cat ~/n); systemctl is-active counter; uptime -s'
```

```text
4
02:05:36.141
254 cefc0bd0
no python3
n=257
active
2026-10-27 02:05:38
```

Line by line:

- **4 vCPUs:** `--type default` took effect, so the fork is bigger than its `small` source.
- **The marker file is there.** It was written one second before the fork, and the source listed no snapshots at that point. The fork copied the disk as it was when we forked.
- **The log ends at 254, and `python3` is gone.** The log file came across on the disk, but the process that wrote it, and the count in its memory, did not. The fork booted at 02:05:38.
- **The systemd counter reads 257.** The service started at boot, read 254 from disk and kept counting. This is how to carry work into a fork.

The source was unaffected. A few seconds later it showed `258 cefc0bd0` with the same `python3` process (PID 527) still running.

`sbx info` on the fork shows `"memoryRestored": null` and `"resumeReason": null`. A fork never restores memory, so that field has nothing to report. It's set only on a resume.

## How long a fork takes

These are single runs on prod on 2026-10-27, not benchmarks:

| Run | Measured | Result |
| - | - | - |
| `small` to `small` | `createdAt` to `updatedAt` once ready, from `sbx info` | 1.9 seconds |
| `small` to `default`, `sbx fork --wait` | Wall time with `time`, including the CLI | 3.4 seconds |

`sbx fork` without `--wait` returns the new id at once (HTTP 202). Forks count as a start against your plan's start limits, like a create or a resume.

## If you need the memory too

Use [stop and resume](/guides/pause-and-resume-a-sandbox-with-memory) instead of a fork. A stop writes the VM's memory to disk, and a resume brings the same sandbox back with its processes running. It's one sandbox, not a copy.

A resume restores memory only on a machine with the same CPU type. If none is free within 2 minutes, it boots from disk instead: files are kept, running processes are not, and the sandbox shows `memoryRestored: false` with `resumeReason: "cpu_mismatch"`. Pass `sbx resume --require-memory` to wait for a matching machine rather than boot from disk.

For copies that should come up working, make your services systemd units with their state on disk, as above. Or save a named snapshot once (`sbx snapshot $src my-stack`) and start each copy with `sbx new --from my-stack`.

## FAQ

### Does the fork get the processes that were running?

No. The fork boots from a copy of the disk, so only enabled systemd services start. Processes you started by hand, with `sbx exec --detach`, or in `tmux` are not in the fork.

### Is the fork's disk from the last 10-minute snapshot?

In our test, no. A file written one second before the fork was in the fork, and the source had no snapshots listed yet. The fork copied the running sandbox's disk at the moment of the fork.

### Can I change the size when I fork?

Yes. Pass `--type small`, `default`, `large` or `xlarge`. We forked a `small` sandbox to `default` and the fork had 4 vCPUs.

### Does forking stop or slow down the source?

It didn't in our test. The source's in-memory counter kept going through the fork with the same PID. The source is never changed.

### Can I fork a sandbox created with `--no-snapshots`?

No. The API answers `409 snapshots_disabled`. Such a sandbox can't be resumed, forked or saved as a template either.

## Related

- [Pause and resume a cloud sandbox with its memory](/guides/pause-and-resume-a-sandbox-with-memory)
- [Snapshots: stop, resume, fork and templates](/docs/snapshots)
- [Run coding agents in parallel](/guides/run-coding-agents-in-parallel)
- [Long-running work and systemd services](/docs/long-running)