- Outside the sandbox — the orchestrator holds the private key. Use the Mesa SDK (TypeScript or Python) to create repos, then sign a short-lived access token locally with
mesa.fs({ layout, ttl }).token(). The layout scopes the token to the repositories it declares. Only the token crosses into the sandbox; the private key never does. - Inside the sandbox — install the
mesaCLI and runmesa mount --daemonizewith the token inMESA_ACCESS_TOKEN. - 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.
Image setup
First, ensure that your Daytona image is properly configured. This example uses Daytona’s declarative image builder to install Mesa and configure FUSE in the image.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>.Create and mount
The following examples create a temporary repo, mount it in a Daytona sandbox, write and read a file, and then delete both resources.Tips
- Use access tokens, not the private key, inside sandboxes. Tokens expire on their own, can’t be used to sign further access tokens, and leave nothing behind to clean up. See Authentication 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. - Don’t forget
user_allow_other. This is the most common setup issue in sandbox environments. See POSIX Mount for more info.

