fix(sandbox): ship agent templates, make start.sh re-runnable, and report crashes

Closed
SA
2mo ago
+133-5

Cloud sandboxes had three independent defects, all of which would still be
broken the day after an image rebuild.

The image never copied packages/agent-setup/templates, so every boot logged
"agent hooks will NOT work on this host" and eight setup actions failed. Agents
ran but never reported starting, finishing, or asking a question — for as long
as sandboxes have existed. host-service resolves them as agent-templates
beside its own bundle, so they now land at /app/agent-templates, the same
placement the CLI tarball uses.

start.sh was not safe to run twice. Both of its branches destroy work in
progress — the clone path wipes the directory, the fetch path moves the branch
onto the remote's head and orphans commits an agent made and hadn't pushed.
That was survivable only while nothing ever ran the script twice, which stops
being true the moment anything restarts it or updates in place. The repository
bootstrap is now fenced behind a marker written only on success, so an
interrupted first run retries and every later run falls through to serving.

Finally, sandbox crashes were invisible, and not because provisioning forgot a
variable: the host-service Sentry DSN is compiled into the desktop bundle at
desktop build time and handed over when the desktop spawns a host. A sandbox is
started by the API and never sees a desktop build, so it could never receive
one. Sandboxes now report to their own project via SENTRY_DSN_SANDBOX on the
API — separate because that project means the host service on people's
desktops, and because release means opposite things on the two surfaces: a
version users happen to have installed versus one we deploy and converge.
Events carry the cloud workspace id, image tag and provider; the workspace id
is what joins a provisioning failure recorded against the API to a runtime
failure recorded against the sandbox.

Notably absent: restartOnFailure. Nothing supervises host-service, so a restart
is the obvious reflex — but it has never been observed to exit. The container
is healthy throughout the investigation above; what looked like a crash was the
desktop calling procedures a 12-day-old image had never heard of. Restarting an
unexplained exit would convert a bug worth investigating into a wobble nobody
sees, and it does nothing for the failure actually hit since: a missing
environment variable throws identically five times and dies anyway. Worth
revisiting once startup errors reach Sentry, which they do not yet.

Verified against a real sandbox provisioned from the live image and torn down
afterwards. Full host-service suite (1439 pass) and trpc suite (122 pass) green.

https://claude.ai/code/https://claude.ai/code/session_01HmfE4Qm77AwKUxJeFVMetY

Summary by CodeRabbit

  • New Features

    • Added separate Sentry configuration for host services and cloud sandboxes.
    • Sandbox error reports now include workspace, image, provider, and run-mode context.
    • Sandbox builds now include agent setup templates for more reliable hook execution.

  • Bug Fixes

    • Improved sandbox startup so interrupted repository setup can retry safely.
    • Prevented repeated repository initialization on subsequent starts.

  • Documentation

    • Documented sandbox telemetry configuration and local-development limitations.