Problem
Settings → Sandbox offers seven remote providers (E2B, Daytona, Vercel Sandbox, Upstash Box, Tenki, Railway, Ascii Box), each with different limits, credentials, and failure modes. That is too many to support well and too many for a user to choose between. This is slice S1a of the hosted sandbox work (AKR-133).

Goal
Akeru supports four sandbox targets: Local, E2B, Vercel Sandbox, and a user-managed Cloudflare Sandbox bridge. Akeru Cloud is reserved: selecting it gives an explicit "unsupported" error until AKR-135 lands. The other adapters and the old Computer implementation are retired, and existing installs migrate cleanly.
- Saved bot sandboxes, settings values, and stored credentials that point at a retired provider migrate, keeping settings, archives, and delegation history.
- Browser support is a per-provider capability. Cloudflare does not expose preview ports, so connectors such as Executor and Tinyfish start there without a browser attachment instead of failing. E2B and Vercel still attach the browser to both connectors.
- Cloudflare targets the official Sandbox SDK 0.x bridge HTTP API. Pause and resume, and preview ports, are not available; idling follows the Worker timeout. The deployment must configure durable storage. SDK 1.x is not supported.
- Web, desktop, and mobile Settings show the same supported list, and user docs match.
Acceptance criteria
How to verify
On the branch, run the focused sandbox and migration tests, touched-path vp lint, and the five package typechecks (server, web, contracts, client-runtime, mobile). Then open Settings → Sandbox on an isolated dev server seeded with a bot that used a retired provider, and confirm it migrated and the list shows only the supported targets.
Out of scope
- Provisioning Akeru Cloud sandboxes and billing (AKR-135)
- Any
apps/cloud changes
- Live restart reattach for the remaining providers (AKR-87)
Context
Where the work is
Local branches akeru-cloud/sandboxes, akeru-cloud/sandbox-integration, and t3code/cloud-sandbox-settings on Leo's machine; not pushed, no PR. After a rebase the S1a commits are:
2e310ad2b feat(sandbox): simplify providers and add Cloudflare bridge support (was a916b32d8)
0e9e39fde feat(settings): show supported sandboxes across clients (was e0d0846cd)
eae51cd57 fix(sandbox): start connectors without a browser on Cloudflare (was 6cea419fa)
akeru-cloud/sandboxes continues with later AKR-133 work on top (private workspaces, cloud provisioning).
Verification so far (2026-10-06)
- S1a: 265 focused tests across 30 touched or added files passed; targeted lint on 76 paths; all five package typechecks passed. Independent review findings were fixed with regression tests. Clean working tree, no suppressions, touched source files under 800 lines, no
apps/cloud changes, no dev servers, no live Akeru data.
- Review fix: both Executor and Tinyfish Cloudflare acquisition tests failed before the fix and passed after, with the browser attachment skipped and the MCP manager initialized. E2B and Vercel still forward browser attachments. 6 files and 52 tests passed; touched-path lint,
vp run --filter akeru-bot typecheck, and git diff --check passed; sandbox user docs and a patch changeset updated.
- Not checked: rendered desktop and mobile states, live providers, and live Cloudflare or connector accounts. Integrated UI verification belongs to the parent (AKR-133) workflow; the implementation worker was told not to start dev servers.
- No external npm HTTP client for the Cloudflare bridge was found, so the adapter calls the bridge HTTP API directly.
Parent: AKR-133. Related: AKR-87, AKR-121, AKR-135.
Created with Claude Opus 5.5 in Claude Code.
Problem
Settings → Sandbox offers seven remote providers (E2B, Daytona, Vercel Sandbox, Upstash Box, Tenki, Railway, Ascii Box), each with different limits, credentials, and failure modes. That is too many to support well and too many for a user to choose between. This is slice S1a of the hosted sandbox work (AKR-133).
Goal
Akeru supports four sandbox targets: Local, E2B, Vercel Sandbox, and a user-managed Cloudflare Sandbox bridge. Akeru Cloud is reserved: selecting it gives an explicit "unsupported" error until AKR-135 lands. The other adapters and the old Computer implementation are retired, and existing installs migrate cleanly.
Acceptance criteria
mainHow to verify
On the branch, run the focused sandbox and migration tests, touched-path
vp lint, and the five package typechecks (server, web, contracts, client-runtime, mobile). Then open Settings → Sandbox on an isolated dev server seeded with a bot that used a retired provider, and confirm it migrated and the list shows only the supported targets.Out of scope
apps/cloudchangesContext
Where the work is
Local branches
akeru-cloud/sandboxes,akeru-cloud/sandbox-integration, andt3code/cloud-sandbox-settingson Leo's machine; not pushed, no PR. After a rebase the S1a commits are:2e310ad2bfeat(sandbox): simplify providers and add Cloudflare bridge support (wasa916b32d8)0e9e39fdefeat(settings): show supported sandboxes across clients (wase0d0846cd)eae51cd57fix(sandbox): start connectors without a browser on Cloudflare (was6cea419fa)akeru-cloud/sandboxescontinues with later AKR-133 work on top (private workspaces, cloud provisioning).Verification so far (2026-10-06)
apps/cloudchanges, no dev servers, no live Akeru data.vp run --filter akeru-bot typecheck, andgit diff --checkpassed; sandbox user docs and a patch changeset updated.Parent: AKR-133. Related: AKR-87, AKR-121, AKR-135.
Created with Claude Opus 5.5 in Claude Code.