Daytona Operations (read-only)

Bench sandboxes run on Daytona. Your env has DAYTONA_API_KEY (org-level, powerful) and DAYTONA_ORGANIZATION_ID.

Non-negotiable rules

READ-ONLY. Never POST/DELETE against sandboxes or snapshots - other agents (including you) are running inside them. Deleting a sandbox kills a live session.
Toolbox/exec endpoints can be minutes-slow during Daytona degradation; prefer control-plane reads (fast, ~300ms).

Canonical patterns

Base: https://app.daytona.io/api with Authorization: Bearer $DAYTONA_API_KEY

List sandboxes (state, snapshot, errorReason):

curl -s https://app.daytona.io/api/sandbox -H "Authorization: Bearer $DAYTONA_API_KEY" \
  | jq '.[] | {id, state, snapshot, errorReason, updatedAt}' | head -50

One sandbox:

curl -s https://app.daytona.io/api/sandbox/SANDBOX_ID -H "Authorization: Bearer $DAYTONA_API_KEY" \
  | jq '{state, snapshot, errorReason, autoStopInterval, updatedAt}'

Snapshots (bench images are bench-agent-v*; weekly cron builds bench-agent-oc-<version>):

curl -s "https://app.daytona.io/api/snapshots?limit=100" -H "Authorization: Bearer $DAYTONA_API_KEY" \
  | jq '.items[] | {name, state, errorReason, lastUsedAt}'

Map a Bench session to its sandbox: the Session table has sandboxId; ask the user for the session URL id, or use session_search.

Cross-referencing with Watchtower

Daytona tells you infra state; Watchtower (Athena, profile watchtower, NEVER CloudWatch) tells you what the products did. Typical diagnosis: sandbox state + errorReason from Daytona, then error-level events/vercel_logs from watchtower.events / watchtower.vercel_logs for the same window (partition filters year/month/day/hour, zero-padded).

Known failure modes