All my sandboxes were gone one morning

[WhatisRT]

Version: sbx v0.28.3 (8d114184e520cf5744502f187faf90342af599e5), macOS 15 (Darwin 25.4.0), Apple Silicon.

Summary

After resuming from sleep, I found all my open sessions killed and asked to login again. After doing so, it was unable to resume anything. sbx run ... returned:

ERROR: failed to create sandbox: create runtime: create runtime: sandboxd error: status 500: failed to create network: Error response from daemon: already exists

sbx diagnose reported every check passing and sbx ls gave me an empty list. Since all of this is incredibly far from my area of expertise, I've asked Claude to diagnose and try to fix the issue, below is what it came up with. I've edited it a little to make it clearer what I've actually done. I can also provide the log files upon request.

.../com.docker.sandboxes-auth/sandboxes-auth/<some-hash>/metadata.json contained the literal four bytes null instead of an account identifier. The associated secretpass was 349 bytes vs. 1815 bytes in the working user-scoped slot.

Timeline (from sandboxd/daemon.log)

1. Through 2026-05-11T20:26:12, GET /runtime returned ~24 KB (7 sandboxes).
2. 2026-05-11T20:25:16: a routine GET /network/log that normally returns in <1 ms took 15.5 s and ended with write unix …/sandboxd.sock: write: broken pipe. At the same instant, seven failed to create SDK client for runtime <name>: health check: context canceled warnings fired — one per sandbox.
3. 2026-05-11T20:26:25 onward: /runtime started returning 401 user is not authenticated to Docker: secret not found.
4. ~14-hour gap (overnight suspend).
5. 2026-05-12T10:55:59: 401 with a more specific cause:

   retrieve default account metadata: store is locked
   context deadline exceeded
   recovery failed. lock file is not older than 30 seconds
   

6. 2026-05-12T10:56:11: lock condition resolves and …/metadata/hub/default/metadata.json is rewritten as the literal bytes null. From this point on, /runtime returns HTTP 200 with body [].
7. Several sbx login invocations after this succeeded ("Signed in as ") and refreshed the user-scoped slot, but default/metadata.json was repeatedly rewritten as null.
8. After some attempts at recovery (copying some directory that contained the sandboxes into the one that sbx actually used at that time), eventually I got this message, which then led Claude to discover the actual fix:

   WARN: unknown authentication error type encountered: default user account id: invalid identifier: "" must match ^[A-Za-z0-9._:-]+(?:/[A-Za-z0-9._:-]+)*$
   

Recovery that worked

Trying out a few suggestions, this is was worked in the end. I don't know if all of those steps were necessary.

1. Stop sandboxd (kill <pid from sandboxd.pid>).
2. Delete .posixage.lock under both …/com.docker.sandboxes/sandboxes/ and …/com.docker.sandboxes-auth/sandboxes-auth/.
3. Delete the …/sandboxes-auth/ZG9ja2VyL2F1dGgvbWV0YWRhdGEvaHViL2RlZmF1bHQ=/ directory entirely.
4. Run sbx ls. The daemon respawned, triggered a sign-in, and all seven sandboxes reappeared with state intact.

[kiview]

Sorry for that @WhatisRT, we have a fix coming up for this in the next release, expected to drop this week.