4. Choose a sandbox provider

The agent does its work inside a sandbox — an isolated environment with a clone of the target repo and a place to execute commands. Sinatra ships with two providers.

Option A — Daytona (recommended for production)

Daytona spins up a managed cloud sandbox per agent run. Each tenant's runs are fully isolated.

1. Sign up at daytona.io and grab an API key.

2. Set in your env:

   SANDBOX_PROVIDER=daytona
   DAYTONA_API_KEY=daytona_xxxxxxxxxxxxxxxxxxxx

3. Sinatra ships a base sandbox image (snapshot/) named sinatra-agent by default. The first time the worker runs, it'll create the snapshot in your Daytona account if it doesn't exist. Per-repo overrides are available via .sinatrarc.sandbox.snapshot_name.

Option B — Docker (recommended for evaluation)

The docker provider runs each sandbox as its own container off the sinatra-agent image, mirroring how Daytona runs the agent in production. Ideal for laptop evaluation.

SANDBOX_PROVIDER=docker

DAYTONA_API_KEY is not needed when using the docker provider.

What the docker provider does

• Builds (one-time) the sinatra-agent-base and sinatra-agent images from snapshot/.
• Creates a container named sinatra-<id> for each run, labeled sinatra=true.
• Clones the target repo inside the container.
• Copies host ~/.claude/.credentials.json and ~/.local/share/opencode/auth.json into the container at create time so subscription auth works without inheriting the rest of the host process state.
• Runs the agent harness (Claude Code, OpenCode, etc.) inside the container.

When to wipe

Containers are not auto-cleaned. Between sessions or if something goes wrong:

docker rm -f $(docker ps -aq --filter label=sinatra=true)

Any in-flight workflow that referenced one will fail and can be re-run.

Trade-offs

Continue to Supply LLM keys →