IDEs & workspace profiles

Open the isolated workspace in VS Code, Cursor, or Windsurf, and install the agents your developers use into the image.

Attach with Dev Containers

AgentBox sits under Git, not under the editor. Any tool that runs git inside the workspace is brokered unmodified, because startup writes a managed gitconfig that routes every GitHub URL to the broker with the workspace token and runtime assertion attached. So an IDE agent (Cursor, Copilot, Windsurf, Claude Code in VS Code) is covered exactly to the extent that its terminal, Git, and tool calls execute inside the workspace container. .devcontainer/devcontainer.json makes that the default.

docker compose up -d --build
# then: Command Palette → "Dev Containers: Reopen in Container"

The editor UI stays on your machine. Its server, terminal, Git, and agent commands run as node inside the workspace service with the entrypoint intact. The devcontainer sets no image, mounts, ports, capabilities, or lifecycle commands: the Compose service definition is the only source of workspace privileges, and a test fails if that changes. Closing the window leaves the broker and its audit trail running.

The devcontainer also turns off the editor's own Git credential injection (github.gitAuthentication, git.terminalAuthentication, integrated askpass), so your laptop's GitHub login is never forwarded into container Git operations. Direct GitHub access from the container is denied by the egress proxy regardless.

Shells opened by the editor

Shells the editor opens, like any docker compose exec session, do not pass through the container entrypoint. The image therefore installs /etc/profile.d/agentgate.sh, and the entrypoint adds it to ~/.bashrc, so login and interactive shells export the model-gateway token (ANTHROPIC_AUTH_TOKEN) exactly as PID 1 has it. A bare non-interactive docker compose exec workspace claude ... gets no profile; wrap it as bash -lc '...'. agentgate doctor reports which case you are in.

Let the IDE server download

The editor installs its headless server into the container on first attach and fetches extensions from its marketplace. The workspace network has no route out, so those hosts must be allowlisted. examples/egress.ide.json is the default allowlist plus the VS Code server and marketplace hosts, Cursor's server host, and Open VSX:

echo "AGENTGATE_EGRESS_CONFIG_PATH=./examples/egress.ide.json" >> .env
docker compose up -d --force-recreate egress-proxy

Vendor hosts change; if the attach fails with a download error, read the egress deny line in the proxy log for the host it wanted and add it. Extensions installed into the container run as the workspace user with the same reach as the agent; treat them like any other dependency.

Approvals from the editor. A push that policy routes to approval fails in the IDE's Git output with the request ID. Approve it from the host CLI or the approval web UI, then push again. Nothing in the container can approve its own request.

Remote SSH is not supported into this topology, on purpose. The workspace network is internal, and Docker cannot publish a port from an internal-only network. Dev Containers attaches over docker exec and needs no listener.

Running AgentBox on the laptop instead. You can run agentd locally, run node src/workspace-setup.js against your own home directory, and use Cursor natively; Git then routes through the broker and you get policy, approvals, and audit. You do not get isolation: the agent runs as your OS user and can read the client token, the admin socket, and every other credential on the machine. Use this to try the policy model, never as the enforcement boundary.

Workspace profiles

Language dependencies and AI tools are installed in a derived image at build time, where registries are reachable; at run time only the egress allowlist and the model gateway are.

examples/workspace-claude-code.Dockerfile is the first profile: the base workspace plus a pinned Claude Code, which honours the ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN that point at the model gateway, so its model traffic is key-injected, path-allowlisted, and budgeted like any other. With a runtime assertion present, the profile also exports ANTHROPIC_CUSTOM_HEADERS (the assertion as x-agentgate-runtime) and rewrites the proxy variables to carry it as proxy credentials, so the gateway and egress proxy attribute that workspace's traffic to its runtime. Its telemetry, error reporting, and auto-updater are disabled in the image because the egress proxy would refuse those hosts anyway.

docker build --tag agentgate-workspace:local --file examples/workspace.Dockerfile .
docker build --tag agentgate-workspace-claude:local --file examples/workspace-claude-code.Dockerfile .
echo "AGENTGATE_WORKSPACE_IMAGE=agentgate-workspace-claude:local" >> .env
docker compose -f compose.yaml -f compose.workspace-image.yaml up -d

compose.workspace-image.yaml swaps the workspace's build: for that image: and changes nothing else about the service, so a profile cannot widen the workspace's privileges by being selected. The same override runs a signed ghcr.io digest in production. CI builds every profile on each push, and each profile's Dockerfile ends by running its tool as node, so a broken postinstall or version pin fails the build rather than the developer's first session. Add further tools the same way and rerun agentgate-egress-check on the result.