Each agent works on its own cloud machine: your repos cloned in, credentials scoped below any developer, and nothing left behind at teardown. Give it exactly the tools and access the job needs, and no more.
Every session starts in its own Linux container with the repos already cloned and gh authenticated, and the container is destroyed when the session ends. Size it up to 16 vCPU, 64 GiB of memory, and 24 hours when the job needs it.
One sandbox per session, destroyed at the end
Agents never hold a developer's identity. They act through the Ellipsis GitHub App with the repos and permissions you granted at install, and repo administration is not one of them. Your branch protections apply with no bypass, and an agent cannot edit protections, settings, or collaborators, no matter what its prompt says.
Branch protections hold, with no bypass for agents
Sandbox secrets inject credentials you mint, so you choose the blast radius: give a debugging agent read-only AWS keys and it can tail production logs but never touch a resource. Values are stored write-only. Nothing lands in the config file, and nothing can be read back out.
sandbox: variables: - name: AWS_ACCESS_KEY_ID - name: AWS_SECRET_ACCESS_KEYWrite-only secrets, injected only where named
Each sandbox gets a GitHub token narrowed to the permissions and repositories in the agent's config, enforced by GitHub when the token is minted. Anything not granted, the agent cannot reach, no matter what its prompt says.
A per-session token, narrowed in YAML
A setup script runs once at image build, after your repos are checked out, and the result is snapshotted. Dependency installs happen on the first session; every session after boots the warm image. Per-session lifecycle hooks cover whatever should not be cached.
sandbox: image: setup: | poetry install pnpm install --frozen-lockfileSetup runs once, every session after boots warm
The full environment, from the tooling in the image to the credentials that die at teardown.
Every session gets its own Linux machine, destroyed when the session ends, so nothing an agent installs or breaks leaks into the next one.
Repos are checked out before the agent starts, with gh already authenticated against them.
Python 3.13, Node.js 22 with npm, git, the GitHub CLI, curl, and a C/C++ toolchain in every image.
Minted for that sandbox alone and expiring in one hour, which is also why a session never outlives its credential.
A read_only permission map mints a token that can read contents, issues, metadata, and pull requests, and write nothing.
List repositories in the config and the token reaches exactly those names; the clone itself uses a separate credential that never enters the sandbox.
Stored values inject only into agents that name them and are never readable back through the dashboard, API, or CLI.
Model calls route through Ellipsis with a per-session key; a real provider key never enters the sandbox.
1 vCPU and 4 GiB by default, sized per agent in YAML up to 16 vCPU and 64 GB of memory.
Built per repository set, commit, and image definition; a new commit re-runs setup on the latest image, so installs cover only what changed.
post_start and post_clone run on every session and are never cached; a hook that exits non-zero fails the session loudly.
Open a live sandbox in a browser IDE or preview any TCP port, gated on org membership. Lock it per agent with ellipsis.ide false.
Your repositories, cloned and checked out with gh already authenticated; base tooling (Python 3.13, Node.js 22, git, the GitHub CLI, curl, a C/C++ toolchain); whatever your image definition and hooks added; and scoped credentials: a one-hour GitHub token minted for that sandbox alone plus the environment variables the config names.
No. Each session runs on its own machine with its own GitHub token, and no session shares a token with another. The token is narrowed to the permissions and repositories the config grants, enforced by GitHub at the mint, and everything is revoked or expires when the sandbox is torn down.
Three fields with different lifetimes: image.dockerfile_append adds RUN instructions to the base image for toolchain installs, image.setup runs after repositories are checked out and its results are captured in the cached image, and hooks (post_start, post_clone) run on every session for anything that should not be cached, like authenticating a CLI.
No. The image is cached per repository set, commit, and image definition. A session at a commit that already has an image starts with everything in place; a session at a new commit starts from the most recent image and re-runs setup on top, so package managers install only what changed.
The default is 1 vCPU, 4096 MiB of memory, and a one-hour timeout. Per agent, environment.compute sets cpu from 0.125 to 16 vCPU, memory from 512 MB to 64 GB, and timeout from 60 seconds up to the one-hour maximum, which matches the GitHub token lifetime.
Store the value once with agent variable set or the dashboard, then name it under environment.variables in the config. Only agents that name a secret receive it, stored values are write-only and never readable back out, and injected values die with the sandbox.
Yes. Open a live session in a browser IDE showing the same working tree the agent is editing, with a terminal, and preview any TCP port a dev server listens on. Access is gated on org membership, so links are safe to share internally, and ellipsis.ide: false locks a sensitive agent shut.