D-204 Use

Agents

Boundlane runs command-line agents. You keep the agent you use today. It runs inside the sandbox instead of directly on your machine. This is not a setting inside Claude Code, and it is not a setting inside Codex.

API keysImages built on your machine

Which agents

You keep the agent you use today. It runs inside the sandbox instead of directly on your machine. An agent is listed here when the catalog knows its command, its key, and its image.

Agent	Run it	Key from your environment	Status
Claude Code	`boundlane run -- claude`	`ANTHROPIC_API_KEY`	In the catalog
Codex	`boundlane run -- codex`	`OPENAI_API_KEY`	In the catalog
OpenCode	`boundlane run -- opencode`	`ANTHROPIC_API_KEY`	In the catalog
Grok	`boundlane run -- grok`	`XAI_API_KEY`	In the catalog
Cursor CLI	`boundlane agents`	The key the catalog names	Next
Grok	`boundlane agents`	The key the catalog names	Next
Muse	`boundlane agents`	The key the catalog names	Next

Each agent runs from an image built on your machine; see Agent images. Run boundlane agents to see the list your CLI version ships with. On Windows, run it through WSL 2. The steps for a missing runtime are in Troubleshooting.

Cursor CLI is still next. The current CLI exchanges an API key for tokens it stores, and a stored token sits inside the sandbox. That is the login case this catalog does not ship. The desktop app is a separate program, and Boundlane does not sandbox it.

What supported means

An agent is supported when all four of these pass on macOS and Linux, through Boundlane, with the agent version pinned in its image:

It works. The agent's terminal interface is usable inside the sandbox, and calls to its model succeed.
The key stays hidden. The agent's environment holds a placeholder. The real key never appears inside the sandbox.
Denies work. A write outside the policy fails. A call to an unlisted host is blocked. A raw network socket is blocked.
Approvals work. A blocked call files a request, and after approval the retry goes through without a restart.

CI rebuilds each image and runs the checks again every week, because agent updates can move files the policy names.

Agent images

Each agent runs from its own image, with the agent, git, and common tools. The first boundlane run builds it on your machine from a Dockerfile we publish. We do not redistribute agent binaries.

boundlane agents build claude

Rebuild after you change the pinned version. If an agent's executable changes while a sandbox runs, the sandbox blocks its network calls, because it checks that each program is the one it first saw. Start a new sandbox after an update.

Keys and logins

Use an API key. boundlane key set <agent> stores the key in the gateway on your machine, or the first boundlane run stores it from your environment. The agent sees a placeholder. boundlane key list shows which agents have one.

Subscription logins, such as signing in to Claude with an account instead of a key, are not supported. A login flow writes a token inside the agent's environment, and that token would sit inside the sandbox. Use a key.

What the catalog holds

Each agent has an entry with what the sandbox needs to know about it. Custom entries are not supported. The format is shown so you know what a policy depends on.

agents/claude/agent.yaml

name: claude
command: claude
image: boundlane/claude
version: "2.1.288"
binaries:                    # the real path, not the claude link on PATH
  - /usr/local/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe
model:                       # the only host the key is added for
  - host: api.anthropic.com
    port: 443
hosts:                       # needed to start, read-only, never sent the key
  - host: platform.claude.com
    port: 443
guide_flag: --append-system-prompt   # how the request guide is passed
default_flags:               # unless you pass the same flag
  --permission-mode: manual
start_note: "Claude may ask whether to use the API key it found. Choose Yes: ..."
key:
  env: ANTHROPIC_API_KEY
  profile_file: profile.yaml

The sandbox matches programs by their real path, so the entry names the file the claude command points to. Programs the agent starts, such as git or npm, get the agent's rules.

The profile tells OpenShell which hosts the key may be sent to. Ours starts from the upstream Claude Code profile with two changes: it names the real path, and it leaves out the error reporting and analytics hosts that profile also opens. If you want those, add them to boundlane.yaml. Claude Code also checks platform.claude.com on its first start and quits if it cannot reach it, so the entry allows that host read-only, without the key. The entry also turns off Claude Code's optional traffic: update checks, telemetry, and release notes.

default_flags start Claude Code in its manual permission mode, so Claude asks you before each command and the policy decides what the command can reach. In auto mode, Claude's own check can refuse a command before the sandbox sees it. Pass your own --permission-mode after -- to change it. start_note is printed before Claude starts: on its first start in a sandbox, Claude asks whether to use the API key it found, with No marked as recommended. Choose Yes. The value is the sandbox's placeholder, not your key, and with No Claude has no key.

guide_flag is the agent's option for adding to its instructions. Boundlane passes a short guide through it, on the command line, each time it starts the agent. The guide says how to request access through the sandbox's policy API. boundlane run prints a guide line when it does this. Claude Code, Codex, OpenCode, and Grok receive it today. Claude Code, Codex, and Grok get it on the command line, so it is not written into the sandbox. OpenCode takes instructions as a file, so Boundlane writes one inside the sandbox, outside the project copy. The image and your project are not changed. An agent without a guide still runs. The sandbox drafts a request from a blocked call, and the agent does not file one with a reason.

Codex

boundlane run codex starts Codex inside the sandbox on your machine. It is not Codex's own sandbox setting. Codex uses an OpenAI API key from OPENAI_API_KEY. Signing in with ChatGPT is not supported, for the reason under Keys and logins.

The codex command from npm is a small launcher. It starts a native program built for your machine's processor, and that program makes the calls. So the entry names that program's path, one for Arm and one for x86. The profile starts from the upstream OpenAI profile: the key goes to api.openai.com as a bearer header, and nowhere else. Upstream also has a Codex profile. It is for ChatGPT sign-in and opens three more hosts, so we do not use it.

Boundlane passes these settings to Codex on the command line each time it starts it. Each one is described in Codex's configuration reference, which we checked on 6 October 2026 for Codex 0.160.1.

Setting	Why
A model provider with `env_key = "OPENAI_API_KEY"`	Codex's built-in provider ignores the variable unless `codex login` stored the key. This one sends it as the header the sandbox fills in.
`sandbox_mode = "danger-full-access"`	Codex's own sandbox has to create Linux namespaces, and it cannot do that inside this sandbox, so every command it ran would fail. The sandbox's file, process, and network rules still apply to every command Codex runs. Codex's warning for this mode is hidden, because it says Codex can change your whole computer, which is not the case here.
`web_search = "cached"`	Codex's usual default. The mode above would otherwise switch it to live search.
`developer_instructions`	The request guide. Codex has no flag for it, so it goes in as this setting.
Update check, analytics, feedback, plugins, and connectors off	Optional traffic. Before we turned these off, every start fetched Codex's plugin catalog from GitHub and called `chatgpt.com`.
`--no-daemon`	A sandbox runs one session, so Codex's shared background server has nothing to share. Without it, Codex shows a warning on every start.

Everything after -- goes to Codex. To run it without the interactive screen, use boundlane run codex -- exec --skip-git-repo-check "your task". Codex needs the flag because the project is copied in without its .git folder.

One call is still made. Each time the interactive screen opens, it asks raw.githubusercontent.com for an announcement, and we found no setting that stops it. The sandbox refuses it, the log shows it as denied, and boundlane requests lists a request for it. Deny it or leave it. Codex works without it, and codex exec does not make the call.

On 6 October 2026 Codex ran with a real OpenAI key on an Apple Silicon Mac. Its model calls reached only api.openai.com. When the agent's curl was refused by a host the policy does not list, Codex filed its own request through the guide, for HEAD / on that host only, with curl as the program. After it was approved, the policy reloaded within two seconds and the retry went through. In an earlier session on an older model at low reasoning, Codex did not file a request and moved on after each refusal. The sandbox's own drafts were still listed. Whether the agent asks depends on the model it runs.

OpenCode

boundlane run opencode starts OpenCode inside the sandbox on your machine. This catalog entry uses an Anthropic API key from ANTHROPIC_API_KEY, the same variable Claude Code uses. The two keys are stored separately. The key goes only to api.anthropic.com. A project file that selects another provider is overridden, because Boundlane's config is applied last.

The opencode command from npm is a native program. Its install copies the build for this machine onto bin/opencode.exe, and that is the path the sandbox matches, on Arm and on x86. OpenShell 0.1.2 ships no OpenCode profile. Ours is a reviewed copy of the upstream Anthropic profile: the key goes to api.anthropic.com in the x-api-key header. Its id is boundlane-opencode, separate from an organization's own Anthropic profile and from Claude Code's.

With the key set and no --model, OpenCode 1.18.34 calls Claude Sonnet 4.6. We checked that on 6 October 2026, in the OpenCode source at tag v1.18.34 and in a sandbox run. These are the switches and config keys from that source. Boundlane sets them each time it starts OpenCode.

Setting	Why
`OPENCODE_DISABLE_AUTOUPDATE`	Turns off the update check. The source describes `autoupdate: false` the same way, and Boundlane sets that too.
`OPENCODE_DISABLE_MODELS_FETCH`	Skips the refresh of the model list from `models.opencode.ai`.
`OPENCODE_DISABLE_LSP_DOWNLOAD`	Skips language-server downloads.
`OPENCODE_DISABLE_DEFAULT_PLUGINS`	Turns off the default plugins.
`enabled_providers` set to Anthropic only, and `share` set to `disabled`	The source says a set provider list enables only those providers, and `disabled` turns sharing off.
An instructions file at `/sandbox/.boundlane/guide.md`	The request guide. OpenCode reads instructions from files, so Boundlane writes this one inside the sandbox before the agent starts. It sits outside the project copy, so it is not in the diff.

OpenCode also tries to install @opencode-ai/plugin into its config folder on startup. That request to registry.npmjs.org was refused: the path contains an encoded slash, and allowing those makes the policy check fail. The image carries a lockfile that makes OpenCode skip the install. If you built boundlane/opencode:1.18.34 before this release, run boundlane agents build opencode once so the image has that file.

Everything after -- goes to OpenCode. To run it without the interactive screen, use boundlane run opencode -- run "your task".

Grok

boundlane run grok starts Grok inside the sandbox on your machine. It uses an xAI API key from XAI_API_KEY. Signing in with grok login is not supported, for the reason under Keys and logins.

The grok command from npm is a link to a native program, bin/grok-native, and that is the path the sandbox matches. OpenShell 0.1.2 ships no Grok profile. Ours uses the same credential shape as the upstream OpenAI profile: the key goes to api.x.ai as a bearer header. The docs at docs.x.ai, checked on 6 October 2026, name that host for API-key auth (GROK_XAI_API_BASE_URL, default https://api.x.ai/v1). The browser-login path uses a different host, and this entry does not open it. The profile id is boundlane-grok.

Boundlane sets these from that settings reference, for Grok 1.0.46.

Setting	Why
`GROK_DISABLE_AUTOUPDATER=1`	Turns off the update check. An update would call `x.ai`.
`GROK_SANDBOX=off`	Grok's own sandbox is off by default. The setting keeps it off. This sandbox's file, process, and network rules still apply.
Web fetch, memory, subagents, and crash reports off	Each already defaults off. The entry sets the variables so they stay off.
`--rules`	The request guide. The reference describes this flag as extra rules appended to the system prompt.

Everything after -- goes to Grok. To run it without the interactive screen, use boundlane run grok -- -p "your task" --output-format plain.

Web search is a known channel

Claude Code's web search does not leave the sandbox. Anthropic runs the search on its side, and the query and results travel inside the normal calls to the model's API. The sandbox allows those calls, so it cannot tell a search from any other prompt, and it cannot block one without blocking the model.

What the sandbox does block is the next step: fetching a result page from inside the sandbox is a connection to a host the policy does not list, and it is refused like any other. In our tests, searches worked and every direct fetch of a result was denied.

So the words of a search query can leave through Anthropic. If that matters for a project, turn the search tool off in Claude Code's own settings, or in your Anthropic organization's settings. Boundlane leaves it on and does not enforce either setting.

Codex's configuration reference describes its default search the same way: results come from an index OpenAI keeps, without Codex reaching the web. In one session on 6 October 2026 the log showed two POST api.openai.com/v1/alpha/search calls and no other search host. We have not confirmed that those were web searches. To remove the tool, pass -c web_search="disabled" after --.

Desktop editors

Boundlane does not sandbox desktop editors, including the Cursor app and VS Code. The Cursor CLI is a separate command-line agent, and that is what the table above means. Connecting an editor to a sandbox remotely is possible upstream. We have not tested it, so we make no claim about it.