# Fix Exit Code 137 or a Full Disk in a Sandbox by Resizing It > 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. Source: https://sandboxer.com/guides/fix-exit-code-137-or-a-full-disk-in-a-sandbox. Updated 2026-10-27. **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](/docs/machines). 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: ```bash sbx new --type small id=sb_5jn838r5rt # your sandbox id from `sbx new` sbx exec $id "free -h; df -h /" ``` ```text 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: ```python # ~/job.py chunks = [] for i in range(24): chunks.append(bytearray(256 * 1024 * 1024)) print(f'{(i + 1) * 256} MB', flush=True) print('done') ``` ```bash sbx exec $id "python3 ~/job.py; echo exit=\$?" ``` ```text 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: ```bash sbx exec $id "dmesg | grep -i 'out of memory'" ``` ```text [ 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: ```bash sbx exec $id "fallocate -l 13G ~/big.bin; echo exit=\$?; df -h /" ``` ```text 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: ```bash sbx exec $id "echo hello > ~/note.txt; echo exit=\$?; python3 -c \"open('out.csv','w').write('x'*10**8)\"" ``` ```text /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 ```bash sbx stop $id --wait sbx resume $id --type default sbx exec $id "uptime; free -h; df -h /; ls -lh ~/big.bin" ``` ```text 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: ```bash sbx exec $id "python3 ~/job.py | tail -3; echo exit=\${PIPESTATUS[0]}" sbx exec $id "echo hello > ~/note.txt; echo exit=\$?" ``` ```text 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](/docs/snapshots)). 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`: ```bash sbx resume $id --type small ``` ```text 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](/docs/machines) 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. ## Related - [Machines and sizes](/docs/machines) - [Limits and errors](/docs/limits) - [Pause and resume a cloud sandbox with its memory](/guides/pause-and-resume-a-sandbox-with-memory) - [Run a long job in a cloud sandbox](/guides/run-a-long-job-in-a-cloud-sandbox)