Sandboxes become inaccessible after running for a while on macOS — sbx ls hangs, dashboard shows none, reboot fixes it

[X-43A]

Environment

• macOS 26.3.1 (Tahoe) ARM64
• sbx v0.28.3
• Docker Desktop also installed
  What happens

After the Mac has been running for a while, all sandboxes become completely inaccessible. sbx ls hangs forever, the dashboard shows no sandboxes, and sbx run <name> also hangs. Full reboot always fixes it.

Diagnosis (with help from Claude)

sbx diagnose passes all checks. The daemon is alive and responsive. But the log shows it can't reach any sandbox VM:

"failed to create SDK client for runtime","runtime":"claude-new","error":"create SDK client: health check: context canceled"
"uri":"/runtime","status":200,"duration_ms":15007

Each sandbox times out after ~15s, and with 6 sandboxes sbx ls just blocks forever. sample on the hung process shows all threads stuck on __psynch_cvwait. The VMs appear frozen at the hypervisor level — the daemon knows they exist but can't reach their internal Docker sockets.

Expected behaviour

sbx ls should timeout and show sandboxes as stopped rather than hanging indefinitely.

---

sbx diagnose report

OS: darwin
Arch: arm64
DS Version: v0.28.3

Check	Status	Message
CLI binary	✓	found
Daemon	✓	healthy
Version match	✓	v0.28.3
Storage directories	✓	all 1 paths present
Directory permissions	✓	all writable
Socket	✓	responsive
Authentication	✓	authenticated

Full JSON output

```json { "version": "1.0", "checks": [ { "name": "CLI binary", "status": "pass", "message": "found", "detail": "/opt/homebrew/bin/sbx", "hint": "" }, { "name": "Daemon", "status": "pass", "message": "healthy", "detail": "version v0.28.3 8d114184e520cf5744502f187faf90342af599e5", "hint": "" }, { "name": "Version match", "status": "pass", "message": "v0.28.3", "detail": "", "hint": "" }, { "name": "Storage directories", "status": "pass", "message": "all 1 paths present", "detail": "", "hint": "" }, { "name": "Directory permissions", "status": "pass", "message": "all writable", "detail": "", "hint": "" }, { "name": "Socket", "status": "pass", "message": "responsive", "detail": "", "hint": "" }, { "name": "Authentication", "status": "pass", "message": "authenticated", "detail": "", "hint": "" } ], "summary": { "pass": 7, "warn": 0, "fail": 0, "skip": 0 } } ```

[kiview]

Thanks for reporting the issue @X-43A.
In case you are still in an error state, could you upload your logs by doing a sbx diagnose --upload please?

[X-43A]

It's done.

Is the diagnostics private? Can I give you the id in here and only authorized people will have access to it?

[X-43A]

If it helps I have both docker desktop and podman installed.

Sbx works perfectly after mac reboot and stops working after sometime, usually after sleep.

[coder-at-work]

Occasionally, I have the same issue. At first, I only knew how to fix it with a full system restart.

I have the impression that it’s related to the Docker login (is the token lifetime too short?). After a weekend where my mac was running and sandboxes were still open, I had to log in again. After that, I encountered this problem. The error messages indicated an issue with the daemon.
That’s why I tried restarting the daemon instead of the entire system.
The command sbx daemon stop && sbx daemon start -d resolves the issue without needing to restart the system.
However, any running sandboxes must be stopped and restarted once (sbx run <sandboxname>).

Annoyingly, sbx help doesn’t list "daemon" as an available command.

Yesterday, I updated to version 0.30.0. I’ll see if the issue still occurs with this version.

[X-43A]

I have the same issue with docker login, forgot to mention it.

@coder-at-work Thanks for that command, will try it next time.

[scyther505]

same issue for me, usually laptop restart makes things happy but not this morning. I did move around some directory that was mounted on one sandbox but unfortunately all my sandboxes went away.

Tried the daemon stop and start but did not work

[X-43A]

It just happened again.

I went home last night with my latptop, came back to the office and all the sandboxes were working initially.

20 minutes later they asked for /login and the rest is what we know.

I used @coder-at-work's command and it worked flawlessly, just had to login again.

[Meldanor]

I have a similar issue linked to a long running task for the agent. After a while the agent crashes / does not respond anymore and the vm itself becomes inaccessible. sbx ls hangs, sbx stop does not work. I can exec into the VM with a bash and do stuff, but can't recover it. I killed every agent related process inside the VM - but it doesn't recover from it. I can't event CTRL+D from the bash session inside the VM properly - it hangs at the "logout".

The solution for this: Kill the sbx process on the host / or restart the mac. But than everything is lost and the problem occurs after restarting the long running task.

At the moment the Docker Sandbox is unusable for long running tasks for me. I didn't have this kind of problem a few days ago.

Setup:
Mac M1 Pro 16 GB
MacOS Tahoe 26.5 (25F71)
SBX v0.31.2

[phawrylak]

Same issue here on Windows 11 with sbx v0.32.0, so this doesn't look OS-specific. Pretty annoying - hoping for a fix soon.

[kaldown]

Confirming. It just hangs for whatever reason, and considering I have multiple repos - I see how this promotes:

• first single session hangs, while other seems working
• then all the session for the repo stop responding, while other repos / session works
• then you can't even open new session, it just stops replying
• after a while "sbx" will show that there is no sandboxes created. While at the very beginning there were few.
• Sandbox refresh failed: no sandbox executor available

[kaldown]

Could you please escalate the issue @gabolaev @maxcleme ? It is very frustrating to loose 3-5 terminal session which ins sum containing few million tokens of research. And it happens long time already. Maybe even a temporal solution to preserve sessions between resets could help, which I will try to pull now

[thrive-rares]

This is still happening on an ongoing basis - very frustrating, and makes it hard to commit to sbx. Any word on escalating this in priority?

[zizzfizzix]

As a workaround, try to kill containerd-shim-nerdbox-v1 whenever you notice this issue. It fixes the problem for me without having to do anything more drastic.