Skip to content
sandboxer
Start free trial
Guides · How-tos

Fix Exit Code 137 or a Full Disk in a Sandbox by Resizing It

Updated October 27, 2026 .md

Short answer: Exit code 137 means the kernel's OOM killer sent SIGKILL because the sandbox ran out of RAM; "No space left on device" (ENOSPC) means the disk is full. Fix both the same way, with sbx stop and then sbx resume --type and a bigger size. Your files stay; running processes don't, so restart the job.

Which error do you have?#

What you see What happened Confirm it with
exit=137, Killed from bash The process used more memory than the sandbox has. 137 is 128 + 9, signal 9 being SIGKILL dmesg | grep -i 'out of memory'
No space left on device, OSError: [Errno 28] The root filesystem is full df -h / shows 100%
type_too_small (HTTP 400) on resume You asked for a smaller size. Moving to a smaller size isn't supported yet, even after you delete data Keep the size, or create a new, smaller sandbox and copy what you need

The sizes, from the machines docs. Prices are per hour, billed per second while the sandbox runs:

Size vCPU RAM Disk Price per hour
small 2 4 GB 12 GB $0.018
default 4 8 GB 50 GB $0.036
large 8 16 GB 125 GB $0.072
xlarge 16 32 GB 251 GB $0.20 (plans from $100)

The free trial runs small and default.

Reproduce an OOM kill on a small sandbox#

We ran everything below on a real small sandbox. First, how much memory and disk it has:

sbx new --type small
id=sb_5jn838r5rt    # your sandbox id from `sbx new`
sbx exec $id "free -h; df -h /"
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       306Mi       3.1Gi       352Ki       625Mi       3.5Gi
Swap:             0B          0B          0B
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        19G  5.5G   13G  30% /

There is no swap, so when RAM runs out the kernel kills a process instead of slowing down. This job holds 6 GB, 256 MB at a time, like a script loading a dataset that's too big:

# ~/job.py
chunks = []
for i in range(24):
    chunks.append(bytearray(256 * 1024 * 1024))
    print(f'{(i + 1) * 256} MB', flush=True)
print('done')
sbx exec $id "python3 ~/job.py; echo exit=\$?"
256 MB
512 MB
…
3328 MB
3584 MB
exit=137
/bin/bash: line 1:   568 Killed                  python3 ~/job.py

The kernel log names the process and how much memory it held when it died:

sbx exec $id "dmesg | grep -i 'out of memory'"
[   33.999539] Out of memory: Killed process 568 (python3) total-vm:3950072kB, anon-rss:3827584kB, file-rss:28kB, shmem-rss:0kB, UID:1000 pgtables:7556kB oom_score_adj:-900

The first time we ran the job, sbx exec didn't print exit=137. It returned The machine did not answer. (sandbox_direct_failed), and the same dmesg line showed that the kernel had killed python3. A fix shipped later on 2026-10-27: in sandboxes created since then, an OOM-killed command exits 137 and the guest agent stays up (older sandboxes get the fix at their next boot). On an older sandbox, if an exec dies with no exit code while a job is allocating memory, check dmesg before you look anywhere else.

Reproduce a full disk#

fallocate reserves space without writing it, so it fills a disk in a second:

sbx exec $id "fallocate -l 13G ~/big.bin; echo exit=\$?; df -h /"
fallocate: fallocate failed: No space left on device
exit=1
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        19G   19G     0 100% /

The fallocate failed, but the space it had already taken stayed taken: du showed 14G in /home/user. From then on, every write fails:

sbx exec $id "echo hello > ~/note.txt; echo exit=\$?; python3 -c \"open('out.csv','w').write('x'*10**8)\""
/bin/bash: line 1: echo: write error: No space left on device
exit=1
Traceback (most recent call last):
…
OSError: [Errno 28] No space left on device

To find what is using the space, run du -xh -d1 / | sort -h | tail. If the big files are disposable, deleting them is the quick fix. If you need them, resize.

Fix both: stop, then resume at a bigger size#

sbx stop $id --wait
sbx resume $id --type default
sbx exec $id "uptime; free -h; df -h /; ls -lh ~/big.bin"
 02:42:59 up 0 min,  0 user,  load average: 0.00, 0.00, 0.00
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       332Mi       7.4Gi       360Ki       242Mi       7.4Gi
Swap:             0B          0B          0B
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        56G   19G   38G  33% /
-rw-r--r-- 1 user user 13G Oct 27 02:42 /home/user/big.bin

The resume took about 3 seconds (one run, 2026-10-27). The same sandbox now has twice the RAM and a bigger disk, with the filesystem already expanded. The 13 GB file is still there. Now the job finishes, and writes work again:

sbx exec $id "python3 ~/job.py | tail -3; echo exit=\${PIPESTATUS[0]}"
sbx exec $id "echo hello > ~/note.txt; echo exit=\$?"
5888 MB
6144 MB
done
exit=0
exit=0

The sandbox keeps its id, URL and files. sbx info $id --json showed "type":"default","vcpu":4,"memoryGB":8,"diskGB":50.

What a resize does not keep#

A normal resume restores the VM's memory, so processes keep running, as long as a machine with the same CPU type is free; otherwise it boots from disk and reports resumeReason: "cpu_mismatch" (snapshots docs). A resume with --type always boots from the disk, because the memory image belongs to the old size. You can see it above: uptime says up 0 min. Our run saw memoryRestored: null in the resume's JSON; that was before a fix shipped later the same night, and a resize resume now reports memoryRestored: false with resumeReason: "resized". Enabled systemd services start on their own. Anything you started by hand, such as a dev server, a tmux session or the job itself, has to be started again. If the job was half done, make it resumable (write checkpoints to disk) before you rely on a resize.

Sizes change only on resume or fork. sbx fork $id --type default gives you a bigger copy and leaves the original as it is.

Shrinking back fails with type_too_small#

Growing works. Moving to a smaller size isn't supported yet: to go smaller, create a new sandbox of that size and copy your files. A resume at a smaller size was refused in our test even after we deleted data. We added 2 GB more to the resized sandbox (21 GB used on the root), stopped it and asked for small:

sbx resume $id --type small
error: The sandbox's data does not fit the small disk. (type_too_small) [HTTP 400, req_Fw4MoeHgwZVyjD8OwQtL]

The sandbox stays stopped at its current size, and a plain sbx resume $id starts it as before. In our test, deleting the big files (df back to 5.5G used) and running sudo fstrim / did not change the answer: the next --type small resume was refused the same way. Plan a resize as one-way. Forking into a smaller size runs the same check and is refused too. To get back to a smaller size, create a new sandbox at that size and copy what you need into it (with sbx scp, rsync or a git checkout). If you only need the bigger machine for one heavy step, fork a bigger copy for that step and delete it afterward, so the original stays small.

FAQ#

Is exit code 137 always out of memory?#

It means the process got SIGKILL (128 + 9). Out of memory is the usual cause in a sandbox, and dmesg shows an Out of memory: Killed process line when it is. If there's no such line, something sent the signal directly, such as kill -9 or a timeout in your own tooling.

Will I lose my files when I resize?#

No. The resize resume boots from the same disk, so files under your home directory and anything you installed are kept. Running processes and anything held only in memory are lost.

Does a bigger sandbox cost more while it is stopped?#

No. A stopped sandbox costs nothing. You pay the bigger size's rate only while it runs, per second: default is $0.036 an hour against $0.018 for small.

Can I add swap instead of resizing?#

The sandbox has no swap by default (free -h shows Swap: 0B). You have root, so you can create a swap file, but it uses the same disk and is much slower than RAM. A bigger size is the simpler fix for a job that needs more memory.

Why does df show 19G on a 12 GB small sandbox?#

That's what df -h / printed on a fresh small: a 19G root with 5.5G already used and 13G free. The machines docs say the disk size is space for your files, and the OS and pre-installed tools don't count against it. Plan your own data against the free space df reports.

More guides

Top AI sandbox platforms for code execution in 2026, ranked

For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.

Read the guide
Best sandboxes for running coding agents (Claude Code, Codex, Gemini CLI) in 2026, ranked

For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.

Read the guide
Best Daytona sandbox alternatives in 2026, ranked

The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.

Read the guide
Best E2B alternatives in 2026, ranked

If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.

Read the guide