Docker Sandboxes documentation previously showed “Availability: Early Access” on multiple pages, but most of those labels have recently disappeared while the release notes still refer to “stable releases”.
rimelek
May 25, 2026, 6:29pm
2
Good question. I found the commit that removed the early access label .
Then I tried to find the issue I remembered on Github and I also commented there
opened 07:48PM - 07 May 26 UTC
## Summary
`sbx run --name <X>` can leak the name claim into containerd's metad… ata boltdb (`meta.db`) when the create fails partway through (started-hook race, container init exit, etc.). Once leaked, the name becomes permanently unusable until daemon-state wipe:
- `sbx ls` doesn't list it.
- `sbx rm <X> --force` reports `Error: sandbox '<X>' not found` and exits 0.
- `sbx run --name <X>` reports `container create: Error response from daemon: already exists` and exits 1.
The two commands disagree about whether the name is in use, and there's no `sbx`-CLI command that reads `meta.db` and reclaims a leaked name. Repeating `sbx rm` does not help.
## Repro (Windows, v0.28.3)
This reproduces deterministically once a name has been poisoned, but the initial poisoning event is a race so the first half is best-effort. To manufacture a poisoned name reliably, kill `sbx run` mid-create or use a configuration that fails the started-hook (e.g. a workspace whose parent dir isn't accessible inside the sandbox).
```pwsh
# After a failed `sbx run --name probe-x ...`:
sbx ls # probe-x not listed
sbx rm probe-x --force # "Error: sandbox 'probe-x' not found"
1..5 | ForEach-Object { sbx rm probe-x --force } # still "not found", forever
sbx run --detached --name probe-x --template <T> claude <mounts>
# -> ERROR: failed to create sandbox: ... container create:
# Error response from daemon: already exists
```
Direct evidence the name lives in `meta.db`:
```pwsh
$db = "$env:LOCALAPPDATA\DockerSandboxes\sandboxes\state\sandboxd\containerd\root\io.containerd.metadata.v1.bolt\meta.db"
Select-String -Path $db -Pattern 'probe-x' -Encoding Byte
# matches found, even though sbx ls / sbx rm see nothing
```
We've also observed that **successful** sandboxes leave orphan task directories behind under `state\sandboxd\containerd\state\io.containerd.runtime.v2.task\docker\<id>\` (7 dirs across 3 successful sandboxes in our last probe run), suggesting the leak is broader than just failed creates.
## Expected
One of:
1. `sbx rm <name>` reclaims the name from `meta.db` regardless of whether sbx-CLI tracks the sandbox as live, OR
2. A new `sbx prune` / `sbx reclaim --name <X>` subcommand, OR
3. Auto-reclaim on next `sbx run --name <X>` when sbx-CLI's own state has no record of the name being live.
## Workaround
Stop the daemon and delete the containerd state dirs:
```pwsh
sbx daemon stop
Remove-Item -Recurse -Force `
"$env:LOCALAPPDATA\DockerSandboxes\sandboxes\state\sandboxd\containerd"
Remove-Item -Recurse -Force `
"$env:LOCALAPPDATA\DockerSandboxes\sandboxes\state\sandboxd\runtimes"
sbx daemon start
sbx template load <overlay.tar> # templates are wiped, must re-load
```
This wipes the entire containerd state — coarse and also drops the template registry, which then needs re-loading. Surgical removal via `bbolt delete` against `meta.db` is possible but fragile across containerd schema versions.
## Versions
- Reproduced on `v0.28.3` (Windows 11).
- Same symptom on `v0.26.1` per our internal notes.
## Why this matters
Wrapper scripts that drive long-running soak loops (we run a Ralph-style autonomous-agent loop against a .NET monorepo for hours-long sessions) hit this ~10–30% of the time on partial-create failures. Without the wipe workaround the sandbox name becomes unusable for the rest of the session. We've worked around it with guid-suffixed names + an internal `Reset-SbxState` helper, but the fundamental disagreement between `sbx ls` / `sbx rm` and the `meta.db` claim means the user-facing CLI has no recovery path short of state wipe.
I have not tested yet and the issue is still open, but I see bugfixes in the release note of the latest sbx version that could fix it
mainly:
Keep sandboxes recoverable when workspace or worktree is deleted on the host
Sicne this was my only real problem with sbx, if it was fixed, I guess it could be GA, but I don’t see it mentioned eitehr.
Thanks for the reply. Is there any official statement on the current release status of Docker Sandboxes?
I noticed that the Early Access label was removed from most of the docs, but I could not find a formal announcement or status update in the Release Notes, blog posts, or X announcements. Are there any plans to communicate this more explicitly?