Skip to main content
Daytona provides secure, high-performance 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 and sign a short-lived access token, then use the Daytona SDK to inject that token and mount Mesa inside the sandbox. The general flow for any sandbox integration is:
  1. 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.
  2. Inside the sandbox — install the mesa CLI and run mesa mount --daemonize with the token in MESA_ACCESS_TOKEN.
  3. Run your agentcd into 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.
For details on FUSE setup, system dependencies, and container configuration, see POSIX Mount.

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>.
The image installs the latest Mesa CLI when Daytona builds it. Rebuild the image to pick up a newer CLI.

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.
For runnable versions that open an interactive shell in the mounted repo, see the TypeScript and Python examples.
Daytona’s Secrets API only substitutes placeholders in HTTPS request headers. MesaFS authenticates over gRPC (HTTP/2), which the substitution proxy doesn’t handle, so a token passed as a Secret never reaches the mount. Inject MESA_ACCESS_TOKEN as a plain environment variable instead.
An access token is minted once with a fixed TTL and is never refreshed: there is no background rotation and no access-token replacement. Tokens default to a 15 minute TTL and max out at 4 hours, so mint one whose TTL covers the whole agent session. After it expires, filesystem operations in the sandbox fail with authentication errors. To continue past expiry, mint a fresh token on the host (the private key lives only outside the sandbox) and remount inside the sandbox with the new token in MESA_ACCESS_TOKEN.

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 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. This is the most common setup issue in sandbox environments. See POSIX Mount for more info.