A paused sandbox wakes for its own timers
A sandbox paused after its idle seconds wakes by itself shortly before the soonest timer of one of its processes is due: a sleep, a poll or wait with a timeout, a timerfd, alarm() or timer_create() that was pending the whole time it sat idle. A loop that polls every ten minutes, or sleep 600 && ./next.sh, now runs on time instead of waiting for the next call. Each such wake is billed as any wake. A timer armed and fired again and again while the sandbox was idle wakes nothing, and a sandbox you paused yourself never wakes on its own.
Same day.
- Catalog MCP servers in a sandbox are withdrawnGET /v1/mcp/catalog and /v1/sandboxes/{id}/mcp return 404 route_not_found, with a message that says what to use instead.
- Environment variables on createPOST /v2/sandboxes and POST /v1/sandboxes take env: up to 32 variables and 32,768 bytes of names and values, set for every command and pr…
- Resize a running sandboxPOST /v2/sandboxes/{id}:update takes vcpu, memoryGB and diskGB (and POST /v1/sandboxes/{id}:resize takes vcpu, memoryMiB and diskMiB).
- Run a sandbox as root with one settingPOST /v2/sandboxes and POST /v2/sandboxes/{id}:update take user: runtime (the default: uid 1000, with passwordless sudo) or root.
- Job secrets can be deleted, and their names reusedPOST /v1/secrets/{id}:delete deletes a job secret (with an optional expectedVersion), and GET /v1/secrets/{id} returns one.
- A fork makes all its copies or nonePOST /v2/sandboxes/{id}:fork with count is admitted as one start: when the copies together would pass one of your limits (running vCPU or…
- Network rules on createPOST /v2/sandboxes takes network (the same {default, rules} that PUT /v2/sandboxes/{id}/network takes), and POST /v1/sandboxes and the ru…
- A command runs to its endPOST /v2/sandboxes/{id}:exec (and /v1/sandboxes/{id}:exec, and the runtime_sandboxes_exec MCP tool) with no timeoutMs no longer stops the…