# 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.