I've been using Docker Sandbox for about a month, mainly through the WSL shell and custom-agent workflow. I later added a separate Windows sandbox using the SBX commands. Today, the WSL sandbox stopped launching, and running `docker sandbox ls` now reports that no sandboxes were found. The SBX sandboxes still appear to be working normally.
The last time I used the missing WSL sandbox, it failed because of insufficient system resources. In `.dockersandboxesvmshell-`, I can only find `container-platform.log`; the virtual machine data does not appear to be there. I'm especially hoping to recover files stored under `/home/agent/`, including skills and other work developed over the past few weeks.
Does anyone know where the WSL sandbox image or its persistent data is stored, and whether the files can be recovered after the sandbox manager loses track of it?
3 Answers
First, make sure the missing environment was created with `docker sandbox`, not the separate `sbx` commands. They use different storage and management systems, so a sandbox created with one will not appear in the other. For a Docker Sandbox, it may be worth checking `docker ps -a`, `docker volume ls`, and `docker images` for leftover containers, volumes, or images. If you find a likely volume, you can mount it temporarily into a small container and copy the contents out, for example with `docker run --rm -it -v :/data alpine sh`. However, if the sandbox directory contains only a log and no disk or volume data, recovery may not be possible through the normal Docker CLI.
A sandbox can disappear from the listing without the underlying VM metadata being healthy. After crashes, the containerd state may become inconsistent. On Windows, the relevant state has been found under `AppDataLocalDockerSandboxessandboxesstatesandboxdcontainerd`; if the sandbox name is still present there, the data might technically exist even though the manager cannot list it. Be careful not to delete that directory while attempting repairs, because removing the state can make any remaining data impossible to restore.
In similar cases, recreating the same sandbox reported that it already existed, but repairing the state was unsuccessful. A failed VM or deleted disk can mean the files are gone even when some metadata remains.
The log indicating insufficient system resources is an important clue. A crash during startup, especially while a workspace bind mount is being removed or unmounted, can leave the sandbox manager and containerd state out of sync. Avoid making more changes to the sandbox folder, and copy the logs and any remaining files before trying cleanup or recreation. For future work, keep persistent projects in a workspace outside the sandbox and regularly synchronize agent skills, memory, and other important files there. Docker Sandbox and SBX should be treated as experimental rather than as the only storage location for valuable work.
That volume-based approach applies to Docker-managed sandboxes, but not to SBX environments. SBX is separate from the Docker CLI, so its data must be investigated in its own storage area.