Tools
Choose a sandbox
Some tasks need more than an API call. Converting a batch of files, running a script against data the agent just fetched, or exploring a repository all require somewhere to actually execute things. A sandbox is that somewhere: a per-agent, per-session workspace with a shell and a filesystem.
toolsets = ["sandbox-remote"]Which backend
| Runs where | Isolation | Use it for | |
|---|---|---|---|
sandbox-local | On the host, beneath LOCAL_SANDBOX_ROOT | None - it is a directory, not a boundary | Trusted development work you are watching |
sandbox-remote | In a separate sandbox worker | Process and host isolation | Anything autonomous, untrusted, or production |
The distinction is a security one. sandbox-local is
convenient and it executes on your host; treat it as a development affordance rather than a
containment strategy. Anything where the agent decides what to run without a person reading it
first belongs on the remote backend.
Treat execution as a serious capability
Pair command execution with:
- An explicit autonomy level, so consequential commands need a person.
- Credentials scoped to what the task needs, not the operator's own.
- A blast radius limit so one confused run cannot make sweeping changes.
- Workspace retention appropriate to whatever data ends up in there.
For repository work specifically, Workbench wraps this pattern in a test gate and a pull request rather than leaving the agent loose in a checkout.
Next
- Run coding work in an isolated factory - repository changes with a gate.
- Blast radius limiter - cap writes per run.
- - environment variables and tool inputs.