# What Each Coding Agent Can Reach on Your Machine

> Source: <https://www.digitalapplied.com/blog/agent-runtime-sandbox-matrix>
> Published: 2026-08-30 00:00:00+00:00

A coding agent sandbox answers one question: what can this harness reach at all. Not what it does without asking — what is inside the boundary in the first place. This page is the census, across sixteen surfaces from eleven harnesses, read on August 30, 2026 against four dimensions: filesystem scope, network egress, process spawning and credential visibility, each recorded for a fresh install and again for what a documented flag changes.

The distinction is load-bearing, and it is the reason this table exists next to another one. Whether the agent stops and asks you before it writes a file is a consent question, and we censused it separately in [what coding agents do without asking](/blog/coding-agent-permission-defaults-census). This page never asks that question. It asks whether the file was reachable by the process at all — which is a different property, enforced in a different place, and frequently answered differently by the same vendor.

Two of the four dimensions here are, as far as we can find, not published anywhere across products: where an agent is allowed to connect, and which of your credentials it can see while it works. Those get the most space below. The single sharpest finding is in the credential column: four of the eleven harnesses ship a documented credential-scoping primitive, and only one of the four does anything at all on a fresh install.

- 01This is a capability map, not a consent map — 16 surfaces, 11 harnesses, 4 dimensions.Every cell answers what the harness can reach, by default and by documented flag: filesystem scope, network egress, process spawning, credential visibility. Five harnesses contribute more than one row because the boundary genuinely differs between their local and cloud surfaces, or between two enforcement paths inside one product. Nothing here reports whether the agent prompts you first.
- 02Four of eleven harnesses ship a credential-scoping primitive. One of the four does anything by default.Claude Code has sandbox.credentials with both deny and mask modes, and it is opt-in. Codex has shell_environment_policy, but its ignore_default_excludes key defaults to true, which keeps variables containing KEY, SECRET or TOKEN. Gemini CLI's environment-variable redaction defaults to false. Copilot CLI's --secret-env-vars is opt-in, though GITHUB_TOKEN and COPILOT_GITHUB_TOKEN are redacted from output by default — the only credential behaviour in the set that is on out of the box, and it covers two named variables.
- 03Egress default is the cleanest split in the matrix: four deny, five allow, one on-with-an-allowlist.Denied on a fresh install: Codex CLI in workspace-write, the Codex cloud agent phase, the Cursor sandbox, and the Claude Code sandbox, which pre-allows zero domains. Allowed: Gemini CLI's default Seatbelt profile, the Copilot CLI local sandbox, the Jules VM, and Devin CLI without --sandbox. The GitHub Copilot cloud agent sits in between with the firewall on by default plus a recommended allowlist. Six surfaces document no egress posture at all.
- 04On three of the biggest harnesses, the sandbox is not one boundary.Claude Code sandboxes Bash subprocesses while Read, Edit and Write go through the permission system instead of the operating system. GitHub says the same thing out loud: its own file tools are a software-only safeguard because the OS sandbox never sees those operations. Devin inverts it — shell is bounded by the OS, while edit and write tools still prompt because they operate outside the sandbox. A reader who concludes the agent is sandboxed has half an answer on all three.
- 05Reduced-capability modes are rare, and the gaps are labelled rather than filled.Four harnesses ship a named mode that removes capability. Three can have one assembled by an operator. Six had none located in the pages read. Separately, Amp, Aider and Cline publish no filesystem or egress boundary at all, and those cells carry an UNVERIFIED label with its reason code instead of a value borrowed from a third-party hardening guide.

## 01 — The boundary questionCapability is not *consent*.

Two questions get collapsed into one whenever anyone writes about agent security. The first is behavioural: does the agent stop and ask before it does something. The second is structural: is the thing it wants to do reachable by the process at all. This page answers only the second one. Where a sentence would have belonged in the consent census, it is not here — it is in [the permission-defaults census](/blog/coding-agent-permission-defaults-census), which is the companion asset to this one and covers a partly different harness set.

Whether a harness ought to ask first or act first is a posture argument, and it is argued in [should your AI agent ask first or act first](/blog/default-deny-vs-default-allow-agent-permissions); this page only maps what each default posture can actually reach.

The reason the structural question needs its own table is that on most of these harnesses the boundary is not one boundary. It is two, enforced by two different mechanisms, and the vendors that document this best are the ones where the split is widest. Claude Code states it plainly: the sandbox isolates Bash subprocesses, while the built-in Read, Edit and Write tools use the permission system directly rather than running through the sandbox. GitHub is unusually candid about the same architecture in its own words, and Cognition inverts it — on the Devin CLI, shell commands auto-approve in autonomous mode precisely because the OS bounds them, while the edit and write tools keep prompting because they operate outside the sandbox.

GitHub, on its own local sandboxing page: *“Built-in file-reading and file-editing tools run as part of Copilot CLI itself rather than as a sandboxed child process. They check the same filesystem policy before reading or writing a file, but because the operating-system sandbox never sees these operations, the check is a software-only safeguard rather than one the operating system enforces.”*

That is a vendor describing the limit of its own boundary in the documentation for the boundary. Three of the largest harnesses in this matrix have a version of that sentence. It is the reason a single yes-or-no “is it sandboxed” cell would be misleading, and the reason each dimension here is split into a default and a flag column rather than collapsed into a verdict.

One pattern in the data is worth naming before the table, because it is the closest thing to an industry consensus in here and no vendor announced it. Three companies independently decided that a repository must not be able to widen the boundary. Anthropic honours credential masking, TLS termination and strict-allowlist keys only from user, managed or explicit `--settings`

scopes, never from a checked-in `.claude/settings.json`

. Cursor states that enterprise team-admin policies and its own hardcoded rules layer on top and cannot be weakened by either configuration file. Cognition makes the Devin `sandbox`

block user-config only, so a project cannot set it. Three implementations, one rule, arrived at separately.

## 02 — MethodWhat was read, and what the labels *mean*.

The evidence tier matters more here than the row count, so it is stated first and on the face of the page: every cell in this matrix is documentation-read only. **Nothing in this dataset was observed on a machine.** Where a vendor documents a default, that default is recorded as the vendor states it. Where the documentation is silent, the cell says so with a reason code rather than being filled from a third-party hardening guide or inferred from a sibling product.

**What was collected.** For each harness surface, four capability dimensions: *filesystem scope* (what paths the process can read and write), *network egress* (where it can connect), *process spawning* (what enforces the boundary on child processes, and what escapes it by design), and *credential visibility* (which secrets are in scope for a command the agent runs). Each is recorded twice: **D** for a fresh install with no configuration, **F** for what a documented flag or config key changes.

**Harness surfaces (16 rows, 11 harnesses).** Claude Code (two enforcement paths), OpenAI Codex (CLI and cloud), Cursor, GitHub Copilot (CLI local sandbox and cloud agent), Gemini CLI, Devin (CLI and cloud session VM), Google Jules, Amp (CLI and orbs), Aider, Cline, OpenHands. Five harnesses contribute more than one row because the boundary genuinely differs between those surfaces.

**Sources.** Vendor-first and vendor-only: official documentation, CLI and config references, changelogs and release pages. No third-party hardening guide, blog post or forum thread contributed a cell. Where a vendor publishes a first-party repository copy of its docs, that copy was used.

**Dates.** All pages were fetched on **August 30, 2026**, and the data **as-of date is August 30, 2026**. Nothing dated after that appears. Version strings are printed per row where a vendor publishes one; where a product publishes no current version that could be pinned from its documentation, the row says “docs as current at 2026-08-30” instead of naming a version.

**The three UNVERIFIED labels.** An unverifiable cell stays in the table, because a labelled gap is information and an empty one is not. The reason code is never merged: **(a)** the vendor does not document it — the relevant pages were read and contain no such mechanism; **(b)** the page was not located — a page that would plausibly carry the answer could not be found or did not resolve; **(c)** the page was located but was not machine-readable for the fact needed. The three carry three separate visual styles in the matrix for exactly this reason: a filled accent chip, a dashed outline, and an inverted solid chip.

**Absence discipline.** No row asserts that a harness lacks a capability. The sayable claim is narrower and it is the one used throughout: the mechanism was not located in the vendor pages read on August 30, 2026. For Aider, for example, the claim is that the published option reference contains no sandbox, network or credential-scoping flag, and that the vendor’s only isolation guidance is its Docker install page — not that Aider has no sandbox.

**Known limitations.** Three of them. This is a weaker evidence tier than a census where behaviour was executed and observed, and the two should not be read as equivalent even when the tables look alike. Two harnesses in the set are pre-release on the surface described — the Copilot CLI local sandbox is public preview, and its own `--sandbox`

and `--no-sandbox`

flags are documented as available only in experimental mode. And the Claude Code sandbox surface has moved through roughly eleven feature-bearing releases in this cycle alone, so a version string here dates faster than anything else on the page.

## 03 — The MatrixSixteen surfaces, four *dimensions*.

Read it column-pair by column-pair. The **D** column of each pair is what a fresh install can reach; the **F** column is the documented lever and its config key. The rows are grouped by where the boundary lives: local surfaces with an operating-system-enforced boundary, cloud and remote surfaces where the boundary is the machine itself, and harnesses whose published control surface is an approval layer with no isolation layer located.

Three groups, and the third one is not a failure of research. Amp, Aider and Cline publish rich approval models and no isolation model. Recording that plainly, with the pages named, is the part of a census that makes the other two groups worth trusting.

| # | Harness (surface) | Version · checked | Filesystem — D | Filesystem — F | Egress — D | Egress — F | Process spawning — D | Process spawning — F | Credentials — D | Credentials — F |
|---|---|---|---|---|---|---|---|---|---|---|
| Group A — local surfaces with an OS-enforced boundary (7 rows) | ||||||||||
| 1 | Claude Code — CLI, sandbox on | v2.1.251 latest tag observed · 2026-08-30Unverified (c)per-version changelog dates: the changelog extraction stripped version headings, so entries could not be dated from it | Sandboxed Bash: write = cwd plus `--add-dir` paths plus the session temp dir. Read = the entire computer except denied directories — the vendor notes this default “still allows reading credential files such as `~/.aws/credentials` and `~/.ssh/` ” | `sandbox.filesystem` allowWrite / denyWrite / allowRead / denyRead; `filesystem.disabled` turns the filesystem layer off and keeps the network layer (user, managed or `--settings` only). Protected paths cannot be exempted at all | Deny — zero domains pre-allowed. A first new domain prompts, or goes to the classifier in auto mode | `allowedDomains` , `deniedDomains` , `WebFetch(domain:…)` allow rules; `strictAllowlist` denies instead of prompting; `allowManagedDomainsOnly` locks to managed entries; `httpProxyPort` / `socksProxyPort` ; experimental `network.tlsTerminate` | Bash and all child processes run inside Seatbelt on macOS, bubblewrap on Linux and WSL2. Native Windows: not supported — no sandbox | `excludedCommands` runs a command outside; `dangerouslyDisableSandbox` retry, removable via `allowUnsandboxedCommands: false` ; `failIfUnavailable: true` refuses to start unsandboxed | Inherited wholesale — “sandboxed Bash commands inherit the parent process environment by default, including any credentials set there.” No built-in credential deny list | `sandbox.credentials.files` / `.envVars` with `mode: “deny”` or `“mask”` . Mask = per-session sentinel plus proxy substitution on `injectHosts` , with `extract` regex, `decode: “jwt”` + `maskClaims` , and `awsPairs` SigV4 re-signing. Plus `CLAUDE_CODE_SUBPROCESS_ENV_SCRUB` |
| 2 | Claude Code — CLI, file-tools path | same build · 2026-08-30 | Read, Edit and Write are not sandboxed. They go through the permission system rather than the operating system | `Read` / `Edit` allow and deny rules; `permissions.additionalDirectories` | Not an OS-level question on this path; `WebFetch` follows its permission rules | `WebFetch(domain:…)` rules | Bash runs unsandboxed under permission rules | `--dangerously-skip-permissions` — blocked as root on Linux and macOS unless already inside a recognised sandbox | Full user environment | As row 1 |
| 3 | OpenAI Codex — CLI and IDE extension | 0.151.0 stable (2026-08-29); 0.152.0 in alpha · 2026-08-30Unverified (c)the vendor’s own changelog endpoint returned 9 bytes; release tags used instead | `workspace-write` = cwd plus temp dirs. Inside writable roots, `.git` , `.agents` and `.codex` are recursively read-only. A version-controlled folder gets Auto; a non-version-controlled one is recommended `read-only` | `sandbox_workspace_write.writable_roots` , `exclude_tmpdir_env_var` , `exclude_slash_tmp` . The newer permission profiles add a `read` / `write` / `deny` path grammar with `:root` , `:minimal` and `:workspace_roots` anchors | Deny — “by default, the agent runs with network access turned off” | `network_access = true` turns it on unrestricted; `features.network_proxy` then constrains it to `domains` rules (allowlist-first, deny wins, `**.` covers apex plus subdomains); `allow_local_binding = false` blocks loopback and RFC1918. Adding domain rules does not enable the proxy by itself | Sandbox applies to spawned commands and their children. macOS Seatbelt runs via `sandbox-exec -p` , Linux via `bwrap` plus seccomp, and there is a native Windows sandbox (`windows.sandbox` unelevated or elevated); WSL2 uses the Linux path | `--sandbox danger-full-access` ; `--dangerously-bypass-approvals-and-sandbox` (alias `--yolo` ); `rules` allow / prompt / forbid command prefixes outside the sandbox; `allow_login_shell = false` | Inherited, and secret-named variables are kept by default: `shell_environment_policy.ignore_default_excludes` defaults to `true` — “keep variables containing KEY, SECRET, or TOKEN before other filters run” | `shell_environment_policy.inherit` = all / core / none; `.filters` include and exclude patterns; `.set` ; setting `ignore_default_excludes = false` applies the automatic secret-name exclusions. Also `deny` globs for `.env` in a profile’s filesystem block |
| 4 | Cursor — agent, sandbox on | sandbox requires v2.0+; docs as current at 2026-08-30 (Run Modes changelog last entry 3.6, 2026-05-29) | `type: “workspace_readwrite”` — read and write inside the workspace, plus `/tmp` and the platform temp dir. Always write-protected regardless of config: `.cursor/*.json` , `.claude/*.json` , `.vscode/**` , `.code-workspace` , `.git/hooks/**` , `.git/config` , `.git/info/attributes` , `.cursorignore` | `additionalReadwritePaths` , `additionalReadonlyPaths` , `disableTmpWrite` , `enableSharedBuildCache` ; `type: “workspace_readonly”` ; `type: “insecure_none”` disables the sandbox | Deny — `networkPolicy.default = “deny”` . RFC1918, `127.x` , `169.254.169.254` and IPv6 private ranges are blocked by default | `networkPolicy.allow` / `.deny` with exact hosts, wildcards and CIDRs, deny always winning; three network modes — sandbox.json only, sandbox.json plus defaults (the default), and allow all | Seatbelt via `sandbox-exec` on macOS; the Linux backend reports in `CURSOR_SANDBOX_LANDLOCK_STATUS` as fully_enforced (Landlock) or bubblewrap. The profile covers “the full subprocess tree”; commands needing full system access bypass the sandbox and ask for approval | Run Modes: auto-review (default), allowlist, run everything. CLI permission tokens `Shell()` , `Read()` , `Write()` , `WebFetch()` , `Mcp()` in `cli-config.json` ; deny beats allow | `~/.ssh` and SSL certificate paths are always readable inside the sandbox (vendor’s own statement). Cursor injects `CURSOR_SANDBOX` , `CURSOR_ORIG_UID` , `CURSOR_ORIG_GID` | Unverified (a)No env-var scrubbing or credential-masking key exists in `sandbox.json` for an OS-enforced control. `Read(.env*)` deny tokens exist for the CLI’s own file tool — a tool-level rule, not an OS boundary |
| 5 | GitHub Copilot CLI — local sandbox | public preview · 2026-08-30. Note `--sandbox` / `--no-sandbox` are documented as “only available in experimental mode” | Deny-by-default — “unless a path is explicitly granted, a command cannot use it” — then automatic grants: cwd read/write, toolchain dirs from `PATH` , `GOPATH` , `CARGO_HOME` , `PYTHONPATH` read-only, system and home profile read-only, package caches (registries read-only, build caches read/write). In a git repo: read across the whole repository, write limited to cwd and `.git` | `/sandbox config` filesystem tab: extra read/write paths, read-only paths, deny paths. More specific path wins and operator rules always beat automatic grants. Enterprise managed settings compose in the most restrictive direction and can lock “include working directory” off | Allow — “allow outbound connections — turned on by default”; “allow local network — turned on by default” | Turn either off in the `/sandbox` network tab; HTTP proxy with URL and credentials | `/sandbox enable` persists across sessions; `--sandbox` for one session; `--no-sandbox` cannot override enterprise managed settings. Sandboxed child processes are OS-enforced; the built-in file tools are a software-only check | `--allow-tool` / `--deny-tool` (deny takes precedence over `--allow-all-tools` ), `--allow-all-paths` , `--allow-all-urls` , `--allow-all` / `--yolo` . “Allow sandbox bypass” is on by default, subject to approval | “Allow dev tool access” is on by default and “grants sandboxed commands read access to developer-tool configuration and caches — including package-manager registries and the tokens they store”. Partial offset: `GITHUB_TOKEN` and `COPILOT_GITHUB_TOKEN` values are redacted from output by default | `--secret-env-vars=VAR …` — “redact an environment variable from shell and MCP server environments (can be used multiple times)”. Also: turn dev-tool access off, or deny a `.env` path so no sandboxed command can read it |
| 6 | Gemini CLI | first-party repo docs on main · 2026-08-30 | Sandbox is opt-in — unsandboxed by default. When on, the default Seatbelt profile `permissive-open` “confines writes to the project directory while allowing broad file reads”. Container modes bind-mount cwd at the same absolute path | `-s` / `--sandbox` , `GEMINI_SANDBOX` , `tools.sandbox` ; `SEATBELT_PROFILE` across permissive, restrictive and strict × open and proxied; `SANDBOX_MOUNTS` (`from:to:opts` , default `ro` ); `security.folderTrust.enabled` defaults to `true` | Allow — the default `permissive-open` profile allows network access, and the unsandboxed default has no restriction at all | The `*-proxied` Seatbelt profiles route network through a proxy; container, gVisor and LXC backends; `SANDBOX_FLAGS` for raw docker or podman flags | Selectable backends: Docker and Podman, gVisor `runsc` (must be named explicitly, not auto-detected), LXC/LXD (experimental, container must pre-exist). “Sandbox expansion” prompts to widen permissions for one run | `security.toolSandboxing` — per-tool isolation instead of whole-process — defaults to `false` ; `security.disableYoloMode` defaults to `false` | Environment inherited. `advanced.excludedEnvVars` defaults to `[“DEBUG”, “DEBUG_MODE”]` and is about project `.env` interference, not secrets | `security.environmentVariableRedaction.enabled` defaults to `false` ; set it true and supply `.allowed` / `.blocked` arrays to redact variables that may contain secrets |
| 7 | Devin CLI — local | docs as current at 2026-08-30 | `--sandbox` derives writable paths from granted `Write(...)` scopes plus the workspace; everything else is read-only. Readable = everything except paths in `Read(...)` deny rules, which are “hidden from sandboxed commands entirely” | A `Write(...)` grant made mid-session expands the sandbox for later commands; a `Read(...)` deny stays hidden for the whole session and cannot be reopened mid-session | No filtering unless configured — “without `--sandbox` , the sandbox section is ignored” | `sandbox.allowed_domains` (an allowlist when non-empty), `sandbox.denied_domains` (deny wins), `network_mode` full (default) or limited (GET, HEAD, OPTIONS only) — user config only, not settable per project. Enterprise allowlist replaces the user list; enterprise denylist is additive | OS-level sandbox behind `--sandbox` . Autonomous permission mode is available only when the sandbox is active: shell auto-approves because the OS bounds it, while `edit` and `write` still prompt “because they operate outside the sandbox” | `sandbox.excluded.allow` / `.ask` / `.deny` using `Exec(...)` rules; team deny overrides user allow and ask; enforcement mode optional (default) or required | Unverified (a)Neither the sandbox page nor the permissions page documents environment-variable handling for sandboxed commands | `Read(...)` deny rules hide credential paths from sandboxed commands |
| Group B — cloud and remote surfaces, where the boundary is the machine (6 rows) | ||||||||||
| 8 | Codex cloud — agent phase | docs as current at 2026-08-30 | OpenAI-managed isolated containers; no host access | Environment configuration per environment | Deny — blocked during the agent phase. The setup phase runs with network so dependencies can install | Per environment: off, or on with a domain allowlist (presets None, Common dependencies at roughly 70 published hosts, or All). HTTP methods restrictable to GET, HEAD and OPTIONS | Full shell inside the container | — | Scoped by lifecycle — “secrets configured for cloud environments are available only during setup and are removed before the agent phase starts” | — |
| 9 | GitHub Copilot cloud agent | docs as current at 2026-08-30 | Runs on the GitHub Actions appliance against a repository checkout | Setup steps and dev-environment customization | Firewall on by default, plus a recommended allowlist covering OS package repos, container registries, language registries, CAs and Playwright browser hosts | Org and repo internet-access settings: enable firewall (enabled, disabled, or let repositories decide), recommended allowlist toggle, custom allowlist by domain including subdomains or by URL prefix. Org rules combine with repo rules and cannot be deleted at repo level | Bash tool inside the Actions appliance | — | Unverified (a)The firewall page documents no credential-scoping mechanism. A blocked request does surface as a warning in the pull request body, naming the address and the command that tried to reach it | — |
| 10 | Devin cloud — session VM | docs as current at 2026-08-30 | Linux VM booted from a frozen snapshot; every session boots a fresh copy and session changes do not persist back | Blueprints define repos and tools; workspace blueprints per subdirectory | Unverified (a)The environment docs read document the VM and snapshot model but state no default egress posture for the session VM | Unverified (a)The allowed_domains and network_mode keys are the CLI sandbox, not the cloud VM; the two are not conflated here | Full VM shell | — | Secrets injected as environment variables. Org secrets are “usable by Devin in all future Devin sessions within your organization”; personal secrets are scoped to your sessions; repo secrets are tied to the snapshot. Build-time secrets are removed before the snapshot is saved — but a value written into a config file during initialize persists in the snapshot | Scope choice across org, personal, repo and session; put credential-writing steps in `maintenance` rather than `initialize` |
| 11 | Google Jules — cloud VM | docs as current at 2026-08-30 | Fresh Ubuntu VM per task with a clone of the authorised repo; the VM is short-lived | Setup script plus environment snapshot | Allow — code runs “in a secure, cloud-based virtual machine (VM) with internet access” | Unverified (a)No egress allowlist, proxy or off-switch is documented on the pages located | Full VM; Docker is present in the preinstalled toolchain | — | Repo-level environment variables, opt-in per task, and “this setting cannot be changed after the task has begun” | Unverified (b)The vendor’s secrets and security pages did not resolve to content; a dedicated secret store distinct from repo environment variables could not be located |
| 12 | Amp orbs — remote | docs as current at 2026-08-30 | Per-thread remote machine, a “fresh, isolated environment”; the agent and the orb terminal share one filesystem | `--orb-size` ; project config | Unverified (a)No egress posture is documented on the orbs pages | — | The whole machine to itself: “install dependencies, run your app, spawn browsers” | — | Unverified (a)No credential-scoping mechanism located on the orbs pages | — |
| 13 | OpenHands — V1 | docs as current at 2026-08-30 | The sandbox provider chooses the boundary: Docker (default, `RUNTIME=docker` ) runs the agent server in a container with “good isolation from your host machine”; Process is “unsafe, but fast” with “no container isolation”; Remote | `RUNTIME` = docker (default), process (legacy local), or remote | Unverified (a)Container default networking applies; no agent-level egress allowlist is documented on the pages read | — | The whole agent server runs inside the container | Provider selection | Unverified (a)No secret policy documented on the runtimes or sandboxes overview pages | — |
| Group C — published control surface is an approval layer; no isolation layer located (3 rows) | ||||||||||
| 14 | Amp — CLI, local | docs as current at 2026-08-30 | Unverified (a)No filesystem-boundary documentation located; the published control surface is `amp.permissions` , a per-tool-call approval layer | `amp.permissions` rules: `tool` glob, `matches` on tool args, `action` across allow, reject, ask and delegate, `context` thread or subagent; `amp permissions edit` / `add` / `test` / `list` | Unverified (a)No egress control documented across the manual, orbs, permissions and legacy-rules pages read | Standard `HTTP_PROXY` / `HTTPS_PROXY` environment variables — a transport setting, not an agent boundary | The Bash tool is gated by `amp.permissions` ; `delegate --to` hands the decision to a helper program answering by exit code | `amp.tools.disable` list | Unverified (a)No credential-scoping mechanism located on the pages read | — |
| 15 | Aider | published option list checked 2026-08-30 | No flag in the published option list creates a filesystem boundary. `--subtree-only` and `.aiderignore` scope what the agent considers, not what the process can touch | The vendor’s only isolation guidance is its Docker install page: run the published image with `--user $(id -u):$(id -g)` and `--volume $(pwd):/app` | Unverified (a)No egress control appears in the published option reference | — | `/run` and `/test` execute shell commands; `--suggest-shell-commands` controls only whether the model proposes them | A Docker container as the boundary, per the install page | `--env-file` and `--set-env` load variables in; no flag scopes or redacts them | Unverified (a)No credential-scoping flag exists in the published option reference |
| 16 | Cline | docs as current at 2026-08-30 | No OS sandbox documented. Scope is an approval category: “read project files” or “read all files” outside the workspace, and the same pair for edits | Auto Approve toggles, per category | Unverified (a)No egress control documented; “use the browser” is an approval category, not a boundary | — | “Execute safe commands” versus “execute all commands”, where the split is a model judgment: “Cline does not use a fixed allowlist. The model marks each command with a `requires_approval` flag” | YOLO mode auto-approves everything | Unverified (a)No credential-scoping mechanism located on the pages read | — |

Anthropic [Claude Code sandboxing](https://docs.claude.com/en/docs/claude-code/sandboxing) and [CLI reference](https://code.claude.com/docs/en/cli-reference) · OpenAI [Codex approvals and security](https://developers.openai.com/codex/agent-approvals-security), [permissions](https://developers.openai.com/codex/permissions) and [cloud internet access](https://developers.openai.com/codex/cloud/internet-access) · Cursor [sandbox.json reference](https://cursor.com/docs/reference/sandbox) and [run modes](https://cursor.com/docs/agent/security/run-modes) · GitHub [local sandboxing](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing), [CLI command reference](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference) and [agent firewall](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/customize-the-agent-firewall) · Google [Gemini CLI sandbox docs](https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/sandbox.md) and [Jules FAQ](https://jules.google/docs/faq/) · Cognition [Devin CLI sandbox](https://docs.devin.ai/cli/sandbox) and [secrets](https://docs.devin.ai/product-guides/secrets) · Sourcegraph [Amp permissions](https://ampcode.com/permissions) · All Hands [OpenHands sandbox providers](https://docs.all-hands.dev/usage/runtimes/overview) · [Cline auto-approve](https://docs.cline.bot/features/auto-approve) · [Aider options reference](https://aider.chat/docs/config/options.html)

Twenty cells across the sixteen rows carry an UNVERIFIED label: seventeen of type (a), one of type (b), and two of type (c) attached to version provenance rather than to a capability. Those cells are the reason the rest of the table is usable. A census that fills every box is a census that guessed somewhere, and the reader has no way to tell where.

## 04 — Dimension oneFilesystem scope, and the paths that are protected *anyway*.

Write scope is the dimension vendors document best, and read scope is the one they document least prominently. Claude Code writes to the working directory plus `--add-dir`

paths plus a session temp dir — and reads the entire computer except a denied set. Codex writes to the workspace plus temp dirs under `workspace-write`

, widened by `writable_roots`

. Cursor writes inside the workspace under `workspace_readwrite`

. Copilot CLI is the strictest default of the four on paper — deny-by-default, then a documented grant list — and it is also the one that publishes the consequence: in a git repository, a sandboxed command can read across the whole repository, including anything sensitive stored elsewhere in the project.

The more interesting structure is what stays protected inside a region the agent can otherwise write to. Codex marks `.git`

, `.agents`

and `.codex`

recursively read-only inside writable roots. Cursor hard-protects `.cursor/*.json`

, `.claude/*.json`

, `.vscode/**`

, `.git/hooks/**`

, `.git/config`

and `.cursorignore`

regardless of configuration. Claude Code protects four groups — its own settings, skills, agents, commands and hooks; shell startup files, `.gitconfig`

, editor directories and `.git/hooks`

; the files that would turn the working directory into a bare repository; and most of the user-level Claude directory including its credentials file — and states there is no way to exempt one of these paths.

Two cells in this matrix involve a git worktree, and both are facts about a protected path rather than an argument for a workflow. When the working directory is a linked worktree, the Claude Code sandbox also allows writes to the main repository’s shared `.git`

so that `git commit`

works, while `hooks/`

and `config`

stay denied. Codex, from the other direction, protects `.git`

recursively inside a writable root regardless of whether it is a worktree pointer file or a directory. Why teams run worktrees in the first place is a separate subject, covered in [worktree isolation for agent CLIs](/blog/agent-cli-worktree-isolation-parallel-coding-agents).

Where a harness offers a container as the boundary, this table records the backend and the key that selects it, and stops there. Gemini CLI ships Docker and Podman, gVisor `runsc`

— which must be named explicitly and is not auto-detected — and an experimental LXC/LXD path where the container must already exist, selected through `GEMINI_SANDBOX`

. OpenHands ships Docker as the default provider, Process which its own docs call “unsafe, but fast”, and Remote, selected through `RUNTIME`

. Why one isolation technology is stronger than another, and how to build an environment around it, is the subject of [our three isolation patterns guide](/blog/ai-agent-sandboxing-isolation-patterns-2026) — this page only records which one ships and how it is chosen.

The most elegant filesystem design in the set is Cognition’s, and it is elegant in the opposite direction from Anthropic’s. On the Devin CLI, writable paths are derived from the granted `Write(...)`

permission scopes plus the workspace, so permissions and isolation are one object rather than two independent layers. A read deny is stronger still: denied paths are hidden from sandboxed commands for the whole session and cannot be reopened mid-session, while a write grant made mid-session does expand the sandbox for later commands. One mechanism, asymmetric in the direction that favours the boundary.

## 05 — Dimension twoNetwork egress is the cleanest *split* in the matrix.

Egress is the dimension nobody publishes across products, and it is also the one where the harnesses disagree most sharply with each other. Four surfaces deny outbound network access on a fresh install. Five allow it. One turns a firewall on and hands you a recommended allowlist. Four document no posture at all. Those are not shades of the same design — they are four different starting positions on what a fresh install can reach, and a team running two harnesses is running two of them.

| Default posture | Surfaces | Which | What the vendor documents |
|---|---|---|---|
| Denied | 4 | Codex CLI in workspace-write · Codex cloud agent phase · Cursor sandbox · Claude Code sandbox | Codex: “the agent runs with network access turned off”. Cursor: `networkPolicy.default = “deny”` plus a built-in private-range block list. Claude Code: pre-allows zero domains and prompts on the first new one |
| Allowed | 4 | Gemini CLI permissive-open · Copilot CLI local sandbox · Jules VM · Devin CLI without --sandbox | Copilot: “allow outbound connections — turned on by default”. Gemini: the default profile allows network access, and the unsandboxed default has no restriction at all. Jules: a VM “with internet access” |
| On, with an allowlist | 1 | Copilot cloud agent | Firewall enabled by default plus a recommended allowlist covering OS package repos, container registries, language registries, CAs and Playwright browser hosts |
| Not documented | 6 | Amp CLI · Amp orbs · Aider · Cline · OpenHands · Devin cloud VM | Unverified (a) in each case — the pages named in the row were read and contain no egress mechanism |

The Codex egress design deserves a paragraph on its own, because it is a two-key system and the keys do different jobs. `network_access`

decides whether the agent has network at all. `features.network_proxy`

decides how that access is enforced. The vendor publishes the truth table: off plus proxy does nothing; on with no proxy is unrestricted direct outbound access; on plus proxy is constrained to the domain rules. And the sentence that catches people: adding domain rules does not enable the proxy by itself. A config file that looks like an allowlist can be a config file with no allowlist in force.

The domain grammar differs enough between harnesses to matter when you are copying a rule set from one to another. On Codex, an exact host matches only that host, `*.example.com`

covers subdomains but not the apex, and `**.example.com`

covers both. Cursor accepts exact hosts, wildcards and CIDR ranges, with deny always winning, and unions allowlists across its two configuration files — unless a team-admin allowlist is present, in which case that list replaces the union. GitHub’s cloud allowlist is either a domain, which includes its subdomains, or a URL prefix comprising scheme, host and path, and org rules combine with repo rules and cannot be deleted at the repository level.

Two smaller facts round out the dimension. Cursor blocks the private address space by default — RFC1918, `127.x`

, the `169.254.169.254`

cloud metadata endpoint, and IPv6 private ranges — which is an egress default about internal reach rather than external reach, and no other harness in the set publishes an equivalent list. And Codex publishes its entire Common dependencies preset inline, roughly seventy hosts, which makes it the only vendor here whose default allowlist can be audited without running anything.

##### Deny is a minority position

Codex CLI in workspace-write, the Codex cloud agent phase, the Cursor sandbox and the Claude Code sandbox all start with no reachable network. On the other side, four surfaces document an open network, and six publish no posture. A team standardising on two harnesses can easily pick one from each side without noticing.

##### Enabling access and constraining it are separate

On Codex, network_access decides whether and features.network_proxy decides how. Off plus proxy does nothing. On with no proxy is unrestricted. Adding domain rules does not enable the proxy by itself — the vendor says so in its own documentation, which is why the matrix records the pair rather than a single yes or no.

##### One default allowlist you can actually audit

The Codex cloud Common dependencies preset is published inline as a host list. Every other allowlist in this matrix is described by category — OS package repos, language registries, certificate authorities — rather than enumerated, which means it cannot be diffed against your own egress policy without running the agent first.

## 06 — Dimension threeCredential visibility is where the defaults are *weakest*.

This is the dimension an enterprise security reviewer asks about first and the one with the least published material, so it gets the most space. The question is narrow: when the agent runs a command, which of your secrets are in that command’s scope. Not whether the agent is trustworthy, and not whether it asks — whether the value is reachable.

Four of the eleven harnesses ship a documented credential-scoping primitive. One of the four does anything on a fresh install, and what it does covers two named variables. Everything else in the column is inheritance: the sandboxed command gets the environment the parent process had, credentials included, because that is what running a subprocess means unless somebody built a filter.

##### Claude Code

The richest primitive in the set and it is off until configured. Files and environment variables can be set to deny or mask. Mask shows a per-session sentinel while a proxy substitutes the real value on requests to named injectHosts, with an extract regex, JWT decoding with maskClaims, and AWS SigV4 re-signing through awsPairs. It requires TLS termination to work, degrades to a block for files on macOS, and cannot be enabled from a repository's own settings file — only from user, managed or explicit --settings scopes. Separately, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB strips Anthropic and cloud credentials from all subprocesses.

##### OpenAI Codex

The primitive exists and its most relevant key points the other way. ignore_default_excludes defaults to true, documented as keeping variables containing KEY, SECRET or TOKEN before other filters run. Setting it to false is what applies the automatic secret-name exclusions. Beyond that, inherit selects all, core or none, filters take include and exclude patterns, set injects values, and a permission profile's filesystem block can deny-glob .env files so no sandboxed command reads them.

##### Gemini CLI

A redaction mechanism aimed squarely at variables that may contain secrets, with allowed and blocked arrays — and enabled defaults to false. The neighbouring key that does have a non-empty default, advanced.excludedEnvVars, defaults to DEBUG and DEBUG_MODE and is documented as being about project .env interference rather than about secrets, so it should not be read as a credential control.

##### GitHub Copilot CLI

The only default credential behaviour in the matrix: GITHUB_TOKEN and COPILOT_GITHUB_TOKEN values are redacted from output by default. The configurable half redacts a named variable from shell and MCP server environments and can be repeated — the only credential mechanism here that extends to an MCP server's environment. Pulling the other way, allow dev tool access is on by default and grants sandboxed commands read access to package-manager registries and the tokens they store.

Set against those four are two vendors who state in their own documentation that credential paths remain readable inside the sandbox. Anthropic writes that the default read behaviour “still allows reading credential files such as `~/.aws/credentials`

and `~/.ssh/`

”. Cursor writes that “SSL certificate paths and `~/.ssh`

are always readable”. Two vendors, the same admission, and — as the matrix shows — opposite egress defaults on the surface where they make it. GitHub is arguably a third in effect rather than in wording: dev-tool access is on by default and grants read of package-manager registries and the tokens they store.

That pairing is the most useful thing on this page for anyone doing a harness review, because it is the combination that decides how much the credential column matters. If a fresh install can read your SSH keys and also open an outbound connection, the two facts compound. If it can read them and cannot connect anywhere, they do not. The quadrant below is just those two columns of the matrix crossed against each other.

| Credential default ↓ / egress default → | Egress denied | Egress allowed or allowlisted | Egress not documented |
|---|---|---|---|
| Something scoped by default | Codex cloud agent phase — secrets available only during setup and removed before the agent phase starts | Copilot CLI — two named token variables redacted from output | — |
| Inherited, primitive available | Claude Code sandbox · Codex CLI workspace-write | Gemini CLI | — |
| Inherited, no primitive located | Cursor sandbox — and `~/.ssh` always readable | Jules VM · Aider · Devin CLI without `--sandbox` | Amp CLI · Amp orbs · Cline · OpenHands · Devin cloud VM |

The two cloud surfaces are the interesting ones, and they land in opposite corners for structural reasons. Codex cloud is the only surface in the matrix where the credential scope is a function of time rather than of configuration: secrets exist during the setup phase, when the network is also open so dependencies can install, and are removed before the agent phase begins, when the network closes. Two capabilities move together in the direction that reduces reach.

Devin cloud publishes the opposite shape, and publishes its own caveat about it. Secrets are injected as environment variables, and the scope you choose determines how long they live: org secrets are documented as usable in all future sessions within the organisation, personal secrets are scoped to your own sessions, repository secrets are tied to the snapshot, and session secrets are not persisted. Build-time secrets are removed before the snapshot is saved — but the vendor adds that if a command writes a secret value into a config file during `initialize`

, that value persists in the snapshot. The documented remedy is to move credential-writing steps into `maintenance`

. That is a first-party operational fact, and it is the kind of thing that only appears when a vendor documents its own lifecycle honestly.

One narrower note belongs here rather than in a section of its own. Copilot CLI’s `--secret-env-vars`

is the only credential mechanism in the matrix documented as extending to an MCP server’s environment. Where the boundary sits relative to MCP is a large separate subject with its own maintained record in our [MCP security incident ledger](/blog/mcp-security-incident-ledger), and this page does not develop it further.

## 07 — Dimension fourReduced-capability modes, and the harnesses that have *none*.

The question this column asks is narrow and has to stay narrow: does the harness ship a mode that **removes capability** — takes the command-execution tool away, or hard-caps the file tools — as opposed to a mode that merely asks more often. That distinction is the entire column, and it is where most of the set fails the test. An approval-level equivalent is a different thing and is labelled as one in the table below.

Claude Code’s `--restricted`

, available from v2.1.248 and also settable through `CLAUDE_CODE_RESTRICTED=1`

, is the strongest documented example. It removes the built-in tools that run commands or code, and it removes `WebFetch`

, unless each is named individually in `--tools`

— the `default`

preset will not do it. It confines the built-in file tools to the working directories. It loads **only managed settings and** `--settings`

, which is a more precise statement than ignoring user settings. It refuses `bypassPermissions`

. And it refuses to create cloud sessions. Anthropic even names the intended audience in the flag’s own description: an evaluation harness driving the CLI on a shared machine.

| Harness | Mode | What it removes | Removes, or only asks? |
|---|---|---|---|
| Ships a named mode (4 harnesses) | |||
| Claude Code | `--restricted` / `CLAUDE_CODE_RESTRICTED=1` (v2.1.248+) | The built-in tools that run commands or code, plus `WebFetch` , unless named in `--tools` ; confines file tools to the working directories; loads only managed settings and `--settings` ; refuses `bypassPermissions` ; refuses to create cloud sessions | Removes |
| Codex CLI | `--sandbox read-only` , or the `:read-only` permission profile; paired with `--ask-for-approval never` for the vendor’s own CI preset | Editing and command execution at the OS layer for spawned commands. The paired CI form is documented as “Codex can only read files; never asks for approval” | Removes; approval can still escalate unless paired |
| Cursor | `sandbox.json` `type: “workspace_readonly”` | Filesystem write inside the sandbox | Removes (filesystem write) |
| Gemini CLI | `SEATBELT_PROFILE=strict-open` or `strict-proxied` ; plus `security.disableYoloMode = true` | Read and write restrictions per the strict profiles; the YOLO key removes an escalation path even when a flag enables it | Removes (filesystem, escalation) |
| Operator can assemble one; no named mode ships (3 harnesses) | |||
| Copilot CLI | `--deny-tool='shell'` ; `/sandbox enable` with outbound connections turned off; `--secret-env-vars` | Deny takes precedence over `--allow-all-tools` , and “the AI model cannot use that tool at all”. The other two remove egress and credential reach respectively | Removes — assembled by the operator |
| Amp | An `amp.permissions` reject rule on the Bash tool, or `amp.tools.disable` | Rejects the tool call, or removes the tool from the set | Removes — assembled by the operator |
| Devin CLI | `--sandbox` with `Read(...)` and `Write(...)` deny rules | Hides denied read paths from sandboxed commands for the whole session | Removes (paths) |
| None located in the vendor pages read (6 harnesses) | |||
| Aider | None located. `--no-suggest-shell-commands` stops the model proposing shell commands; `/run` and `/test` remain available | — | Neither |
| Cline | None located. Auto Approve toggles change what runs without a prompt; they do not remove the tool | — | Asks only |
| Jules | None located | — | — |
| Devin cloud | None located in the environment and secrets pages read | — | — |
| Copilot cloud agent | None located as a mode; the firewall enabled or disabled toggle is an egress control | — | — |
| OpenHands | Provider selection is the only lever, and the `process` provider is documented as less isolated, not more | — | — |

The sayable claim is this one: of the harnesses checked here, *only Claude Code ships a single named flag whose documented purpose is to remove the command-execution tools and confine the file tools at once.* It is not sayable that no other harness has one — only that none was located in the vendor pages listed in this page’s method. Every “none located” cell above names the pages that were read, and a later refresh that finds one will move the row rather than rewrite the claim.

One naming correction belongs here, because it circulates as a mode and is not one. Codex has exactly three sandbox modes — `read-only`

, `workspace-write`

and `danger-full-access`

— and the newer permission profiles layer a second system on top, with the vendor advising you use one system or the other for a session rather than both. `codex exec --full-auto`

is not a fourth mode. OpenAI documents it as a **deprecated compatibility path** that prints a warning, and points non-interactive runs at `codex exec --sandbox workspace-write`

instead. Version drift on these two CLIs generally is tracked in our [read of what actually changed in the two agent CLIs](/blog/claude-code-codex-cli-agent-operator-changes-august).

## 08 — Stated limitsWhat the vendors say about their own *limits*.

Three of these vendors publish a limitations section inside the documentation for the boundary itself. Those statements belong in a capability map, because a documented boundary’s scope is part of the capability — but they belong as one sentence each, in the vendor’s own words, and nothing more. Where a sandbox actually leaks in practice is a different subject with a different treatment and it has its own page, so each of the three sentences below is recorded as the vendor published it and linked out rather than developed.

**Anthropic** writes that the sandbox proxy “does not terminate or inspect TLS on outbound traffic”, so “code running inside the sandbox can potentially use domain fronting or similar techniques to reach hosts outside the allowlist”. That is a property of how the allowlist is enforced, stated by the vendor in the allowlist’s documentation, and it is recorded here without elaboration; the [sandbox-leak post](/blog/agent-sandbox-escapes-worktree-symlink-command-filters-2026) is the place that subject is treated.

**GitHub** lists three limitations for its cloud agent firewall, of which the relevant one for a capability map is the scope: “the firewall only applies to processes started by the agent via its Bash tool. It does not apply to Model Context Protocol (MCP) servers or processes started in configured Copilot setup steps.” The same page states that “sophisticated attacks may bypass the firewall”. Both are recorded as published and neither is developed here; the [July 26 sandbox-leak census](/blog/agent-sandbox-escapes-worktree-symlink-command-filters-2026) is where that subject lives.

**OpenAI** documents that the Codex proxy’s DNS and IP classification blocks lookups that fail and hostnames resolving to non-public addresses, and states that this “reduces DNS rebinding risk, but it does not eliminate it”. A vendor bounding its own claim in the sentence that makes it is exactly the sort of statement a census should carry verbatim and leave alone — and, again, hand off to [the post that treats sandbox leaks](/blog/agent-sandbox-escapes-worktree-symlink-command-filters-2026).

Two vendors describe the limits of their own mechanisms rather than of a boundary, and both are worth quoting for the same reason. Cline writes that it “does not use a fixed allowlist. The model marks each command with a `requires_approval`

flag based on the command and arguments. These are examples, not guarantees.” That is the only purely model-judgment cell in the whole matrix, and the vendor says so. All Hands labels one of its own OpenHands providers “process sandbox (unsafe, but fast) … no container isolation”, which is a rare and useful thing for a vendor to print in its own provider table.

One caveat about the tool-result path, and then this section closes. Codex CLI 0.151.0, released 2026-08-29, notes that extensions can now inspect or replace MCP tool results before they reach the model — which means the tool-result path is extensible, and the integrity of what the model reads is a configurable surface rather than a fixed one. That subject lives in the [MCP security incident ledger](/blog/mcp-security-incident-ledger) and stops there; it is not one of this page’s four dimensions.

## 09 — AppliedUsing this matrix when you *evaluate* a harness.

The most useful thing about this dataset is not any single cell. It is that three of these harnesses will print their own effective boundary on the machine you are actually running, which means you do not have to take a table’s word for it — including this one. Copilot CLI has `/sandbox policy`

, which prints the effective policy per directory. Codex has `codex sandbox macos|linux|windows`

, optionally with a named permissions profile and `--log-denials`

. Claude Code exposes its resolved configuration through the `/sandbox`

Config tab. Those three are the only self-inspection commands in the set, and a harness that has one is materially easier to review than one that does not.

##### Read the two credential cells before anything else

Whether a fresh install can read your SSH keys and whether it can open an outbound connection are the two facts that compound. Four harnesses ship a credential primitive and only one does anything by default, so on most of this set the honest answer for a fresh install is inheritance. If a harness sits in the allowed-egress and inherited-credentials row of the quadrant above, that is the review finding, not a configuration detail.

##### Ask which actor the sandbox actually covers

On Claude Code the sandbox covers Bash subprocesses and not the built-in file tools. On Copilot CLI the OS covers child processes while the file tools are a software-only check by the vendor's own description. On the Devin CLI it is inverted. A single is-it-sandboxed answer will be wrong on three of the largest harnesses here, so the question to ask a vendor is which actor the boundary covers, not whether one exists.

##### Confirm a repository cannot loosen your boundary

Three vendors independently refuse repository-level widening, each differently: Anthropic honours masking and TLS-termination keys only from user, managed or --settings scopes; Cursor's hardcoded rules and team policies cannot be weakened by either configuration file; Cognition makes Devin's sandbox block user-config only. If a harness accepts its boundary configuration from a checked-in file, that is a governance question about every repository you clone.

##### Print the effective policy on your own machine

Three harnesses will tell you: /sandbox policy on Copilot CLI, codex sandbox with an optional profile and --log-denials on Codex, and the /sandbox Config tab in Claude Code. Run the one your harness has before you accept any table's cell, including this page's. Everything here is documentation-read, and a documented default is not the same object as an observed one.

Two neighbouring assets answer questions this page deliberately does not. What the agent does without stopping to ask is censused in [the permission-defaults census](/blog/coding-agent-permission-defaults-census), which is the companion to this table and covers a partly different harness set — read the two together and you have capability and consent for most of the market. Where your code and prompts travel once they leave the machine is a third question, censused in [our census of agent data terms](/blog/coding-agent-data-terms-census-2026). And if the practical question is which harness a team of engineers should be standardising on, with a security review that has to survive procurement, that is the kind of engagement our [AI transformation practice](/services/ai-transformation) opens with.

## 10 — ConclusionFour questions, asked *separately*.

### Sixteen surfaces, four dimensions, and twenty cells that say the vendor has not published it.

The design decision that makes this table worth citing is that it never collapses four questions into one verdict. Filesystem scope, network egress, process spawning and credential visibility are recorded in separate cells, each for a fresh install and again for a documented flag, and a reader can quote one without inheriting our reading of the others. On most of these harnesses the four answers do not point the same way.

The finding a security reviewer should take away is in the credential column. *Four of eleven harnesses ship a documented credential-scoping primitive, and only one of the four does anything on a fresh install* — for two named variables. Two vendors state in their own documentation that SSH keys remain readable inside the sandbox. A third grants read of package-manager tokens by default. None of that is a flaw in any product; it is what inheriting a parent process environment means. It is also not discoverable from any single vendor’s page, which is why it needed a table.

Twenty cells carry an UNVERIFIED label, and they are the reason to trust the rest. Amp, Aider and Cline publish rich approval models and no isolation model, and those cells say so with the pages named instead of borrowing a value from a hardening guide. This page is maintained monthly by the Digital Applied Team: rows move as vendors publish, labelled gaps close when a vendor documents the mechanism, and the as-of date on the caption is the only date that should ever be cited alongside a cell.