sandbox-agent: the docs say server, the justfile says daemon

One HTTP API in front of six different agents

The problem statement is three sentences long and each one is a design constraint. Coding agents need sandboxes, because you cannot let a model execute arbitrary code on your production servers, and because the existing SDKs assume local execution. Every coding agent is different, with proprietary APIs, event formats and behaviours, so swapping one means rewriting your integration. And sessions are ephemeral, because an agent transcript lives in the sandbox and disappears when the process ends. The answer to the second problem is the architecture: Sandbox Agent is a universal adapter, and each agent has its own adapter translating between the universal API and that agent's own interface. The agent list is Claude Code, Codex, OpenCode, Cursor, Amp and Pi. The answer to the first is placement, since the server runs inside the sandbox and exposes HTTP and SSE, and the answer to the third is a session schema you own rather than one you lose.

Transcripts live in the sandbox until you stream them out

The persistence story is the part that matters after the demo. Agent transcripts live in the sandbox, and when the process ends you lose everything, so the server streams events in a universal schema to your storage, with Postgres, ClickHouse or Rivet named as destinations, and the stated benefit is replay later and audit everything. That universal session schema is listed as a feature in its own right, described as a standardized schema that normalizes every agent's event format for storage and replay, which is the piece that makes the audit claim possible: six agents with six event vocabularies become one row format. The Inspector is the other half of the story, a built-in interface for inspecting sessions and events, documented at the /ui/ path on the same port the server listens on. So the loop is: agent runs, events normalize, stream lands in your database, and the Inspector shows you what happened while it was still running.

A static binary, one curl line, five build targets

The binary is described as a lightweight static Rust binary installable inside a sandbox with one curl command, and the file names the places it is expected to run: E2B, Daytona, Modal, Cloudflare Containers, Agent Computer, or Docker. The install line is this:

# Install it
curl -fsSL https://releases.rivet.dev/sandbox-agent/0.4.x/install.sh | sh
# Run it
sandbox-agent server --token "$SANDBOX_TOKEN" --host 127.0.0.1 --port 2468

The build recipe is in the justfile rather than the file, and it is a list worth reading: one target per platform, built through a shell script in the docker directory, covering x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, x86_64-pc-windows-gnu, x86_64-apple-darwin and aarch64-apple-darwin. Five binaries, one of them musl static, which is what makes a single file runnable inside a minimal sandbox image. Agent binaries are a separate step: sandbox-agent install-agent --all preinstalls them, and the file notes they will otherwise be installed lazily on first use, which is the difference between a cold start and a fast one.

The documentation says server, the build script says daemon

The same binary appears under two names. Every example in the file runs sandbox-agent server, and the components table describes a Rust daemon started as sandbox-agent server. The justfile, which is what a contributor actually runs, starts it as a daemon instead:

SANDBOX_AGENT_SKIP_INSPECTOR=1 cargo run -p sandbox-agent -- daemon start --upgrade

So a subcommand renamed from server to daemon, or a second alias nobody has removed, and a developer following the build script and a user following the documentation type different words for the same process. Two smaller details in the same file. The environment variable skips the Inspector for local work, which is why it is set during development and absent from the install instructions. And a recipe named install-fast-sa builds in release mode, deletes whatever is at ~/.cargo/bin/sandbox-agent and copies the new binary there, a shortcut that saves a path lookup and will happily overwrite an installed version without asking.

One token, and a flag that removes it

Authentication is a single value passed on the command line, and the documented default address is loopback on port 2468. The SDK takes the same two pieces in a connect call:

import { SandboxAgent } from "sandbox-agent";

const client = await SandboxAgent.connect({
  baseUrl: "http://127.0.0.1:2468",
  token: process.env.SANDBOX_TOKEN,
});

Two observations. The token travels in an environment variable on both sides, which is the right habit, and the base URL is a plain string with no scheme validation. And the file documents disabling auth outright for local work, with sandbox-agent server --no-token, which is convenient for a laptop and is one flag away from being a server on a network with a full agent inside it. The same port, 2468, serves the API, the event stream and the Inspector UI at /ui/, so anything that can reach the API can reach the interface as well unless you bind differently. Nothing in the visible text describes scopes, per-token identity or an audit log of who called what.

Bun users must trust five packages before the binaries run

The package manager split produces one genuinely surprising instruction. npm users get the SDK with npm install [email protected] and nothing else. Bun users are told, in a comment attached to the same install, to allow postinstall scripts for native binaries because they are required for SandboxAgent.start(), and the command that does it names five packages by platform:

bun pm trust @sandbox-agent/cli-linux-x64 @sandbox-agent/cli-linux-arm64 @sandbox-agent/cli-darwin-arm64 @sandbox-agent/cli-darwin-x64 @sandbox-agent/cli-win32-x64

The global CLI install repeats the same five-package trust list with a global flag, so the list has to be trusted twice on a machine that uses both paths. What the packages are is inferable from their names and nothing else: five platform-specific builds of the same command, which means an install pulls binaries for platforms you will never run. The versions are also pinned by range rather than exact, in the form 0.4.x, in every install line for the SDK, the CLI and the npx wrapper, so three separate installs can resolve to three different builds.

Docs and manifests on 0.4.x, newest tag a 0.5.0 candidate

Three sources give three version stories. The Cargo workspace package version is 0.4.2, and every internal crate in the workspace dependency list repeats 0.4.2 alongside its path. Every install instruction in the file asks for 0.4.x, including the release URL, which ends in sandbox-agent/0.4.x/install.sh. The release history, however, lists v0.5.0-rc.3 from 2026-03-30, then v0.4.2 from 2026-03-26, then v0.5.0-rc.2 from 2026-03-25. So the newest tag is a release candidate for a minor version that no documented install path requests, published four days after the 0.4.2 it sits above. The last commit on the default branch is dated 2026-06-19, three months after that tag, so the branch has moved on without producing another release. Whether 0.5.0 is finished is not something the repository answers.

A Rust workspace and a pnpm workspace, with no root test script

Two build systems sit side by side. The Cargo workspace takes members from server/packages/* and gigacode, and excludes two desktop crates under factory and foundry, which are Tauri shells kept out of the library build. Its dependency list is conservative to the point of being dated: axum at 0.7 with the websocket feature, tower-http with cors and trace, tokio at 1.36, reqwest at 0.11, and utoipa with an axum extension for schema generation. The edition is 2021 in a repository whose last commit is from 2026. The pnpm workspace runs turbo for build, dev, generate and typecheck, with biome for linting and lefthook for git hooks, and its prepare script is written to fail quietly outside a git checkout. What it does not have is a test script, even though vitest sits in the root devDependencies. The Rust tests run through the justfile instead, as cargo test --all-targets, with check and format as separate recipes. The examples directory is where the sandbox story becomes concrete, with one directory per provider named in the file and several more beside them: daytona, e2b, modal, cloudflare, vercel, agentcomputer, boxlite in two languages, computesdk, and plain docker in two flavours, alongside worked examples for permissions, custom MCP tools, custom skills, a mock agent, persistence to Postgres, to SQLite or to memory, and a file-system example.

Editorial conclusion

sandbox-agent is aimed at a specific and real problem: you want an agent to run somewhere isolated, and you want your application to keep the transcript after the process dies. It addresses that with an adapter per agent, one normalized event schema and streamed persistence, which is the right shape for the job. Three things to check first. The auth model is one token, and a documented flag turns it off entirely, so a deployment that binds anything other than loopback needs that token set deliberately. The version numbers disagree: documentation and manifests are on 0.4.x while the newest tag is a 0.5.0 release candidate, and the binary is installed from a moving 0.4.x path. And the daemon is named two different ways, once as server in the file and once as daemon in the build script, which is the kind of thing that costs an afternoon the first time you script against it. Apache 2.0, last push 2026-06-19.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rivet-dev/sandbox-agent on GitHub