Handoff — 2026-09-17 — sbx auto-stop: why the ori sandbox goes `stopped` alone

Conclusion (verified)

sandboxd auto-stops a sandbox 30 s after its last CLI sentinel session closes. sbx create holds one only while it runs, so with the documented sbx create … -p 8888:8888 command the webapp dies 30 s after the prompt comes back. Nothing the browser does keeps it up. Daemon log proving it: ~/Library/Application Support/com.docker.sandboxes/sandboxes/sandboxd/daemon.log (sbx daemon status prints the path).

Source anchors (in sandboxes/): sandboxd/pkg/server/backend_dockernext.go — sessionTracker, holdSession, WithAutoStopDelay(30*time.Second) in setupDockerNextBackend; cli-plugin/commands/sentinel.go (openSentinelConn, holdSentinel); cli-plugin/commands/create.go executeCreateAndReleaseSession; sandboxapi/openapi.yaml sessionHold + detached field.

The only switch: `detached: true`, create-time, via `sbx run -d`

sbx run -d claude . --template k33g/ori:0.0.0 --kit ./kits/ori --name ori -p 8888:8888 creates the sandbox with Spec.Detached=true → holdSession logs "detached; not auto-stopping" and never stops it. sbx run accepts the same flags as sbx create (checked docs/yml/sbx_run.yaml).
sbx create has no --detached flag; Detached cannot be changed afterwards (no PATCH). An existing sandbox must be sbx rm'd first.
sbx run -d --name ori on an existing NON-detached sandbox restarts it without holding a sentinel, so it stays up — until the next sbx exec/sbx run session ends, which re-arms the 30 s stop. Fragile; prefer recreating.
The 30 s delay is hard-coded; no sbx settings key, no env var (grep for autoStop outside the backend file finds only an e2e feature name).

Next steps (user's decision)

The user was recreating with sbx run -d and testing when the session ended — result not yet reported. Expected in the daemon log: session disconnected (detached; not auto-stopping). This likely also explains the "offline" WebSocket symptom of the earlier handoff (the container was already stopping).
DONE: quickstart.md, kits/ori/README.md, docs/en|fr/how-to/run-in-a-sandbox.md switched to sbx run -d with the explanation. If the test shows sbx run -d behaves differently from expected (e.g. --name + workspace positional interplay), fix the docs accordingly.
Still uncommitted since 2434cc7 — the user has deferred the commit repeatedly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# Handoff — 2026-09-17 — sbx auto-stop: why the ori sandbox goes `stopped` alone

## Conclusion (verified)

sandboxd auto-stops a sandbox 30 s after its **last CLI sentinel session** closes. `sbx create` holds one only while it runs, so with the documented `sbx create … -p 8888:8888` command the webapp dies 30 s after the prompt comes back. Nothing the browser does keeps it up. Daemon log proving it: `~/Library/Application Support/com.docker.sandboxes/sandboxes/sandboxd/daemon.log` (`sbx daemon status` prints the path).

Source anchors (in `sandboxes/`): `sandboxd/pkg/server/backend_dockernext.go` — `sessionTracker`, `holdSession`, `WithAutoStopDelay(30*time.Second)` in `setupDockerNextBackend`; `cli-plugin/commands/sentinel.go` (`openSentinelConn`, `holdSentinel`); `cli-plugin/commands/create.go` `executeCreateAndReleaseSession`; `sandboxapi/openapi.yaml` `sessionHold` + `detached` field.

## The only switch: `detached: true`, create-time, via `sbx run -d`

- `sbx run -d claude . --template k33g/ori:0.0.0 --kit ./kits/ori --name ori -p 8888:8888` creates the sandbox with `Spec.Detached=true` → `holdSession` logs "detached; not auto-stopping" and never stops it. `sbx run` accepts the same flags as `sbx create` (checked `docs/yml/sbx_run.yaml`).
- `sbx create` has no `--detached` flag; `Detached` cannot be changed afterwards (no PATCH). An existing sandbox must be `sbx rm`'d first.
- `sbx run -d --name ori` on an existing NON-detached sandbox restarts it without holding a sentinel, so it stays up — until the next `sbx exec`/`sbx run` session ends, which re-arms the 30 s stop. Fragile; prefer recreating.
- The 30 s delay is hard-coded; no `sbx settings` key, no env var (grep for `autoStop` outside the backend file finds only an e2e feature name).

## Next steps (user's decision)

1. The user was recreating with `sbx run -d` and testing when the session ended — result not yet reported. Expected in the daemon log: `session disconnected (detached; not auto-stopping)`. This likely also explains the "offline" WebSocket symptom of the earlier handoff (the container was already stopping).
2. DONE: `quickstart.md`, `kits/ori/README.md`, `docs/en|fr/how-to/run-in-a-sandbox.md` switched to `sbx run -d` with the explanation. If the test shows `sbx run -d` behaves differently from expected (e.g. `--name` + workspace positional interplay), fix the docs accordingly.
3. Still uncommitted since 2434cc7 — the user has deferred the commit repeatedly.

Handoff — 2026-09-17 — sbx auto-stop: why the ori sandbox goes stopped alone

Conclusion (verified)

The only switch: detached: true, create-time, via sbx run -d

Next steps (user's decision)

Handoff — 2026-09-17 — sbx auto-stop: why the ori sandbox goes `stopped` alone

The only switch: `detached: true`, create-time, via `sbx run -d`