forked from bots-garden/ori
| ✨ Workspace panel, selectors, previews, desktop app, sandbox template, resizable file tree, light/dark theme | 1 | # Handoff — 2026-09-17 — sbx auto-stop: why the ori sandbox goes `stopped` alone |
| 2 | ||
| 3 | ## Conclusion (verified) | |
| 4 | ||
| 5 | 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). | |
| 6 | ||
| 7 | 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. | |
| 8 | ||
| 9 | ## The only switch: `detached: true`, create-time, via `sbx run -d` | |
| 10 | ||
| 11 | - `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`). | |
| 12 | - `sbx create` has no `--detached` flag; `Detached` cannot be changed afterwards (no PATCH). An existing sandbox must be `sbx rm`'d first. | |
| 13 | - `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. | |
| 14 | - 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). | |
| 15 | ||
| 16 | ## Next steps (user's decision) | |
| 17 | ||
| 18 | 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). | |
| 19 | 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. | |
| 20 | 3. Still uncommitted since 2434cc7 — the user has deferred the commit repeatedly. |