- Outside the sandbox: use the Mesa SDK (TypeScript or Python) to create repos, sign a short-lived access token, and orchestrate your workflow.
- Inside the sandbox: install the
mesaCLI, configure it with a short-lived access token, and runmesa mount --daemonizeto mount your repos as local directories. - Run your agent:
cdinto the mount path and launch your agent (e.g. Claude Code, Codex, or a custom agent). Any file edits are automatically persisted back to Mesa.
Sandbox setup
Superserve sandboxes run on a FUSE-enabled kernel, and the Mesa installer apt-installsfuse3 as a dependency, so the standard Mesa install script works on every Superserve template out of the box. Because Superserve sandboxes are full Firecracker microVMs, you don’t need user_allow_other or chmod 666 /dev/fuse.
Custom template
For faster startup, pre-install the Mesa CLI into a custom Superserve template so each sandbox boots with the Mesa CLI already installed: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 from your API key (which never enters the sandbox) and expires on its own. See Mesa’s Authentication docs for details.
- Use
--daemonize. Always runmesa mount --daemonizein sandbox environments so Mesa runs as a background process and doesn’t block your agent’s terminal. - Build a custom template for production use. Pre-installing the Mesa CLI avoids the install overhead on every sandbox creation.
- Mount path follows
$HOME. Superserve’s guest agent setsHOME=/home/user, so the mount lands at/home/user/.local/share/mesa/mnt/<org>/<repo>. Use~/.local/share/mesa/mnt/...and it resolves correctly.