Skip to main content
Sprites (by Fly.io) provides stateful, disposable sandboxes that work well with Mesa. This guide shows the full end-to-end flow: use the Mesa SDK outside the sandbox to set up resources, then use the Sprites SDK to configure and mount Mesa inside the sandbox. The general flow for any sandbox integration is:
  1. Outside the sandbox — use the Mesa SDK (TypeScript or Python) to create repos, sign a short-lived access token, and orchestrate your workflow.
  2. Inside the sandbox — install the mesa CLI, pass the token in as MESA_ACCESS_TOKEN, and run mesa mount --daemonize.
  3. Run your agentcd into the mount path and launch your agent (ex. Claude Code, Codex, or a custom agent). Any file edits are automatically persisted back to Mesa.
For details on FUSE setup, system dependencies, and container configuration, see POSIX Mount.

Create and mount

Sprites are Debian-based, so the standard Mesa install script works directly. Use execFile("sh", ["-c", ...]) to run shell commands — the SDK’s exec() method splits on whitespace and doesn’t support pipes or &&.
The layout scopes the token: it can reach the repositories the layout declares and nothing else. A plain mesa mount then shows exactly those repositories under the organization browse tree. To mount the layout’s own paths instead, serialize workspace.layout() with JSON.stringify(...) in TypeScript or json.dumps(...) in Python, write it into the sandbox, and mount with mesa mount --layout <file>.

Tips

  • Use scoped, short-lived access tokens. Sign a dedicated token for each sandbox session with only the scopes it needs. It’s signed locally with your private key (which never enters the sandbox) and expires on its own. See Authentication for details.
  • Pick a TTL that covers the session. Tokens default to a 15 minute TTL and max out at 4 hours, and a mount keeps the token it started with for its whole lifetime. If the token expires mid-session, filesystem operations in the sprite start failing with authentication errors; mint a fresh token on the host and remount.
  • Use --daemonize. Always run mesa mount --daemonize in sandbox environments so Mesa runs as a background process and doesn’t block your agent’s terminal.
  • Don’t forget user_allow_other. See POSIX Mount for the most common setup issue in sandbox environments.
  • Sprites are stateful. Unlike ephemeral sandboxes, Sprites persist state across connections. The Mesa install survives a stop and resume, but the mount does not: mint a fresh token on the host and re-run mesa mount --daemonize after resuming.