agent-sandbox
AGENTS.md212 starsChanged 5 months agoMITView on GitHub
This file provides guidance to agents working in this repository. Agent Sandbox is a Go CLI plus Docker images and templates for running AI coding agents inside locked-down local sandboxes. Stable repo surfaces: Supported agents in the CLI: claude, codex, gemini, hermes, opencode, pi, copilot, factory. Repo-wide support is defined by the combination of: Do not infer product support from the checked-in .agent-sandbox/ tree. That directory only reflects which agent layers have been initialized for this repo's local development runtime.
- Reads credentials
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,700 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository5 other files it gives its agents.
- add-agentSkill
- plan-milestoneSkill
- plan-projectSkill
- planSkill
- plan-taskSkill
The file
We split this AGENTS.md into the rules it gives an agent
9 rules. About 0 are common, 4 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 27
Do not infer product support from the checked-in .agent-sandbox/ tree.
- Distinctive: line 31
Prefer these in order when describing or changing current behavior:
- Very specific: line 37
Treat docs/plan/ and docs/roadmap.md as planning or historical context, not as the source of truth for current implementation.
- Distinctive: line 140
Do not confuse template sources with generated runtime files.
- Very specific: line 184
Use /opt/proxy-python/bin/python3 for proxy Python tests.
- Very specific: line 230
After it merges, push a lightweight tag vX.Y.Z on the merge commit.
- Distinctive: line 244
Never amend a pushed commit.
- Distinctive: line 245
Every PR gets an automated Greptile review.
- Very specific: line 251
Use the add-agent skill or follow an existing agent end to end.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Instructions
This file provides guidance to agents working in this repository.
Repo Snapshot
Agent Sandbox is a Go CLI plus Docker images and templates for running AI coding agents inside locked-down local sandboxes.
Stable repo surfaces:
cmd/agentboxandinternal/- the Go CLI, runtime detection, scaffolding, and Docker invocation codeimages/- the base image, agent images, proxy image, and proxy enforcement tests.agent-sandbox/- generated runtime files for developing this repo locallyREADME.mdanddocs/- user-facing docs, agent setup guides, policy docs, and troubleshooting.github/workflows/- Go tests, proxy tests, image builds, release binaries, and per-agent version checks
Supported agents in the CLI: claude, codex, gemini, hermes, opencode, pi, copilot, factory.
Repo-wide support is defined by the combination of:
internal/runtime/agents.goimages/agents/<agent>/internal/embeddata/templates/<agent>/docs/agents/<agent>.md.github/workflows/check-<agent>-version.yml
Do not infer product support from the checked-in .agent-sandbox/ tree. That directory only reflects which agent layers have been initialized for this repo's local development runtime.
Source Of Truth
Prefer these in order when describing or changing current behavior:
- Code in
internal/andimages/ - Tests in
internal/**/*_test.goandimages/proxy/tests/ - User-facing docs in
README.md,docs/cli.md,docs/policy/schema.md, anddocs/agents/*.md
Treat docs/plan/ and docs/roadmap.md as planning or historical context, not as the source of truth for current implementation.
internal/embeddata/templates/ is the source of truth for files generated by agentbox init and agentbox switch.
Development Environment
This repo is usually developed from inside its own sandbox container. Network restrictions are real:
- Outbound traffic from the agent container must go through the proxy sidecar
- Direct outbound is blocked by iptables
- SSH is disabled, and Git remote URLs are rewritten to HTTPS
- Unrestricted git or network operations should be run from the host
Container baseline:
- Debian bookworm
- Non-root
devuser (uid/gid 501) - Zsh with minimal prompt
GODEBUG=http2client=0in the compose stack to avoid Go HTTP/2 issues through mitmproxy/workspacebind-mounted to the repo- Per-agent persistent state volumes plus
/commandhistory
Build local images with:
./images/build.shThe script supports base, proxy, every agent name, and all.
Runtime Layout
Generated runtime files live under .agent-sandbox/.
Key files:
.agent-sandbox/active-target.env- active agent and related runtime metadata.agent-sandbox/compose/base.yml- managed shared compose layer.agent-sandbox/compose/agent.<agent>.yml- managed agent-specific compose layer.agent-sandbox/compose/user.override.yml- shared user-owned compose overrides.agent-sandbox/compose/user.agent.<agent>.override.yml- per-agent user-owned compose overrides.agent-sandbox/policy/user.policy.yaml- shared user-owned policy.agent-sandbox/policy/user.agent.<agent>.policy.yaml- per-agent user-owned policy
Devcontainer mode also uses:
.devcontainer/devcontainer.json.devcontainer/devcontainer.user.json.agent-sandbox/compose/mode.devcontainer.yml.agent-sandbox/policy/policy.devcontainer.yaml
Managed files are regenerated. User-owned override and policy files are preserved across switches.
Legacy single-file layouts are no longer supported. If you encounter old docker-compose.yml or policy-*.yaml generated files, follow docs/upgrades/m8-layered-layout.md.
Code Map
Go CLI
internal/cli- Cobra commands and user-facing command behaviorinternal/runtime- path discovery, active target state, lifecycle helpers, compose selection, and legacy-layout detectioninternal/scaffold- file generation forinit,switch, devcontainer output, and runtime syncinternal/docker- Docker and Docker Compose invocation helpers plus image lookup logicinternal/embeddata- embedded template accessinternal/version- version metadatainternal/testutil- test helpers
Current root commands:
initswitcheditpolicyproxybumpupdownlogscomposeexecdestroyversioncompletion
Images
images/base/
- Shared base image
- Startup and firewall scripts such as
entrypoint.sh,init-firewall.sh, andinstall-proxy-ca.sh - Optional language stack installers under
images/base/stacks/
images/agents/
- One directory per supported agent
- Agent-specific Dockerfiles and any agent-specific config files
images/proxy/
- Proxy Dockerfile and entrypoint
render-policyfor policy rendering and merge logicaddons/enforcer.pyfor proxy enforcement- Python unit tests under
images/proxy/tests/
Templates Vs Runtime Files
Do not confuse template sources with generated runtime files.
- Edit
internal/embeddata/templates/when changing whatagentbox initoragentbox switchgenerates - Edit the checked-in
.agent-sandbox/tree only when adjusting this repo's local development runtime
Important template groups:
internal/embeddata/templates/compose/- shared compose layers and user override scaffoldsinternal/embeddata/templates/<agent>/cli/agent.yml- agent-specific CLI compose templateinternal/embeddata/templates/<agent>/devcontainer/devcontainer.json- agent-specific devcontainer templateinternal/embeddata/templates/policy.yamlanduser.policy.yaml- shared policy scaffoldsinternal/embeddata/templates/user.agent.policy.yaml- per-agent user policy scaffold
Network Policy
The stable high-level model is still:
- Proxy enforcement in the
proxysidecar - Firewall enforcement in the agent container
Security-critical files:
images/base/init-firewall.shimages/base/entrypoint.shimages/base/install-proxy-ca.shimages/proxy/addons/enforcer.pyimages/proxy/render-policy
Policy docs and examples live under:
docs/policy/schema.mddocs/policy/examples/all-agents.yaml
For one-off policy changes in a project sandbox, prefer the user-owned files under .agent-sandbox/policy/ over changing proxy code.
Testing Changes
Primary test commands:
go test ./...
/opt/proxy-python/bin/python3 -m unittest discover -s images/proxy/tests -p 'test_*.py'Use /opt/proxy-python/bin/python3 for proxy Python tests. It is the dev-image venv with mitmproxy, pytest, and
PyYAML; system Python does not have all proxy test dependencies.
Useful local verification steps:
./images/build.sh proxy
agentbox policy config
agentbox compose restart proxy
agentbox compose logs proxyTo sanity-check proxy enforcement inside a running sandbox:
curl -x http://proxy:8080 https://example.com
curl -x http://proxy:8080 https://github.comThe first request should be blocked. The second should succeed only if the active policy allows GitHub.
CI And Release
Key workflows:
.github/workflows/go-tests.yml- runs Go tests with coverage and builds the CLI.github/workflows/proxy-tests.yml- runs the proxy Python test suite.github/workflows/build-images.yml- builds and publishes the base, proxy, and all agent images.github/workflows/release-go-binaries.yml- builds release archives for tagged Go CLI releases
Per-agent version check workflows exist for:
claudecodexcopilotfactorygeminihermesopencodepi
Cutting a release
- Open a PR that moves the
[Unreleased]entries inCHANGELOG.mdunder## [X.Y.Z] - YYYY-MM-DDwith a one-line summary, keeps an empty[Unreleased]section on top, and bumps the--version vX.Y.Zexamples inREADME.mdandscripts/install-agentbox.sh. - After it merges, push a lightweight tag
vX.Y.Zon the merge commit.release-go-binaries.ymlbuilds the archives and opens a draft GitHub release with generated notes. - The maintainer publishes the draft and edits the notes. Publishing is outside the sandbox proxy's write allowlist, so an agent stops after reporting the draft release URL.
build-images.yml runs on pushes to main that touch images/ and on release events. A fix merged after a release's
image build reaches users through the next push-triggered build and agentbox bump.
Pull Requests
- Open agent-authored PRs as drafts with
gh api -X POST repos/{owner}/{repo}/pulls -F draft=true. Thegh prcommands are blocked in the sandbox; seedocs/github.md. - PRs are rebase-merged. A PR stacked on another branch needs
git rebase origin/mainafter its base lands, which requires a force-push of the PR branch. Ask the maintainer before any force-push and use--force-with-lease. - Never amend a pushed commit. Address review feedback in new commits.
- Every PR gets an automated Greptile review. Evaluate each comment, fix the valid ones in a new commit, and reply on
the thread with the commit and the test that covers it. Then post a PR comment containing
@greptile reviewso the new commit gets a fresh review.
Adding A New Agent
Use the add-agent skill or follow an existing agent end to end.
A complete new-agent change usually touches all of these:
internal/runtime/agents.goimages/agents/<name>/Dockerfileinternal/embeddata/templates/<name>/cli/agent.ymlinternal/embeddata/templates/<name>/devcontainer/devcontainer.jsondocs/agents/<name>.mdimages/build.sh.github/workflows/check-<name>-version.yml.github/workflows/build-images.ymlimages/proxy/render-policyimages/proxy/addons/enforcer.pyREADME.mdif the support matrix changes
Git And Customization Docs
Relevant docs:
docs/git.md- git credentials, SSH-to-HTTPS rewriting, and worktree caveatsdocs/github.md- repo-scoped GitHub API access throughgh api, token permissions, and the write allowlistdocs/dotfiles.md- dotfiles and shell customizationdocs/stacks/- optional language stacksdocs/images.md- image pinning and bump workflowdocs/troubleshooting.md- common issues and fixes
Target Platform
Primary target: Colima on Apple Silicon.
CI builds images for both linux/amd64 and linux/arm64, so avoid changes that silently assume only one architecture.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

