# Security model

This is the security architecture of cplt: the threat model it addresses, the defense layers it implements, and how automated tests validate them.

## Supported agents

cplt sandboxes AI coding agents. Currently that means **GitHub Copilot CLI**, **[OpenCode](https://opencode.ai/)**, **Google Gemini CLI**, **[Antigravity CLI](https://github.com/google-antigravity/antigravity-cli)**, **[Pi](https://github.com/earendil-works/pi)**, **[Claude Code](https://docs.anthropic.com/en/docs/claude-code)**, **[goose](https://github.com/aaif-goose/goose)**, and **DeepSeek Harness** (`dsh`). All share the same core sandbox (deny-default Seatbelt/Landlock profile, env sanitization, scratch dir), with per-agent adaptations:

| Property        | Copilot                             | OpenCode                                                            | Antigravity                                 | Pi                                          | Claude Code                                  |
|-----------------|-------------------------------------|---------------------------------------------------------------------|----------------------------------------------|---------------------------------------------|----------------------------------------------|
| Auth mechanism  | GitHub token (Keychain, `GH_TOKEN`) | `/connect` device flow to `auth.json`, or API keys                  | Google OAuth (browser / keyring session)     | API keys (Anthropic, OpenAI, Gemini, etc.)  | OAuth token (Keychain / `~/.claude`) or API key |
| Auth in sandbox | Environment token, one-shot gh guard cache, or native Keychain login on macOS | Copilot auth stored in data dir; third-party keys need `--pass-env` | OAuth/session data stored in `~/.gemini/*` | Keys need `--pass-env`             | OAuth stored in `~/.claude`/Keychain; keys need `--pass-env` |
| Config dir      | `~/.copilot` (read/write; Linux adds execute, see below) | `~/.config/opencode` (read-only)                                    | `~/.gemini/config` (read/write)              | `~/.pi/agent` (read-only root; `sessions/`, `prompts/`, `themes/`, `tools/`, `tmp/` writable) | `~/.claude` + `~/.claude.json` (read/write)  |
| Data dir        | `~/Library/Caches/copilot`          | `~/.local/share/opencode` (write, no exec)                          | `~/.gemini/antigravity-cli` (read/write)     | `~/.pi/agent/bin` (read + exec)             | N/A (in config dir)                          |
| State data dir  | N/A                                 | `~/.local/state/opencode` (write, no exec)                          | N/A                                          | N/A                                          | N/A                                          |
| Keychain access | Yes¹                                | No                                                                  | Yes (OAuth/keyring flow)¹                    | No                                          | Yes (macOS OAuth token storage)¹             |
| SEA extraction  | Yes (pre-sandbox)                   | No                                                                  | No                                           | No                                          | No                                           |
| Env isolation   | Exported token vars passed; resolved gh substitute or opt-in injection adds a token; `COPILOT_*` passed | suppressed (see below)                          | suppressed (see below)           | suppressed (see below)          | suppressed (see below); `DISABLE_AUTOUPDATER=1` injected |
| Auto-detected   | Yes (priority 1)                    | Yes (priority 2)                                                    | Yes (priority 3)                             | No (explicit only, name collision risk)     | No (explicit only)                           |

¹ On macOS the Keychain grant is dropped when a substitute resolves (`sandbox.keychain_substitute`: on by default for Copilot and Claude Code, opt-in for the others); see [Keychain access is all-or-nothing](#keychain-access-is-all-or-nothing). For Copilot that is a nonblank exported `COPILOT_GITHUB_TOKEN`, `GH_TOKEN` or `GITHUB_TOKEN` surviving `deny.env`, or gh's stored github.com token injected into the first permitted name. A failed retrieval or detected account mismatch keeps the grant when no exported substitute resolves. For Claude Code it means `CLAUDE_CODE_OAUTH_TOKEN` is exported and not denied. Resolution does not validate the credential.

### GitHub token handling per agent

| Agent | `GH_TOKEN`/`GITHUB_TOKEN` from host env | `inject_token` (deprecated²) | `gh auth token` | Real `gh` behind the gh guard | Keychain |
| --- | --- | --- | --- | --- | --- |
| Copilot | Passed unless denied | First of `GH_TOKEN`, `GITHUB_TOKEN`, `COPILOT_GITHUB_TOKEN` not in `deny.env`; skipped for a surviving exported token or gh-token substitute | Served once from `.gh-token` when enabled and cached; skipped for a surviving exported token, denied `GH_TOKEN`, or gh-token substitute | Surviving `GH_TOKEN`/`GITHUB_TOKEN`, native Keychain access on macOS when granted, or `.gh-exec-token` when eligible. gh ignores `COPILOT_GITHUB_TOKEN` | Conditional on macOS¹ |
| Every other agent | Stripped (`--pass-env GH_TOKEN` forwards it) | Ignored | "No cached token" (with `block_auth_token = true`, the default) | `GH_TOKEN` from the exec token | Antigravity, Claude Code and goose yes¹; the rest no |

² On macOS `gh_guard.inject_token` has no effect: the exec token covers `gh`, and the Keychain substitute covers Copilot. cplt still accepts the key and never refuses a launch over it. While it is `true`, cplt prints one line at launch, and `cplt check` lists it with the replacement. On Linux there is no Keychain grant to drop; for Copilot the substitute reads Copilot's own Secret Service login on the host with `secret-tool` and passes it as `COPILOT_GITHUB_TOKEN` (see [Linux keyring access](docs/known-impacts.md#linux-keyring-access-depends-on-the-backend-and-agent-version)). When no lookup runs or it finds nothing, this key is the recommended handover. Native access depends on the backend and agent version; the keyring is not guaranteed closed. `cplt check` also notes `GH_TOKEN` or `GITHUB_TOKEN` in `pass_env` for agents other than Copilot, since `gh` no longer needs it there; keep it if another tool uses it.

**The exec token.** With the gh guard on and a scratch directory, cplt can write `$SCRATCH/.gh-exec-token` at mode `0600` when gh's effective `hosts.yml` exists and trusted stored-token retrieval succeeds. File existence alone is not proof of login. A surviving child `GH_TOKEN`/`GITHUB_TOKEN`, a gh-token substitute, or `deny.env` naming `GH_TOKEN` suppresses this cache. macOS Copilot also skips it when no substitute resolves, because its Keychain grant stays; Linux Copilot and other agents can use it. The gh wrapper sets `GH_TOKEN` from the file on the real gh it runs, for that process only. The cache does not put the token in the agent's environment; other handover channels can. HTTPS git authentication to github.com uses the same wrapper: cplt appends `credential.https://github.com.helper = !gh auth git-credential` through `GIT_CONFIG_*`, after the user's helpers. Those helpers retain precedence; other hosts are unchanged. A host with only an exported token and no `hosts.yml` gets no exec cache; non-Copilot agents need `--pass-env GH_TOKEN` to receive that exported token. `__CPLT_GH_TOKEN_DIR` points the guard to the actual scratch directory even if the user passes a different `TMPDIR`. The file remains for the session, is removed with the scratch directory on exit, and an orphaned cache is cleaned by a subsequent scratch-enabled launch.

**The limit.** A sandboxed agent can get the host user's full gh token, unless `proxy.inject_github_token` is on (see below), in which case it gets a placeholder. It can read `$TMPDIR/.gh-exec-token`, or run `gh auth git-credential get`, which the gh guard allows because HTTPS push needs it. The gh guard limits which `gh` commands the wrapper runs. It does not limit what the token can do once the agent has it, for example with `curl` against the GitHub API. A narrower token for the sandbox is planned ([#731](https://github.com/navikt/cplt/issues/731)).

**Retrieval is not authentication.** Doctor and launch use the same trusted-directory gh lookup and `gh auth token --hostname github.com`, with `COPILOT_GITHUB_TOKEN`, `GH_TOKEN` and `GITHUB_TOKEN` removed from that subprocess. The child has null stdin/stderr, a 5-second exit timeout and a 500 ms stdout-EOF grace. A nonempty result proves only retrieval from gh's stored credential source, not token validity, entitlement, selected Copilot account or long-session renewal. Doctor does not print the token. A Keychain grant or discovered native module is not proof of a stored login.

**OpenCode** also gets that token as its GitHub Copilot login when its `auth.json` has no `github-copilot` entry. cplt sets `OPENCODE_AUTH_CONTENT`, which OpenCode reads instead of `auth.json`: your other providers copied from the file, plus a `github-copilot` entry holding the gh token. So for OpenCode the token is in the agent's environment, not only in the exec token file. An existing `github-copilot` entry (a `/connect` login or Enterprise), or an `auth.json` cplt cannot parse, leaves OpenCode alone. A normal run does not rewrite `auth.json`; `/connect` inside the sandbox does, and writes the gh token in as the `github-copilot` entry, which the next session then uses. `deny.env` naming `GH_TOKEN` or `OPENCODE_AUTH_CONTENT` turns this off.

**GitHub MCP for OpenCode v2** ([#797](https://github.com/navikt/cplt/issues/797)). When the user's own OpenCode config (the config dir, or `OPENCODE_CONFIG_CONTENT` when it reaches the sandbox) names `https://api.githubcopilot.com/mcp` or `/mcp/readonly` in `mcp.servers` (or the legacy `mcp.<name>`), cplt serves an endpoint at a random 128-bit path on its existing proxy port and points the entry at it with `"oauth": false` through `OPENCODE_CONFIG_CONTENT`. Project config never enables it, since the agent can write it. No sandbox rule is added: on Linux a Landlock port rule cannot be limited to loopback, so a new port would be reachable on every host. The path is compared in constant time, and the proxy's connection limit, head size cap and head deadline apply. The endpoint holds the gh token, retrieved the same way as above, and does not put it in the sandbox. Every request goes to `https://api.githubcopilot.com/mcp/readonly` with `X-MCP-Readonly: true` and `X-MCP-Lockdown: true` forced. The entry's or agent's `Authorization`, `Cookie` and `X-MCP-*` headers are dropped (`X-MCP-Toolsets` passes), and a header with any control byte other than tab is refused. The upstream leg runs through the system `curl` from a trusted directory. The token and request go in on stdin rather than in argv, `-q` skips `~/.curlrc`, and `SSLKEYLOGFILE` is removed. The agent therefore gets read-only GitHub MCP tools with the user's identity and lockdown on, not the token. This channel does not change the [limit](#github-token-handling-per-agent) above: the token is still reachable through the exec token, and through `OPENCODE_AUTH_CONTENT` where that handover applies. `sandbox.github_mcp_proxy = false`, `--no-github-mcp-proxy`, or `deny.env` naming `GH_TOKEN` or `OPENCODE_CONFIG_CONTENT` turns it off.

**Brokered local MCP servers** ([#824](https://github.com/navikt/cplt/issues/824), macOS, and Linux under Bubblewrap ([#834](https://github.com/navikt/cplt/issues/834)); the agent's sandbox then has the D-Bus and systemd sockets masked, and the server child gets its own sandbox, described below). A local MCP server with a broker spec in `~/.config/cplt/mcp/` runs on the host as a child of cplt, not in the sandbox, so it can use its own host login (for `nais`, the keychain) without the sandbox getting that grant. Specs are read only from the user config dir, never from the repository. A symlinked spec is refused, and so is a spec whose file, or any entry on the way to it, the session's final sandbox policy makes writable (tool caches, agent dirs, the shared git dir and every `allow.write`, file grants included). `cplt mcp status` applies the same check; run outside a project (from `~`, say) it checks against an empty stand-in project and reports `"project": null`. cplt refuses a spec that names an unknown credential mechanism, runs anything other than the mechanism's fixed command (for `nais-keychain`, `nais alpha mcp serve`; the `none` mechanism has no fixed command and no probe, so it runs any command in the trusted dirs, the same trust as `allow.exec`), names a command outside the trusted dirs, holds a secret value or a credential placeholder, or allows a `write` or `external` tool without `writeConsent` (a `host-exec` tool never). The child starts in `/`, never the agent-writable project (so `python3 -m` cannot import planted code), with a cleared environment (`HOME`, a trusted-dirs `PATH`, `TMPDIR`, `LANG`, an empty `NO_PROXY`, and `HTTPS_PROXY`/`HTTP_PROXY` pointing at its own CONNECT-only proxy on 127.0.0.1). That proxy allows only the spec's `egressHosts` (exact or subdomain), port 443 only, refuses names that resolve to loopback, private or link-local addresses, and logs each refusal as DENIED. The agent's allowlist is not changed. On macOS the child runs under its own Seatbelt profile ([#849](https://github.com/navikt/cplt/issues/849)): outbound TCP reaches only that proxy port, so a program that ignores the proxy variables gets `EPERM`; UDP is denied; writes go only to its temp dir and its mechanism's config dir (for `nais-keychain`, `~/Library/Application Support/nais`, plus `~/Library/Keychains/login.keychain-db` and its `.sb-*` temp siblings, which Security.framework rewrites in the caller's process on a token refresh); reads, the keychain through securityd, and name lookups stay open; no listener and no unix-socket connects. Mach lookups are limited to the services a real nais run was measured to use ([#911](https://github.com/navikt/cplt/issues/911)): `com.apple.SecurityServer` (securityd, for the keychain), plus the system services `bsd.sb` allows. An XPC service that makes requests for its caller, such as `nsurlsessiond`, is therefore out of reach. What remains: securityd and the `bsd.sb` services still act on the child's behalf, so this contains a cooperating server like nais, not an arbitrary hostile binary. On both systems the credential probe of `cplt mcp status` runs in the server's own sandbox and egress proxy ([#930](https://github.com/navikt/cplt/issues/930)), since nais reads `config.yaml` from the dir the server can write and a planted value there could otherwise make the probe run gcloud on the host. On Linux the child runs under Bubblewrap with its own network namespace ([#849](https://github.com/navikt/cplt/issues/849)): its only way out is the egress proxy, bound in as a unix socket and relayed to `127.0.0.1:<port>` inside the namespace by a cplt relay process, so a direct connect gets `ENETUNREACH`; the root is read-only; `HOME` is an empty read-only tmpfs with only the mechanism's own entries bound back (for `nais-keychain`, the writable `~/.config/nais` under `XDG_CONFIG_HOME`, and nothing else), so sockets in `HOME` such as Docker Desktop's `~/.docker/desktop/docker.sock` are gone; writes go only to a private `/tmp` and that config dir; `/run`, the runtime dir and the Nix daemon's socket dirs are private, and bwrap 0.8 and later adds `--disable-userns` (`cplt doctor` warns below 0.8). A `keychain` mechanism gets a session bus filtered by `xdg-dbus-proxy --filter --talk=org.freedesktop.secrets` (resolved from the trusted dirs, living as long as the child), so it can reach the Secret Service and nothing else on the bus: not `systemd --user`, and no D-Bus activation of other services. The host bus itself is never bound in. Without xdg-dbus-proxy or a host bus the child gets no bus (`cplt doctor` warns). Other mechanisms get no bus. Without bwrap, or if the namespace cannot be built, the child does not start. The broker log is the `--proxy-log` file: every `tools/call` leaves one line there with the server id, tool, outcome (ALLOWED, DENIED with the reason, FAIL with the integer error code, or CANCELLED) and duration, never arguments or results; the terminal shows only DENIED lines and failures. The child's stderr goes to the broker log, at most 64 lines of 512 bytes, token-shaped runs redacted. The sandbox may connect only to the broker's socket, in a per-session directory outside every grant. The agent can only pick a declared server id. The broker parses every JSON-RPC line and forwards its own re-serialization, so the server sees exactly what was checked. It drops client notifications other than `initialized`, `cancelled` and `roots/list_changed` (an id-less `tools/call` never reaches the server), refuses a request whose id is already in flight, filters `result.tools` in every response, refuses batches and protocol versions other than 2025-06-18 and 2025-11-25, lists and allows only `tools.allow`, refuses `execute_graphql` arguments with a key that case-folds to `query`, and documents with a mutation, a subscription or more than one operation (fragments included, anything unparsable refused), refuses keys in the envelope, `params` and `arguments` that case-fold together or to a checked field (Go's `encoding/json` matches field names that way), caps in-flight requests at 8 (a client `notifications/cancelled` frees its slot and the late response is dropped; a request unanswered after 120 s gets a JSON-RPC timeout error, the server a cancel, and the slot is freed), drops server-initiated messages, and serves at most 32 connections at once (socket clients and egress tunnels), closing extra ones before any thread starts; a handshake that stalls ends after 10 s. Rejected-spec paths and reasons are escaped before they reach the terminal. Residual risk: the child runs trusted code on arguments the agent chooses, and can read what the user can (and send it to its `egressHosts`); on Linux it can reach unix sockets outside `HOME`, `/tmp` and `/run` (under `/var`, say), and read copies of `HOME` elsewhere in the root (a btrfs snapshot, a second bind mount): hiding `HOME` is a denylist, and a keychain server can read every Secret Service item the user's session has unlocked, not only its own: with gnome-keyring, every item in the login collection, including other apps' passwords and tokens, plus whatever gnome-keyring's internal interface allows over the same bus name; with KeePassXC's Secret Service integration, every entry in the groups it exposes.
**Proxy-side token injection** ([#820](https://github.com/navikt/cplt/issues/820), `proxy.inject_github_token`: on in configs written by `cplt config init`, off in configs without the key). The sandbox gets a placeholder with the real token's prefix and length in every channel above. For `api.github.com`, `github.com`, `uploads.github.com` and `*.githubcopilot.com` on 443, after every proxy policy gate has passed, the proxy terminates TLS with a leaf from a per-session CA whose key exists only in cplt's memory and is name-constrained to `github.com` and `githubcopilot.com`. It restores the real token only in `Authorization` (`Bearer`, `token`, `Basic` password), never on the GitHub MCP paths or `TRACE`, and forces one request per connection so later bytes cannot be rewritten. The upstream leg trusts the system roots plus CAs from the user's env, held in memory; the bundles in the scratch dir are agent-writable and only affect what the agent trusts. This removes the long-lived token from the sandbox but not its use: the agent can still send requests through the proxy that carry it. `hosts.yml` remains readable. A setup failure refuses the launch; it never falls back to the real token. A token without a known GitHub prefix (`gh?_`, `github_pat_`) cannot get a placeholder and is passed as is.

A token in the environment is readable: `block_auth_token` blocks `gh auth token`, not `echo $GH_TOKEN`. The direct-`curl` bypass in [gh guard security boundaries](docs/gh-guard.md#security-boundaries) applies to any agent that can read the token.

### Rules that apply to every non-Copilot agent

- **Copilot env vars are suppressed.** `GH_TOKEN`, `GITHUB_TOKEN`, `COPILOT_GITHUB_TOKEN`, and every `COPILOT_*` variable are stripped for OpenCode, Gemini, Antigravity, Pi, Claude Code, goose, and DeepSeek Harness. OpenCode's Copilot provider uses its own auth file or the host gh login, and `gh` still authenticates through the gh guard; see [GitHub token handling per agent](#github-token-handling-per-agent).
- **Third-party API keys are opt-in.** `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`, `GEMINI_API_KEY`, `OPENROUTER_API_KEY`, `ANTHROPIC_AUTH_TOKEN`, `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`), and the Bedrock/Vertex routing vars (`CLAUDE_CODE_USE_BEDROCK`, `AWS_BEARER_TOKEN_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `ANTHROPIC_VERTEX_PROJECT_ID`, `GOOGLE_CLOUD_PROJECT`) are never passed through by default. You have to name each one with `--pass-env`. That keeps credentials from reaching a sandboxed process by accident.

- **Host-persistence guard on the agent's own writable grants.** Most agents get their global config dir mounted read/write — and for some, more than that: the shell also gets the fish *data* dir, Claude a top-level file (`~/.claude.json`), OpenCode its data, state and cache dirs. Some files in those grants auto-execute the next time the agent runs *outside* the sandbox. goose is the exception: its config dir is read-only, because it rewrites `config.yaml` by rename, which needs directory write and would hand back the whole vector. Those paths are write-denied (`Agent::host_persistence_denies`):

  | Agent | Denied inside the agent's writable grants |
  | --- | --- |
  | Claude Code | `settings.json`, `statusline.sh`, `plugins/` |
  | Pi | `settings.json`, `trust.json`, `extensions/`, `npm/`, `git/`, `skills/` |
  | Antigravity | `config/hooks.json`, `config/mcp_config.json`, `antigravity-cli/bin/` |
  | Copilot | `settings.json`, `hooks/`, `mcp-config.json`, `lsp-config.json`, `extensions/`, `installed-plugins/`, `pkg/`, `skills/` |
  | Shell (fish) | `config.fish`, `conf.d/`, `functions/`, `completions/`, `vendor_conf.d/`, `vendor_functions.d/`, `vendor_completions.d/` |
  | goose | — (its whole config dir is read-only; see below) |
  | DeepSeek Harness | `cordis.patch.yml` (home-level overlay; `profiles/` stays writable so DSH can rewrite its boot include-root) |
  | OpenCode | — (skills live in its read-only config dir; see below) |

  **Hook and status-line scripts outside `~/.claude` ([#702](https://github.com/navikt/cplt/pull/702), [#705](https://github.com/navikt/cplt/issues/705)).** cplt reads the user-level `settings.json` (never `settings.local.json` or a project's `.claude/settings*.json`, which the agent can write) and grants read + execute on the one file each hook or `statusLine` command runs: the command itself, or the script an interpreter (`python3`, `node`, `bash`, `uv run`, ...) is given. Other arguments, such as a log file, are not granted. The granted file is write-protected inside the sandbox. Files in a credential directory, under the Claude config root, or under another writable grant are skipped, and a hook inside an `allow.write` tree stays exec-denied. A script that imports sibling files needs `allow.read` on its directory. On Linux the grant applies only when Bubblewrap is active, because only its read-only bind keeps `settings.json` out of the agent's reach. With Landlock alone the whole Claude config root is writable, so cplt drops the grant, warns, and the hook may fail. On Linux, cplt creates a missing `~/.claude/settings.json` (or its `CLAUDE_CONFIG_DIR` equivalent) as `{}` before every launch, with or without Bubblewrap, so Bubblewrap can bind it read-only; an existing file is never overwritten. On hosts that run Claude without Bubblewrap (Landlock only), the agent can edit `settings.json` during that session, and a later Bubblewrap launch trusts whatever hook paths it names; only scripts outside writable trees and credential directories get read + exec.

  **Hook and MCP scripts outside `~/.copilot` (macOS only, [#704](https://github.com/navikt/cplt/issues/704)).** cplt reads `~/.copilot/settings.json`, `hooks/*.json` and `mcp-config.json` (never a project's hook or MCP files, which the agent can write) and grants read + execute on the one file each hook command (`bash`, `command`, or `exec` + `args`) or MCP server `command` + `args` runs: the command itself, or the script an interpreter is given. All three are write-denied inside the sandbox, so the agent cannot add entries. A symlinked hook file or `hooks/` directory is not read. The other rules match the Claude Code grant: no other arguments, the granted file is write-protected, and credential paths and paths under `~/.copilot` are skipped. Linux is unchanged for now.

  For both: no grant is made when the configured script path, or any symlink crossed resolving it, lies in a tree the agent can write (project, `--repo-dir`, `allow.write`, a writable agent dir), since the agent could repoint that link at any file.

  Two of these go beyond "the file that names the code". Pi's `npm/` and `git/` hold the code of packages `pi install` already fetched: denying only the settings file stops a *new* entry being added while leaving the code an existing entry already points at editable in place, which loads on the next host run. Antigravity's `bin/` holds `agentapi` and `webm_encoder`, which it executes on the host.

  `skills/` is a third kind and the newest ([navikt/copilot#858](https://github.com/navikt/copilot/issues/858)). Nothing in it fires at launch. A skill is the instructions the model is offered in the *next* session, and the way a skill does work is by naming a script for the agent to run — `bash "$SKILLS_DIR/<skill>/<script>.sh"` is the documented shape — so writing a skill is writing the argument to a later shell command, not prompt content. An agent that can edit `~/.copilot/skills/` edits its own future instructions. This document previously said the opposite for Copilot, and that sentence is gone. **Claude Code's `skills/` stays writable**, and the difference is where skills come from, not what they are: Copilot's and Pi's are put there by an install that runs outside cplt, while authoring a skill in-session is most of what `~/.claude/skills/` is for. It is a documented residual rather than an open question: [#366](https://github.com/navikt/cplt/issues/366) closed with the directory left writable, no open issue tracks changing that, and `--deny-path ~/.claude/skills` closes it (macOS, or Linux with bubblewrap) for a deployment that wants it closed.

  `skills/` also differs by platform. For **Copilot** it rides the same bubblewrap overlay as the other seven, but unlike `extensions/` it reliably **exists** once anything is installed, so the Linux deny is real rather than nominal in the common case. For **Pi** the directory additionally lost its write grant in `config_dirs` — it joins `extensions/`, `npm/` and `git/` as read-only by construction — so there it holds under plain Landlock, with no bubblewrap. The cost for Pi is the same shape as those three: a skill is installed outside cplt.
- **No `allow.write` reopens them.** On **macOS** the denies are emitted at the tail of the profile, after `emit_user_allows`, so SBPL last-match-wins keeps them on top. That placement is load-bearing: while they sat beside the dir-wide allow, `allow.write = ["~/.claude"]` — an ordinary grant, since `is_unsafe_root` only rejects `~` itself — silently reopened every one of them, including Claude's `statusline.sh` and `plugins/`. This is the same fix #212 applied to the git-persistence denies. The consequence is that there is deliberately **no in-cplt escape hatch**: a step that needs to write a denied file happens outside cplt.
- **Linux is weaker.** Landlock cannot deny a subpath inside an allowed directory, so the deny is carried by the same bubblewrap read-only overlay used for `.git/hooks`: it holds only when `bwrap` is present, and only for paths that **already exist on disk** — bubblewrap cannot bind a missing source. That caveat bites harder here than it does for git, because `git init` creates `.git/hooks` while `extensions/` does not exist until the first extension is installed, so on Linux that particular deny is nominal in the common case. New configs set `sandbox.mask_missing_deny_paths = true`, which closes this for directories (and for missing `config.worktree` files when `sandbox.allow_git_config_write = false` and `extensions.worktreeConfig` is enabled): a missing deny directory whose parent exists gets an empty read-only tmpfs, so the agent cannot create it. The agent then sees an empty directory, and bubblewrap leaves the empty mountpoint on disk. Still open with the key on: a missing *file* (`settings.json`, `hooks.json`, `mcp-config.json`), which would need a placeholder the agent reads as an empty config, and a directory whose parent is missing, because masking it would make bubblewrap create the parent in the real home; the launch warns about each one it skips. Which entries are directories is an explicit list (`HOST_PERSISTENCE_FILES` names the files), so fish's `conf.d` and `vendor_*.d` are masked too. Without the key (existing configs) nothing changes and `cplt doctor` suggests it. Without bubblewrap, the guard is unenforced on Linux entirely.
- **Cost: do the affected step outside cplt.** Denying `settings.json` breaks whatever writes it. For **Pi** it is `pi install` plus every in-session setting that persists there — `/model` (Ctrl+S), `/thinking`, `/settings` — but not auth, which comes from provider API keys via `--pass-env`. For **Claude Code** and **Antigravity** auth is unaffected; the cost is editing hooks, MCP config or a statusline from inside a session. For **Copilot** it is `/settings`, `/config`, `/mcp add` and `/lsp`; auth, the session store, saved permissions and logs are untouched, because Copilot keeps its own mutable state in different files (`config.json`, `permissions-config.json`, `session-store.db`, `session-state/`, `command-history-state/`, `logs/`, `ide/`, `mcp-oauth-config/`, `mcp-secrets/`, `plugin-data/`) that stay writable.


### Agent notes beyond the table

**OpenCode.** The data dir (`~/.local/share/opencode/`: sessions, auth, SQLite DB) and the state dir (`~/.local/state/opencode/`: locks, history, statistics) both carry `(deny process-exec)` and `(deny file-map-executable)` alongside their write permission, so neither can be used for write-then-exec persistence. The config dir (`~/.config/opencode/opencode.json` and friends) is read-only, so the agent cannot tamper with settings that apply to unsandboxed runs. That read-only config dir is also why OpenCode needs **no** `skills/` entry when Copilot and Pi got one: OpenCode reads skills out of the config dir, or out of wherever `OPENCODE_CONFIG_DIR` points, and both are read-only on both backends already — by the grant itself, not by a deny, so it needs no bubblewrap and no path that exists in advance. nav-pilot's staged OpenCode launch points `OPENCODE_CONFIG_DIR` at a pinned payload and hands cplt `--allow-read` on it, which inherits the same posture. The cache dir's `~/.cache/opencode/bin/` — the managed `rg`/`fd` OpenCode downloads and runs — is granted process-exec and no write, and macOS write-denies it at the tail of the profile. On **Linux it is a residual**: its writable ancestor is `~/.cache`, which `HOME_TOOL_DIRS` grants to every agent, so narrowing OpenCode's own cache grant would take nothing away, and Landlock cannot subtract. The bubblewrap read-only overlay re-binds it (the same treatment `~/.cache/copilot/pkg` gets, and for the same reason), which means the control is absent on a Linux host without user namespaces.

**OpenCode plugins and local MCP servers outside the granted dirs (macOS only, [#703](https://github.com/navikt/cplt/issues/703)).** Because the config dir is read-only, cplt trusts the user config in it (`opencode.json`, `opencode.jsonc`, `config.json`) and grants read + execute on each `file://` plugin and on the one file each local `mcp.<name>.command` runs (the script, when the command is an interpreter). Other arguments are not granted, and the granted file is write-protected inside the sandbox. Project config is never read. When the config dir, a config file, or any symlink on the way to either resolves into the project, an `allow.write` tree or another writable grant (for example `XDG_CONFIG_HOME` inside the project, or a config dir or `opencode.json` symlinked into it), the agent can edit the config or swap the whole dir with `mv`, so cplt grants nothing from it. A config file symlinked to a dotfiles repo outside every writable tree is still read. A `file://` URL is percent-decoded. For a directory plugin the entrypoint (`package.json` `main`, else `index.ts` or `index.js`) is granted only if it resolves inside the plugin dir, and nothing is granted when the plugin dir, or a symlink on the way to it, is in a writable tree. Files in a credential directory, under the config dir, or under OpenCode's writable data, state and cache dirs are skipped; launch is never refused. Linux is unchanged.


**Copilot.** `~/.copilot` is granted read/write plus map-executable, and is an ordinary `AgentDir` rather than a hand-written profile block, which is what lets the host-persistence guard reach into it. Ten paths inside it are write-denied (eight with `sandbox.allow_copilot_host_persistence` on). `settings.json` carries `hooks.<event>[]` entries whose `bash` / `command` / `exec`+`args` fire at lifecycle points, and `hooks/*.json` is the same schema in its own directory. `mcp-config.json` (`mcpServers.<name>.command`) and `lsp-config.json` (`lspServers.<name>.command`) both name host processes the CLI spawns — LSP servers start automatically once the working directory is trusted. `extensions/` runs Node modules; GitHub's own documentation says extensions "execute on your computer with your privileges", and while they are gated behind `--experimental` today, that is a flag the user flips, not a boundary. `pkg/` holds the native `.node` addons and carries the deny that used to be hardcoded next to the grant.

**On Linux `~/.copilot` is also executable by default**, so it is a writable tree the agent can run a dropped binary from. Landlock's EXECUTE is checked on `execve()` only, so the execute right is not what loads the `.node` addons; it is carried over from the old hand-written rule. `sandbox.deny_copilot_dir_exec = true` removes it and leaves read and write ([#324](https://github.com/navikt/cplt/issues/324)). It is off by default because a plugin, MCP server, LSP server or hook launched as a program stored under `~/.copilot` would stop working. It has no effect on macOS. Two residuals, both warned at launch: if `~/.copilot` is a symlink into a tree granted execute, Landlock's union keeps its contents executable and the key does nothing; if Copilot is installed inside `~/.copilot`, its install directory keeps execute, since Copilot cannot start without it.

`installed-plugins/` is the seventh, and it is the one entry whose cost is not settled — see below. None of the other six is written by the CLI in normal operation; they change only when you run `/settings`, `/config`, `/mcp add` or `/lsp`, so the guard costs those four commands inside the sandbox and nothing else.

`skills/` is the eighth and the only one that does not auto-execute. It is denied because a skill steers the next session and names the scripts that session runs; the argument and the comparison with Claude Code are in the host-persistence table above. **Editing a skill from inside a session is now refused** — the write fails with `Operation not permitted`, and so does planting a new file in a skill directory. Installing one from inside a session is refused too. That is not new behaviour so much as newly consistent: `nav-pilot install --user` already failed inside cplt when it reached `~/.copilot/hooks/`, and nav-pilot turns that EPERM into an error naming cplt and telling you to run the install from a shell outside it. With `skills/` denied, the same install fails one artifact earlier, and nav-pilot's explanation currently covers only the hook copy — a bare `permission denied` on the skill. Worth a follow-up on the nav-pilot side; it does not change what the sandbox should do. `instructions/` keeps the dir-wide write grant: it is prompt content in the sense `skills/` is not. `agents/` is not prompt content, see below.

**On Linux most of these are nominal.** The bubblewrap overlay cannot bind a path that does not exist, and in a fresh install `hooks/`, `settings.json`, `lsp-config.json` and `extensions/` do not — they appear only when you first run `/settings`, `/lsp`, or install an extension. `pkg/` is the one that reliably exists, because the CLI creates it. `mcp-config.json` exists only once you have added a server. `skills/` exists as soon as anything has been installed, which is the state any host that cares about this deny is in, so it lands with `pkg/` on the reliable side rather than with `extensions/` on the nominal one. This is the same "must already exist" caveat as `.git/hooks` and Pi's `extensions/`, and it means the Linux posture for Copilot today is close to "the native modules and the installed skills are protected, the rest is protected once you have used the feature". macOS enforces all ten unconditionally (eight when the key is on), and without bubblewrap Linux enforces none of them.

**`installed-plugins/` is denied, and its cost is genuinely unknown. Read this before assuming either way.**

A plugin ships its own `hooks.json`, `.mcp.json` and `lsp.json` — the same three execution routes the six entries above close. Leaving it writable denied the front door and left the side door, so it is denied.

Against that, GitHub documents first-party plugins as updating themselves at the start of every session in a trusted working directory, and this deny stops a write that would need. **Whether it stops anything that would otherwise happen inside cplt could not be determined**, and the reason is worth recording so nobody repeats the work:

- `COPILOT_AUTO_UPDATE=false` and `--no-auto-update` are the same boolean in Copilot's shipped SEA bootstrap, and cplt already passes the flag on every Copilot run (`Agent::extra_args`). Setting the environment variable as well would add nothing — a control that reads as a mitigation and is not one.
- That bootstrap is the *binary self-update* path. The code that would show whether the same flag also covers session-start *plugin* updates is not in the published package: in `@github/copilot-darwin-arm64@1.0.83` (139 MB), `COPILOT_AUTO_UPDATE` occurs once and `installed-plugins`, `mcp-config.json`, `lsp-config.json`, `session-store.db`, `permissions-config.json`, `trustedFolders` and `hooks.json` occur zero times. The application is fetched into `pkg/` on first run, so the behaviour is not readable from any shipped artifact.

So one of two things is true. **If `--no-auto-update` already covers plugin updates, this deny costs nothing** — plugins never self-update inside cplt in the first place. **If it does not, plugin auto-update fails inside the sandbox**, and a plugin has to be updated outside cplt, like every other denied path here.

**What would settle it:** one `cplt --agent copilot` session on a host with Copilot and a first-party plugin installed, watching whether anything under `~/.copilot/installed-plugins/` is touched at startup. If nothing is, replace this section with a line saying the deny is free. If something is, the cost is real and belongs in the "do it outside cplt" list above.

`instructions/` stays writable: it is prompt content and names no script for a later run. `skills/` and `agents/` used to be on that list on the same reasoning, and for both that reasoning was wrong.

**`agents/`, `permissions-config.json` and `trustedFolders` ([#906](https://github.com/navikt/cplt/issues/906)).** Checked against Copilot CLI 1.0.104 on macOS:

- A custom agent in `~/.copilot/agents/*.agent.md` can declare `mcp-servers` with a local `command`. That command runs when the agent is selected (`--agent <name>`, or an interactive pick), before the first model request. So a planted agent is a host command that waits for a later session to select it. Whether the model can select an agent by itself was not tested.
- `permissions-config.json` holds saved tool approvals. A `commands` entry with a `:*` prefix, or a `write` entry, lets later host sessions in that location run those tools without asking.
- `config.json` holds `trustedFolders`. A hand-added entry skips the "Confirm folder trust" prompt. Copilot replaces the file by rename, using `config.json.trusted-folders.lock`, so a read-only file mode does not stop it.

New configs (`cplt config init`) set `sandbox.allow_copilot_host_persistence = false`, which write-denies `agents/` and `permissions-config.json` as paths: create, rename and unlink all fail. Saving a tool approval inside cplt then fails for that session; add custom agents and save approvals from a host shell. A config without the key keeps both writable, as before, and `cplt doctor` suggests setting it.

`config.json` stays writable with either value. Copilot writes `firstLaunchAt`, UI flags (`appTipShown`, `reasoningSummariesCleanupDone`) and possibly login state there in a normal session, and whether login survives a denied file could not be tested. Instead, with the key off, cplt reads `trustedFolders` before and after the session and warns about each folder the session added, naming the file to remove it from. That reports the change after the session; it does not prevent it.

The project-level `.github/agents/` stays writable, matching Claude Code's project `.claude/agents/` ([#366](https://github.com/navikt/cplt/issues/366)). It is repository content that shows up in `git status` and review, unlike a file under `$HOME`. Note that its `mcp-servers` command runs before the folder-trust prompt is answered, so trust does not gate it.

On Linux the deny uses the same bubblewrap overlay as the rest of this list, so it holds only with `bwrap` and only for paths that already exist. `agents/` and `permissions-config.json` often do not exist in a fresh install, and then Linux does not enforce the deny. The `trustedFolders` check works the same on both platforms.

On Linux, with the key off and bubblewrap wrapping the run, cplt creates an empty `~/.copilot/agents` before launch so the read-only bind holds on a fresh install. It does not create `permissions-config.json`, because an empty file is not valid JSON, so that deny stays nominal until Copilot first writes the file.

The `~/.copilot` directory itself is pinned against rename and unlink on macOS ([#923](https://github.com/navikt/cplt/pull/923)), for every config. Without the pin, `mv ~/.copilot <project>/.x && ln -s <project>/.x ~/.copilot` moved every file out from under the denies, which name `~/.copilot/...`. Every agent's writable config root that carries host-persistence denies gets the same pin (`~/.claude`, `~/.gemini/config`, and so on).

**Residual: `COPILOT_HOME`.** All of these denies name `~/.copilot`. If `COPILOT_HOME` points the host's Copilot at another directory, cplt does not deny anything there, and that directory is protected only if no sandbox grant reaches it.

**Residual: a relocated config root inside a writable tree.** When `DSH_HOME` or `CLAUDE_CONFIG_DIR` points into the project, the project's own grant already lets the agent write and rename there, so the config root's pin does not apply and the host-persistence denies are the only guard left.

**Every writable root is pinned against rename (macOS, [#923](https://github.com/navikt/cplt/pull/923)).** The same move-and-symlink trick works on any writable root that holds a deny: the project and every `--repo-dir` or `allow.write` root (`.git/hooks`, `.cplt.toml`, `.github/hooks`, and so on), and the home tool dirs `~/Library/Caches`, `~/.cache`, `~/.m2`, `~/.gradle`, `~/.nuget` and `~/.konan`. The denied paths sit directly under the root, so there is no smaller directory to pin, and each root gets `(deny file-write-unlink (literal <root>))`. Only the root's own name is fixed. Everything inside it can still be written, renamed and deleted, and `git checkout`, `git gc` and `git worktree add` work as before. The cost is that the agent cannot `mv` or `rmdir` a granted root. mise's data dir is not pinned, because `mise implode` removes it, so its `shims/` and `installs/` denies can still be escaped this way. A tool dir relocated by an environment variable (`GRADLE_USER_HOME`, for example) is not pinned either.

**Shell (`--agent shell`, and `cplt exec`, which reuses the same policy).** For a fish session cplt grants write to `$__fish_config_dir` (`~/.config/fish`) and the data dir (`~/.local/share/fish`). Both are needed: fish rewrites `fish_variables` by creating a temp file in the config directory and renaming over the target, so `set -U` fails without directory write, and `fish_history` lives in the data dir. Sourcing config does **not** need write — an earlier comment in `agent.rs` said it did, and that was the only stated reason the config directory was writable at all.

Seven paths in those two directories run code on the next host shell and are write-denied. `config.fish` and `conf.d/*.fish` are sourced at every startup. `functions/*.fish` autoload when a command of that name is invoked, so a planted `git.fish` shadows `git`. `completions/*.fish` are sourced on tab-completion. Three more live in the data dir, which previously carried write with no guard at all: `vendor_conf.d/` is **sourced at every startup and is first in `$__fish_vendor_confdirs`**, needing no invocation, no tab-completion and no universal variable — the strongest of the set; `vendor_functions.d/` and `vendor_completions.d/` are on `$fish_function_path` / `$fish_complete_path` by default. fish writes none of the seven: with the config dir read-only, `fish -c` and `fish -i -c` both start clean and only `set -U` fails. The cost is `funcsave`, `fish_config`, and plugin managers that install functions — do those outside cplt.

**On Linux most of these denies are nominal in a fresh install.** The bubblewrap overlay cannot bind a path that does not exist, and `conf.d/`, `functions/` and `completions/` are created by fish on first run while the three `vendor_*` directories are created by whatever package installs into them — commonly never. `config.fish` is the one that reliably exists. This is the same "must already exist" caveat as `.git/hooks` and Pi's `extensions/`, stated here rather than left for the general bullet to cover by analogy.

**Residual: `fish_variables` stays writable, and it is a complete bypass of the six denies above.** Universal variables are an execution vector on their own — `set -U fish_user_paths /some/writable/dir` prepends that directory to `PATH` for every subsequent fish shell, so the next `git`, `ls` or `sudo` resolves to an attacker's binary, with no config file touched. Demonstrated end to end: `set -U fish_user_paths <dir>` in one sandboxed shell, then a plain `fish -c whoami` on the host running the planted script. It is left open because denying it means denying every `set -U`, and the config directory is granted write for that and nothing else. If you want it closed for a particular deployment, `--deny-path ~/.config/fish/fish_variables` does it, at the cost of universal variables inside the sandbox. A second, smaller residual: `~/.cache/fish/generated_completions` is on `$fish_complete_path` and sits in the writable `~/.cache` tool dir, but fish generates it itself, so a deny would break a legitimate write; it only fires on tab-completion in an interactive shell.

For a zsh session only `~/.local/share/zsh` is granted and none of the six entries exist there, so the guard is inert — zsh's own startup files (`~/.zshrc`, `~/.zshenv`) are not granted write in the first place.

**Antigravity.** Keeps the Keychain grant unless `~/.gemini/antigravity-cli/antigravity-oauth-token` already exists — that file is `agy`'s *keyring fallback*, not a mirror, so its presence is the only safe signal that the agent can authenticate without the grant (#242). See [Keychain access is all-or-nothing](#keychain-access-is-all-or-nothing). Its two grants carry their own auto-executing config, so the host-persistence guard applies: `~/.gemini/config/hooks.json` names host commands, `~/.gemini/config/mcp_config.json` holds `mcpServers` that auto-start, and `~/.gemini/antigravity-cli/bin/` holds binaries (`agentapi`, `webm_encoder`) Antigravity runs on the host. All three are write-denied. Note that Antigravity is granted `~/.gemini/config` and `~/.gemini/antigravity-cli`, not `~/.gemini` itself, so Gemini's own user-level `settings.json` is not writable through an Antigravity session.

**Pi.** Not auto-detected: the `pi` binary name is generic and may collide with other tools, so select it explicitly with `--agent pi` or `sandbox.agent = "pi"`. `~/.pi/agent/` holds settings, auth, sessions, and themes.

The **root is granted read-only**, and write is granted per subdirectory: `sessions/`, `prompts/`, `themes/`, `tools/` and `tmp/`, plus file-level write on the top-level files Pi rewrites in place (`auth.json`, `oauth.json`, `models.json`, `models-store.json`, `keybindings.json`, `pi-debug.log`). It used to be one write grant over the whole tree, and that is what made the managed binary dir `~/.pi/agent/bin/` (bundled `fd`, `rg`, which has process-exec) writable **and** executable on Linux: Landlock unions a path with every ancestor rule and has no deny form, so the parent's write reached the exec-only child, and an agent that overwrote `rg` there owned the user's next unsandboxed `pi`. macOS emitted — and still emits — an explicit `(deny file-write*)` for `bin/` at the tail of the profile; Landlock has no such rule, so the grant is narrowed instead, the shape `HOME_TOOL_DIRS` already uses for `~/.cargo/bin` against `~/.cargo/registry`, and the only form that holds on a host without bubblewrap. The writable set is Pi's own `~/.pi/agent/*` surface, read off `@earendil-works/pi-coding-agent` 0.85.1 (`dist/config.js`, `dist/core/resource-loader.js`).

The cost of the narrowing is that Pi can no longer create a **new** top-level entry under `~/.pi/agent` from inside cplt: a first-ever `pi auth login` (which creates `auth.json`) and the managed-binary bootstrap (Pi downloads `fd`/`rg` into `bin/` when they are not on `PATH`) have to happen outside cplt. A file-level grant only matches a file that already exists, because both backends resolve the path when the rule is built.

Startup locks are the exception: `trust.json.lock/`, `auth.json.lock/` and `settings.json.lock/` may be created, timestamped and removed. Pi 1.1.0 needs the latter two when reading settings and refreshing auth availability. On macOS these grants match only the named directories, permit no files inside them, and leave `settings.json`, `trust.json` and `bin/` write-denied. On Linux the existing directory-creation grant requires bubblewrap to prevent sibling renames. If bubblewrap is unavailable or disabled during preparation, the root stays read-only and `cplt doctor` reports the blocker. Existing gap: if bubblewrap passes preparation but fails at launch, fallback to plain Landlock retains directory-creation and removal rights without the mountpoint protection. Those rights permit replacing `bin/` with a writable sibling, planting code for a later unsandboxed Pi run.

`~/.pi/agent/extensions/`, `settings.json`, `trust.json`, `npm/`, `git/` and `skills/` are write-denied by the host-persistence guard, and read-only by construction now that the root is. Pi auto-discovers `~/.pi/agent/extensions/*.ts` and `*/index.ts` and loads them at startup without confirmation, since the project-trust gate covers only project-local `.pi/extensions`, and Pi's own documentation states that extensions run with the user's full system permissions and can execute arbitrary code. `settings.json` in the same directory is denied for the same reason: its `extensions` key loads code from arbitrary file paths and its `packages` key from npm or git, so denying the `extensions/` directory alone would not close the vector. `trust.json` is the project trust store: `ProjectTrustStore` records a bare decision keyed on the normalized project path with **no fingerprint** of what is being trusted, so writing it pre-trusts a directory — and trust is the gate on the project-local auto-load paths, `.pi/extensions` and `.pi/settings.json`'s `packages`. `npm/` and `git/` are denied because that is where `pi install` puts the code: without them, denying `settings.json` would stop a *new* `packages` entry being added while leaving an already-installed package editable in place, and it loads on the next host run. A file written to any of these would execute unsandboxed the next time `pi` runs on the host. `skills/` was deliberately writable until [navikt/copilot#858](https://github.com/navikt/copilot/issues/858) and is not any more: a skill is what Pi's next session is offered and it names the scripts that session runs. It lost its write grant as well as gaining the deny — the same narrowing `bin/` got, and for the same reason, so that a Linux host without bubblewrap still holds it read-only. The cost is in-sandbox package management, `/trust`, editing or installing a skill, plus every setting that persists to `settings.json` — `/model` (Ctrl+S), `/thinking`, `/settings`. Do those outside cplt. Auth is unaffected once `auth.json` exists: Pi has no interactive login by default and reads provider API keys from the environment.

**Claude Code.** Not auto-detected either; select it with `--agent claude` (aliases `cc`, `claude-code`) or `sandbox.agent = "claude"`.

- **Subscription auth works out of the box.** The OAuth token lives in `~/.claude/.credentials.json` (Linux) or the macOS login Keychain ("Claude Code-credentials"). Both are exposed to the sandbox, so the subscription flow needs no env var. On macOS the Keychain grant is dropped when `CLAUDE_CODE_OAUTH_TOKEN` is exported (see [Keychain access is all-or-nothing](#keychain-access-is-all-or-nothing)). That hands the sandboxed agent its own credentials, an inherent trade-off, the same one Copilot's Keychain access makes. Because subscription OAuth needs no env var, cplt does not emit the "needs auth" warning for Claude Code.
- **Config dirs are read/write.** `~/.claude/` (sessions, projects, history, settings, credentials) and the top-level `~/.claude.json`.
- **Host-persistence guard.** Inside that writable config dir, `statusline.sh`, `plugins/` and `settings.json` are explicitly write-denied. All three auto-execute the next time `claude` runs *outside* the sandbox, so a compromised agent could otherwise plant code that escapes via the next launch. `settings.json` was previously left writable on the grounds that it needs explicit user invocation; that was wrong — its `hooks` key auto-fires on `SessionStart`, `UserPromptSubmit` and other events, so it is now denied. `commands/`, `agents/` and `skills/` stay writable, and the reason previously given for that — that they run only when the user invokes them — was wrong. All three are **model-invocable**, and all three reach a host shell. Probed against Claude Code 2.1.261 in a scratch `CLAUDE_CONFIG_DIR`: a `skills/<name>/SKILL.md` and a `commands/<name>.md` are both listed to the model as "available for use with the Skill tool" with the user never naming them, and invoking either runs the `` !`cmd` `` shell preprocessing in its body; an `agents/<name>.md` accepts a `hooks:` block in its frontmatter, and its `Stop` hook ran a host command when the model spawned the agent. The invocations in that probe were forged from a stub API server, so what is established is that the CLI executes them on the model's word — not that a live model picked the planted file, which was not tested. The per-file `disable-model-invocation: true` key does block the first two (verified: the call is refused and the shell does not run), but it is **absent by default** — upstream's own wording, in the shipped binary, is "Both the user (`/<skill-name>`) and Claude can invoke skills by default" — so anything the agent writes is model-invocable unless the agent opts out, which a hostile one will not. What separates these three from `statusline.sh`, `plugins/` and `settings.json` is therefore not user invocation; it is only that the model has to select them rather than them firing at launch, and a description written to match ordinary prompts closes most of that gap. One thing still stands between a planted file and execution: the preprocessing goes through the normal Bash permission check. It was denied under default `-p` permissions and ran once Bash was allowed, so the vector lands on sessions with a Bash allowlist, `--dangerously-skip-permissions`, or auto mode, and prompts in a default interactive one.

  They are left writable anyway, and the trade is the same shape as the `mcpServers` one below. Authoring a skill, a command or a subagent is most of the reason those directories exist, and a path-granularity sandbox can only deny the whole directory: `disable-model-invocation` is a frontmatter key, and neither Seatbelt nor Landlock has per-key policy. For a deployment that wants them closed, `--deny-path ~/.claude/skills` (likewise `commands`, `agents`) does it, at the cost of in-session authoring. The default stays writable: [#366](https://github.com/navikt/cplt/issues/366) closed with this recorded as a residual, and no open issue tracks changing it. Enforcement follows the platform limits above: full on macOS, bubblewrap-only on Linux. These denies also moved to the tail of the profile, which fixed a pre-existing hole — `allow.write = ["~/.claude"]` used to reopen `statusline.sh` and `plugins/`. The residual `mcpServers` risk in `~/.claude.json` is left open on **both** platforms, and deliberately. It is not a limit of either backend: `~/.claude.json` is its own `AgentDir`, so macOS would deny it with one more tail entry and Landlock would enforce `write: false` on it unaided — it is the one host-persistence entry that needs no bubblewrap overlay. The obstacle is granularity. `mcpServers` and the per-project `projects.<path>.mcpServers` are keys inside a file Claude Code rewrites throughout a session, alongside `numStartups`, `tipsHistory` and each project's `lastCost` and `hasTrustDialogAccepted`. Denying writes to the file would genuinely stop the agent planting an MCP server, and would also stop the trust dialog, onboarding state and session accounting from ever persisting — the CLI catches the write failure, so nothing crashes, it just re-asks every launch. That cost is why the deny is not there, on macOS exactly as much as on Linux. Closing the gap without paying it needs a mechanism cplt does not have: per-key policy, or materialising the config into a session-scoped `CLAUDE_CONFIG_DIR` at launch ([#333](https://github.com/navikt/cplt/issues/333)). Treat write access to a relocated `CLAUDE_CONFIG_DIR` the same way.
- **`CLAUDE_CONFIG_DIR` is supported.** It sits on the env allowlist, and when set, `Agent::Claude.config_dirs()` grants that directory in place of `~/.claude`. Both halves are required. Granting the path without passing the variable, or the reverse, breaks auth and config inside the sandbox.
- **Auto-update disabled.** cplt injects `DISABLE_AUTOUPDATER=1`. Claude Code has no `--no-auto-update` flag, and a self-update inside the sandbox is a persistence vector that would also fail against read-only install paths.

**goose.** Not auto-detected; select it with `--agent goose` or `sandbox.agent = "goose"`. Verified against goose 1.48.0.

- **Provider-agnostic, so no domain defaults.** goose routes model traffic to whichever provider you configure, and an `--observe-domains` capture (1.48.0, 2026-09-03) showed it contacting no goose-owned host of its own. Its built-in allowlist is therefore the shared package-registry base and nothing else; add your provider's domain via `allowed_domains`. See [docs/proxy.md](docs/proxy.md#default-allowlist-fail-closed-networking) for the two hosts that were seen and deliberately excluded.
- **XDG dirs on macOS too.** goose uses `~/.config/goose`, `~/.local/share/goose` and `~/.local/state/goose` on both platforms — not `~/Library/Application Support` — and honours the `XDG_*` overrides on macOS. It creates no cache dir, so none is granted.
- **Config dir is read-only, on purpose.** `config.yaml` declares `extensions:` entries carrying a `cmd` and `args` that goose spawns as subprocesses on every session start. A writable config dir would let a sandboxed agent append an extension that runs **unsandboxed** the next time the user launches goose, the same class as `.git/hooks` and Claude Code's `plugins/`. There is no `write_files` carve-out either: goose rewrites `config.yaml`, `permission.yaml` and `permissions/tool_permissions.json` by creating a temp file in the directory and renaming over the target, which needs directory write and would hand the vector straight back. The cost is that `/mode` and theme changes, the first-run telemetry prompt, and persisted "always allow" tool permissions do not survive a sandboxed session. That last one is a feature: a sandboxed agent should not be able to grant itself standing tool approval for the user's future unsandboxed runs. A full `goose run` against an existing `config.yaml` left it byte-identical, so ordinary use is unaffected.
- **Keychain access is granted, and it is avoidable.** goose stores provider secrets in the OS keyring by default (macOS login Keychain; D-Bus Secret Service on Linux, so the grant is macOS-only in effect) under service `goose`, account `secrets` — a single entry holding every secret. cplt grants the whole of `~/Library/Keychains`, which is broader than that one entry, so a sandboxed goose can reach other Keychain items too (issue #242). Unlike Copilot or Claude Code, goose does not need it: run with `GOOSE_DISABLE_KEYRING=1` and goose falls back to a `secrets.yaml` in its config dir, or pass the provider key with `--pass-env` and skip stored secrets entirely. Prefer either over the Keychain grant.
- **Plugin manifests are covered.** goose auto-spawns MCP servers declared in plugin manifests under `~/.agents/plugins/` and `<project>/.agents/plugins/`. The first is outside every granted directory and unreachable in the sandbox. The second sits in the writable project tree and is the same in-repo persistence class as `.git/hooks`, so it is denied for every writable root, after the user allows so no `allow.write` reopens it. The rest of `.agents/` stays writable: nothing there auto-executes.

**DeepSeek Harness.** Not auto-detected; select it with `--agent dsh` (aliases `deepseek`, `deepseek-harness`) or `sandbox.agent = "dsh"`. Upstream ships it as a developer preview.

- **Its own sandbox does not nest, and does not need to.** DSH runs every shell and file tool call through its own process sandbox: Seatbelt on macOS, bwrap or Landlock on Linux. macOS does not support nested `sandbox-exec` calls, and bwrap's namespace needs `unshare`, which cplt's seccomp filter denies with `EPERM` — the same two walls Gradle's daemon sandbox and Chromium's own sandbox hit inside cplt. Under cplt the enforcing boundary is cplt's profile, so the inner runner is redundant: select DSH's shipped `danger-full-access` permission preset. Left on, it surfaces as a sandbox runner failure on tool calls, which DSH deliberately reports as infrastructure failure rather than a failed command.
- **One writable home root.** `$DSH_HOME` (`~/.dsh` by default) holds sessions, settings, cache and the profile store, and is granted read/write so a session persists mid-run. `DSH_HOME` is on the env allowlist so the child resolves the root cplt granted; granting one and passing the other would leave DSH writing outside the sandbox's writable set with nothing naming the cause. A value resolving to a system root or `$HOME` is refused by `first_unsafe_agent_dir` before launch.
- **Host-persistence guard, with a stated residual.** `$DSH_HOME/cordis.patch.yml` is write-denied: the Loader reads it at boot via `loadOptionalPatches` and never writes it, so denying it closes that layer at no cost. `profiles/` cannot be denied the same way — DSH rewrites each profile's constant `cordis.yml` include-root on every boot — so a per-profile `cordis.patch.yml` and anything `dsh plugin` installed stay agent-writable. That is a residual, not a closed vector: do profile and plugin edits outside cplt, and launch `dsh` through cplt so planted code still runs sandboxed.
- **Auth needs no Keychain.** The key comes from `DEEPSEEK_API_KEY` via `--pass-env` or from `$DSH_HOME/.env`; a key saved through DSH's models UI lands in `$DSH_HOME/.credentials.yaml`, inside the same writable root. `DEEPSEEK_BASE_URL` is a route, not a credential, and is deliberately absent from the auth hints so it cannot suppress the missing-key warning or be offered in place of the key.

**Copilot's own command sandbox does not nest.** Copilot CLI sandboxes shell commands itself since 1.0.83. On Linux that sandbox builds a network namespace, which needs `slirp4netns`, `iptables`/`ip6tables` and `/dev/net/tun`, and cplt's seccomp filter denies the `unshare` and `setns` it takes with `EPERM` — the same wall Chromium's sandbox, the Gradle daemon and DSH's inner runner hit. cplt also sets `HTTP_PROXY`/`HTTPS_PROXY` for the child, and 1.0.83 restricts a Linux sandbox's egress to the configured proxy, so Copilot takes the namespace path whether or not the user asked for it. cplt therefore sets `COPILOT_CLI_SANDBOX_SUPPORT_OVERRIDE=unsupported`, Copilot's own opt-out: it stands down for the session, prints its own notice saying so, and leaves `sandbox.enabled` in the user's `settings.json` untouched. **cplt is then the only boundary** — the same statement the Playwright and DSH entries make, and here the alternative is not two boundaries but a launch that never starts. `--pass-env COPILOT_CLI_SANDBOX_SUPPORT_OVERRIDE` returns the choice to the caller. Not covered: an enterprise managed policy that requires the sandbox floors it on regardless, including when the policy could not be read at all, and no environment variable lifts that floor. See [docs/known-impacts.md](docs/known-impacts.md#copilot-clis-own-command-sandbox-1083).

**Copilot's project-directory hook path.** `.github/hooks/*.json` is a documented Copilot CLI hook load path, and it sits in the project directory the sandbox makes writable by definition. A hook written there runs on the next **unsandboxed** Copilot session in that repository — the same class as `.git/hooks`, and worse in three ways: it needs no grant at all, `.github/` is a directory people commit to routinely so a new file there is less conspicuous than one under `.git/`, and it survives being committed and pushed, so it can reach other people's checkouts. It is denied for every writable root and, since it fires for whoever next opens *that* repo, in repositories nested beneath one. Only `hooks/` is denied: workflows, instruction files and agent prompts under `.github/` are ordinary repo content, and CI execution is a different trust boundary.

**Concealment, not just execution.** `.git/info/exclude` is a local, uncommitted gitignore. Nothing in it executes, but every path it names disappears from `git status` — for the user and for any tooling that shells out to git — and `git status` is the review step people actually perform. An agent that plants a file and then hides it has defeated the check every other protection here assumes. It composes with the path above: a hook in the working tree, hidden from `git status`, is one the user never sees appear. Nothing legitimate writes the file from inside a session (git creates it once from the template at `git init`), so the deny is free. `.gitignore` in the working tree is deliberately not protected — it is committed, so it shows up in a diff. The other route to the same concealment, `core.excludesFile` and its default `~/.config/git/ignore`, runs through paths already denied: `<gitdir>/config`, and the user-level `~/.gitconfig` / `~/.gitconfig.local` / `~/.config/git/config` / `~/.config/git/ignore`, which are read-only exceptions in a home that is write-denied by default. That holds while those files live in `$HOME`. When they are dotfiles links into a writable tree, it holds only within the limits under [Git configuration](#layer-0-environment-variable-sanitization): not on Linux without Bubblewrap, and not where cplt could not create a missing target on Linux.

**Legacy remote files.** git still resolves a remote name through `.git/remotes/<name>` and `.git/branches/<name>` when `.git/config` does not define it. A file planted there defines a remote with a URL the agent chose, without writing the denied `.git/config`, and git on the host picks it up after the session ([#743](https://github.com/navikt/cplt/issues/743)). On macOS both directories are write-denied in every gitdir, nested ones included. Nothing current writes them, so the deny is free. On Linux with Bubblewrap, an existing directory is re-bound read-only (`--ro-bind`) and a missing one inside an existing gitdir is shadowed with an empty read-only tmpfs (`--tmpfs <dir> --remount-ro <dir>`, [#747](https://github.com/navikt/cplt/issues/747)), so `mkdir` fails with `EEXIST` and creating files inside fails with `EROFS`. Landlock-only hosts leave them writable.

## Threat model

cplt assumes the sandboxed agent is **untrusted**, because it executes arbitrary code suggestions on your machine. The threat model covers:

| Threat | Example | Defense layer |
|---|---|---|
| **Credential theft** | Read `~/.ssh/id_ed25519`, `~/.aws/credentials` | Seatbelt deny rules (macOS) / Landlock deny (Linux) |
| **Data exfiltration** | POST secrets to `https://evil.com/collect` | Filesystem isolation (credentials unreadable) |
| **Secret file access** | Read `~/.netrc`, `~/.npmrc`, `~/.vault-token` | Seatbelt deny rules (macOS) / Landlock deny (Linux) |
| **Destructive GitHub ops** | `gh repo delete`, `gh pr merge`, `gh release create` | gh guard command interception (on by default) |
| **Unreviewed code push** | `git push origin main` | git guard command interception (on by default, `block` mode, default branch) |
| **Git alias push bypass** | `git -c alias.p=push p origin main` | git guard blocks `-c alias.*` and denies unknown subcommands |
| **Git subtree push bypass** | `git subtree push --prefix=lib origin main` | `subtree` in explicit block list, plus deny-unknown policy |
| **Multi-refspec bypass** | `git push origin feature main` | git guard checks ALL refspecs, not just the first |
| **Token exfiltration via CLI** | `gh auth token` prints raw token | gh guard serves the cached token once at startup and deletes the file, so subprocesses get nothing from that channel. Not a boundary: `gh auth git-credential get` stays allowed so HTTPS push works, and it prints `password=<token>` for any agent that still has a token source. See [`block_auth_token` is best-effort](#honest-gaps) |
| **Cross-repo operations** | `gh pr close -R other-org/other-repo` | gh guard scope checking against current repo |
| **Org/user data enumeration** | `gh api /orgs/.../audit-log` leaks PII | gh guard restricts API to `/repos/{current-repo}/...` endpoints only. GraphQL queries must start at a repository in scope and may select only an allowlist of pull request and review-thread fields: see [GraphQL reads are allowlisted](#honest-gaps) |
| **GraphQL mutations** | `gh api graphql` running `mergePullRequest`, or resolving threads in another repository | gh guard parses the document and allows three review-thread mutations only after a lookup puts every target in a repository in scope ([gh-guard.md](docs/gh-guard.md#gh-api-graphql)) |
| **DNS rebinding SSRF** | Domain resolves to `127.0.0.1` after check | Post-DNS-resolution IP validation; `--allow-private-domain` opt-in bypass for explicitly trusted internal domains |
| **Sandbox profile injection** | Path with `\n(allow file-read* (subpath "/"))` | SBPL path character validation (macOS) |
| **Cross-session profile replacement** | Overwrite another session's SBPL profile in the shared temp dir before the kernel reads it | The profile is passed to `sandbox-exec -p` as an argument; it is never written to disk, so there is no file to swap |
| **Write-then-exec in /tmp** | Drop binary in `/tmp`, execute it | Seatbelt deny (macOS) / Landlock deny (Linux); `--scratch-dir` provides a safe alternative |
| **Cloud metadata access** | Fetch `169.254.169.254` or CGNAT range | Private IP blocklist covering all reserved ranges |
| **Cross-project access** | Read files outside project directory | Seatbelt subpath (macOS) / Landlock ruleset (Linux) |
| **Process-group escape** | Kill parent, children continue unsandboxed | Signal forwarding (SIGTERM, SIGHUP) |
| **Env var credential theft** | Read `AWS_SECRET_ACCESS_KEY` from env | `env_clear()` plus safe allowlist |
| **Persistence via native modules** | Replace `keytar.node` with malware | Seatbelt write-deny on `~/.copilot/pkg` and `~/Library/Caches/copilot/pkg` (macOS). **Landlock can express neither** — `~/.copilot` is granted write wholesale and the execute rule on `~/.cache/copilot/pkg` unions with the `~/.cache` write grant. Bubblewrap re-binds both read-only; **without bubblewrap this is unenforced on Linux** ([#328](https://github.com/navikt/cplt/issues/328)) |
| **Git hook injection** | Write post-checkout hook that runs outside sandbox | Seatbelt write-deny (macOS). **Landlock leaves project `.git/hooks` writable**, and env hardening does NOT stop a planted hook running unsandboxed on the next `git` run. Bubblewrap re-binds `.git/hooks` read-only, which mitigates the *direct* file-planting vector on Linux. **Residual:** `.git/config` stays writable, so `core.hooksPath` can still redirect hooks to a writable dir. See [Linux namespace isolation](#linux-namespace-isolation-bubblewrap) |
| **Git config hijacking** | Set `core.hooksPath=/tmp/evil` or URL redirect | Seatbelt write-deny (macOS). On Linux, Bubblewrap binds `.git/config` read-only when `sandbox.allow_git_config_write = false`, which new configs set (#386); without Bubblewrap that launch refuses. **A config without the key, or with `true`, leaves it writable on Linux.** The injected `GIT_CONFIG_*` overrides constrain config resolution for in-sandbox git runs, and the proxy blocks redirected fetches (Linux) |
| **Submodule supply chain** | Modify `.gitmodules` to point to malicious repo | Seatbelt write-deny (macOS). **Linux leaves `.gitmodules` writable**, deliberately, because `git submodule add` writes it; proxy domain filtering limits reachable clone targets (Linux) |
| **Syscall abuse** | `ptrace`, `mount`, `kexec_load` | seccomp-BPF filter (Linux) |

### Platform enforcement comparison

| Protection | macOS (Seatbelt) | Linux (Landlock + seccomp) | Linux (+ Bubblewrap) |
|---|---|---|---|
| Credential files (~/.ssh, ~/.aws) | ✅ Kernel deny | ✅ Not in ruleset (deny-by-default) | ✅ Landlock (deny-by-default) |
| Project .env file read/write/delete | ✅ Kernel deny | ⚠️ Proxy blocks exfiltration | ⚠️ Proxy blocks exfiltration |
| .git/hooks write in project | ✅ Kernel deny | ❌ Writable (Landlock can't sub-deny; env hardening does NOT block hook planting) | ⚠️ Re-bound read-only (blocks direct file planting; `core.hooksPath` via writable `.git/config` is a residual) |
| .git/config write in project | ✅ Kernel deny | ❌ Writable (env hardening constrains in-sandbox config resolution only) | ✅ Re-bound read-only with `sandbox.allow_git_config_write = false` (new configs); writable when unset or `true`. Only files that exist at launch; nested repos by a bounded scan |
| .gitmodules write in project | ✅ Kernel deny | ❌ Writable (Landlock can't sub-deny) | ❌ Deliberately writable (`git submodule add` writes it) |
| .cplt.toml write in project | ✅ Kernel deny | ❌ Writable (Landlock can't sub-deny) | ✅ Re-bound read-only if present |
| .github/hooks write in project | ✅ Kernel deny | ❌ Writable (Landlock can't sub-deny) | ✅ Re-bound read-only if present |
| .git/info/exclude write in project | ✅ Kernel deny | ❌ Writable (Landlock can't sub-deny) | ✅ Re-bound read-only if present |
| .git/remotes, .git/branches write in project | ✅ Kernel deny | ❌ Writable (Landlock can't sub-deny) | ✅ Re-bound read-only if present, read-only empty tmpfs if absent at launch |
| Network: outbound port filtering | ✅ Kernel (all versions) | ✅ Kernel (6.7+) / ⚠️ Proxy only (<6.7) | ✅ Same as Landlock (no net namespace) |
| Network: localhost isolation | ✅ Kernel deny | ⚠️ Proxy domain filtering | ⚠️ Proxy domain filtering (no net namespace) |
| Network: force all egress through proxy (`proxy.forced`, opt-in) | ✅ Kernel pins TCP to `localhost:<proxy_port>`; system-resolver DNS stays open unless `proxy.deny_dns` (see [Honest gaps](#honest-gaps)) | ⚠️ Kernel blocks direct `:443`; port-based residual `evil.com:<proxy_port>` until [#114](https://github.com/navikt/cplt/issues/114) | ⚠️ Same as Landlock (no net namespace) |
| Exec from /tmp | ✅ Kernel deny | ✅ Landlock deny | ✅ Landlock deny |
| Dangerous syscalls | N/A (Seatbelt covers) | ✅ seccomp-BPF | ✅ seccomp-BPF |
| PID namespace isolation | N/A (not applicable) | ❌ Not available | ✅ Kernel namespace |
| Mount namespace isolation | N/A (not applicable) | ❌ Not available | ✅ Kernel namespace |
| User namespace (unprivileged) | N/A (not applicable) | ❌ Not available | ✅ Kernel namespace |
| --deny-path / deny.paths | ✅ Kernel deny | ❌ No effect (warned) | ✅ Mount-masked (files read as EACCES, dirs appear empty; the real content is unreachable) |
| Metadata of a denied file (`stat`, `access`) | ✅ Denied with the read | ❌ Not mediated: exists and reports readable, then `open` fails with EACCES | ⚠️ Masked paths (`deny.paths`/`--deny-path`, credential-dir masks): mode-000 placeholder — `stat` sees an empty, unreadable file and `access(R_OK)` correctly fails. Everything else: same as Landlock |

Legend: ✅ = kernel-enforced, ⚠️ = defense-in-depth (proxy/env), ❌ = not available

**Landlock does not mediate metadata.** Its access rights cover opening, reading, writing, executing and directory changes. There is no right for `stat(2)`, `access(2)` or `faccessat(2)`. On Linux, a file the sandbox denies still shows up as present, and `access(path, R_OK)` returns success. The `open(2)` that follows then fails with `EACCES`. Seatbelt denies the metadata call along with the read, so on macOS the check fails too. On Linux the sandbox can see a denied file's existence, size and timestamps, but not its contents. The bigger effect is on programs that check a file and then use it: on Linux they are told the file is readable and then fail on the open, while on macOS they treat it as absent and carry on. cplt cannot fix this in general. The workaround is per tool: grant the file with `allow.read` if the tool needs it, or point the tool at a path that does not exist so the check and the open agree. cplt does the second for `~/.npmrc` via `NPM_CONFIG_USERCONFIG` ([#180](https://github.com/navikt/cplt/issues/180), [#389](https://github.com/navikt/cplt/issues/389)).

**Bubblewrap changes this only for paths it explicitly masks.** A `deny.paths`/`--deny-path` target, or a credential-directory entry masked under [Linux namespace isolation](#linux-namespace-isolation-bubblewrap), is not left as the Landlock-denied original — bwrap binds a real, empty, mode-000 file over it. `stat` therefore reports that placeholder (present, zero-length, unreadable by anyone), and `access(path, R_OK)` correctly fails on it instead of lying. Every other Landlock-denied path — anything simply outside an `allow.*` grant, like `~/.npmrc` — is untouched by Bubblewrap and behaves exactly as the Landlock-only column.

### Linux namespace isolation (Bubblewrap)

On Linux, cplt can optionally layer **Bubblewrap** (`bwrap`) on top of Landlock + seccomp-BPF. Bubblewrap is what Flatpak uses, and it gives us battle-tested unprivileged namespace setup. It is defense-in-depth for the Landlock/seccomp layer, not a replacement for it. Landlock (filesystem and network access control) and seccomp (syscall filtering) remain the enforcing boundary; bwrap adds process, IPC, and hostname isolation plus a private `/tmp` around them.

**What bwrap adds:**

1. **PID namespace.** The agent cannot see or signal host processes. `ps` shows only the agent's own process tree, which stops process enumeration.
2. **IPC / UTS / cgroup namespaces.** No shared SysV IPC, an isolated hostname, an isolated cgroup view.
3. **Mount namespace.** The whole host filesystem is bind-mounted **read-only** (`--ro-bind / /`); write access is granted only at the specific paths carrying a writable Landlock rule, re-bound writable at their real locations. The host root is therefore still *enumerable* inside the namespace. The mount namespace only changes the mount topology, it does not hide arbitrary files. Confidentiality is Landlock's job (deny-by-default): a path with no read rule is denied by Landlock even though it appears in the mount table.
4. **Private `/tmp`.** `/tmp` is a fresh, empty `tmpfs` that carries no exec-bearing Landlock rule, so the "no exec from `/tmp`" guarantee holds. The scratch dir (write+exec) stays at its real path and is never overlaid on `/tmp`. A writable path that legitimately lives under `/tmp` (say a `--project-dir` in `/tmp`) is re-bound *after* the tmpfs so it stays usable.
5. **User namespace.** Unprivileged operation, no root required. The agent maps to the **invoking host UID**, there is no UID-0 mapping, and it holds no real capabilities on the host.
6. **Git-persistence read-only re-bind.** See below.

#### The git-persistence re-bind

The set of paths that must stay unwritable inside a writable tree is defined once, in `sandbox_policy.rs` (`PROTECTED_IN_ROOT` and `PROTECTED_IN_GITDIR`). Each entry states its own Linux coverage: `Bwrap` if the read-only overlay carries it, or `Gap(reason)` if Linux does not enforce it at all. Seatbelt turns the whole set into deny rules, bubblewrap re-binds the `Bwrap` subset read-only, and **Landlock enforces none of it** — it is additive, so a sub-path cannot be subtracted from an allowed writable tree. The backends choose the mechanism; they no longer each decide the list.

The project's `.git/hooks` and `.cplt.toml` live *inside* the writable project tree, and Landlock cannot carve a sub-deny out of it, so on the Landlock-only path they stay writable. That is a persistence-escape gap against macOS. When bwrap is active, those two pre-existing paths are re-bound **read-only** (`--ro-bind`, emitted after the writable project bind so it shadows it), so an agent can no longer plant a `.git/hooks/post-commit` that runs unsandboxed on the next `git` run, nor drop a `.cplt.toml` that relaxes the next session's sandbox. In a git **worktree** the project's `.git` is a gitdir *pointer file*, so `<project>/.git/hooks` does not exist and the real hooks live under the shared common dir that the sandbox grants write access to; `<git_common_dir>/hooks` is therefore re-bound read-only too, otherwise the worktree persistence vector would be missed.

The set is deliberately narrow. `.gitmodules` is left writable, because `git submodule add` writes it. `.git/config` is bound read-only when `sandbox.allow_git_config_write = false`, which `cplt config init` writes (#386); in-session `git config`, `git remote add` and `git push -u` tracking then fail, as on macOS. Git writes `.git/config.lock` and renames it over the file. The rename onto the bind fails with `EBUSY` (macOS reports `EPERM`), and git deletes the lock itself, so no stale lock is left. A config without the key keeps `.git/config` writable, as before, and `cplt doctor` suggests setting it. Without Bubblewrap the bind cannot exist, so a launch with the key `false` refuses instead of running unprotected. The same key binds a `.git` gitdir pointer file (so the agent cannot repoint a worktree or `--separate-git-dir` checkout) and every `config.worktree`. Limits: only files that exist at launch are bound, so a repository created in the session (`git init`, `git clone`) stays writable. Nested repositories are found by the same bounded scan as `.git/hooks`. A hard link to `.git/config` from the writable tree fails with `EXDEV`, because the bound file is its own mount; the integration test checks this. With `extensions.worktreeConfig` on, a `config.worktree` that does not exist at launch is masked with `--ro-bind /dev/null <path>` when `sandbox.mask_missing_deny_paths = true` (leaving an empty mountpoint file on the host); a `.git/config` that cplt cannot read safely (a symlink, a FIFO, over 64 KiB) counts as enabled, so the mask fails closed; with `mask_missing_deny_paths` off it is not bound, so the agent can create one. The `.git/worktrees/<name>` directories are rename-pinned so a worktree cannot be moved out from under its `config.worktree` bind.

Four residuals come with this. Where `.git/config` stays writable (key unset or `true`), an agent can still set `core.hooksPath` to redirect hooks into a writable directory, so the `.git/hooks` bind mitigates the *direct* file-planting vector only, not all git-hook persistence. A read-only bind protects only paths that *already exist* at launch, since bwrap cannot bind a nonexistent source, so a not-yet-created `.cplt.toml` can still be created. Submodule hooks (`.git/modules/<name>/hooks`) are not covered. And the whole mitigation requires bwrap; the Landlock-only path stays exposed.

The remote HEAD symref, `refs/remotes/<remote>/HEAD`, names the branch `protect_default_branch_only` protects (GHSA-cm6f-3wjh-x9qx), and its Linux coverage has two gaps ([#417](https://github.com/navikt/cplt/issues/417)). macOS denies it with a regex matched at syscall time, so every remote is covered, including one added mid-session. Bubblewrap binds paths, not patterns, so it lists `refs/remotes/` at launch and binds each `HEAD` file it finds there. Any remote whose `HEAD` file does not exist at launch has nothing to bind, so its symref stays writable for the whole run. That includes a remote added by `git remote add` and `git fetch` in the current session, and one added in an earlier session that never got a `HEAD` file. On a Landlock-only host there is no filesystem protection: Landlock cannot subtract a path from a writable tree, which is a kernel limit. Only the wrapped-git gate blocks apply there, and a direct file write bypasses them. In every case the default branch the git guard uses was captured at launch, so a rewrite does not change the current session's guard; a rewrite left on disk is what the next launch reads. There is no `packed-refs` gap: git never packs symbolic refs, so on the `files` backend the loose `HEAD` file exists whenever the symref does. The `reftable` backend is different, since the ref is not a file there and no path rule on either platform can see it. The git gate refuses `git remote set-head` and write-form `git symbolic-ref` in block mode, while push prevention is active, but the gate is a PATH shim: git invoked by absolute path, or a direct write to the tables under `.git/reftable/`, gets around it (see the PATH-shim limits under [Honest gaps](#honest-gaps)). Server-side branch protection is the boundary that holds in that case, as [docs/git-guard.md](docs/git-guard.md) says. Where the deny holds and a remote HEAD is missing, `git fetch` (2.48+) prints `error: couldn't set 'refs/remotes/origin/HEAD'` and still exits 0 with every tracking branch updated. Closing the Linux divergences that are not kernel limits is tracked in [#386](https://github.com/navikt/cplt/issues/386).

By default Bubblewrap does not create a network namespace (see the limitations below), so it is not a network or confidentiality boundary. `proxy.netns = true` (opt-in, [#114](https://github.com/navikt/cplt/issues/114)) adds one; see the first limitation.

**How Landlock and seccomp stay enforced (fail-closed):**

`bwrap` needs `unshare`/`mount`/`pivot_root` to build the namespaces, exactly the syscalls our seccomp filter `EPERM`s, and the bind-mount sources are what a restrictive Landlock domain would block. So Landlock and seccomp are **not** applied to the `bwrap` process. They are applied to the **agent**, inside the namespaces, after bwrap finishes setup:

```text
cplt ──exec──▶ bwrap (creates namespaces, unrestricted)
                 └─exec──▶ cplt re-entry helper (in-namespace)
                             │  applies Landlock + seccomp bound to the
                             │  inodes visible *inside* the namespaces
                             └─execve──▶ agent (Landlock + seccomp enforced)
```

The re-entry helper is this same cplt binary, dispatched by an `.init_array` constructor keyed on the `__CPLT_BWRAP_POLICY_FD` environment variable. The Landlock policy and agent argv arrive over an **inherited pipe**, so nothing is written to disk and the fresh `--tmpfs /tmp` cannot hide it. Because the helper opens its Landlock rule paths *inside* the namespaces, the effective policy is identical to the non-bwrap path. If any step of the helper fails it `_exit(126)`s **before** the agent runs, so the agent is never executed unsandboxed. A one-byte confirm pipe lets the parent detect that the inner sandbox was applied. On auto-detect, a missing confirmation degrades gracefully to the direct Landlock+seccomp path; explicit `--use-bubblewrap` treats it as a hard error.

**Activation:**

- **Auto-detect (default):** if `bwrap` is in PATH and can actually create the namespaces (probed by running the real `build_bwrap_args` output against `/bin/true`), cplt uses it. Otherwise it falls back to Landlock+seccomp.
- **Explicit enable:** `--use-bubblewrap` or `sandbox.use_bubblewrap = true`, which hard-fails if bwrap is unavailable rather than silently falling back.
- **Explicit disable:** `--no-bubblewrap` or `sandbox.use_bubblewrap = false`, which uses Landlock+seccomp only. If both are given, off wins.

**Graceful degradation:** Bubblewrap requires a kernel with unprivileged user namespaces enabled. Without bwrap or namespace support, cplt falls back to Landlock + seccomp-BPF, which still provides the full filesystem and syscall isolation. bwrap changes the process and mount topology, not the access-control policy.

**What bwrap does NOT provide:**

- **No network isolation by default.** Without `proxy.netns` there is no network namespace. The host network is shared, so the sandboxed agent can reach cplt's CONNECT proxy on `127.0.0.1`. Outbound control stays with Landlock TCP port rules (ABI v4+) and the proxy, exactly as on the non-bwrap path.
- **With `proxy.netns = true` (opt-in, [#114](https://github.com/navikt/cplt/issues/114)).** bwrap runs with `--unshare-net`, so the agent's network namespace holds only `lo`. A small relay inside it listens on `127.0.0.1:<proxy_port>` and passes each connection over a unix socket in the session's scratch dir to the proxy on the host, so `HTTPS_PROXY` keeps working. Every other address has no route: direct TCP to any host and port, the host's own loopback services, UDP and DNS all fail in the kernel, which closes the `evil.com:<proxy_port>` residual. Names are resolved by the proxy from the `CONNECT` request; a tool that calls `getaddrinfo` itself gets no answer. The relay is the agent's parent and its child subreaper, so it outlives an agent that double-forks and exits, and it exits once every process below it is gone. It is not dumpable, ignores the terminal's signals and runs under its own Landlock domain (no filesystem access except the socket's directory, no TCP connect) and the agent's seccomp filter. The agent can still kill it, which only cuts the agent's own network. If the namespace cannot be set up (no Bubblewrap, user namespaces off, proxy off, no scratch dir), cplt refuses to launch and names the fix; it never falls back to the shared network. `allow.localhost` and `allow_localhost_any` have no effect under it, and cplt warns when they are set. One exception: `AF_VSOCK` sockets are not scoped by a network namespace and seccomp does not deny them, so inside a VM guest the agent can still reach the hypervisor host over vsock. IPv4 loopback only; macOS ignores the key, since Seatbelt already pins egress to the proxy.
- **No filesystem confidentiality from the mount namespace.** The full host filesystem is enumerable read-only. Landlock, not the mount namespace, is what denies reads.
- **No UID remapping.** The host UID is visible inside the user namespace (an integration test asserts this). There is no root/UID-0 illusion.

**The layers, honestly attributed:**

- Filesystem: **Landlock** (deny-by-default) is the access control. The mount namespace only makes the host root read-only and provides a private `/tmp`.
- Network: **proxy** (domain filtering) plus **Landlock** port filtering (6.7+). Bubblewrap adds nothing here.
- Syscalls: **seccomp-BPF** (ptrace, mount, kexec_load, unshare, and more), applied to the agent inside the namespaces.
- Processes: **PID namespace** (host process tree invisible), plus IPC/UTS/cgroup isolation.

**Installation:**
```bash
# Debian/Ubuntu
sudo apt install bubblewrap

# Fedora/RHEL
sudo dnf install bubblewrap

# Arch
sudo pacman -S bubblewrap
```

### Out of scope

- **TLS interception.** The proxy sees CONNECT targets (hostname:port), not request bodies or responses.
- **Kernel exploits.** We rely on Apple's Seatbelt (macOS) and Landlock/seccomp (Linux) enforcement being correct.
- **Keychain isolation** (macOS). See [Keychain access is all-or-nothing](#keychain-access-is-all-or-nothing) below for what the grant actually reaches and when cplt drops it. `mach-lookup` is blanket because Node.js needs it for DNS, the Security framework, and system services. The **clipboard** (`com.apple.pasteboard`) is reachable through that same blanket allow, so cplt adds a targeted deny **by default**: only the pasteboard service is blocked, every other Mach service is untouched. Whatever the developer last copied — a password out of a password manager as often as not — is otherwise readable by the agent with a bare `pbpaste`. `--allow-clipboard` or `sandbox.deny_clipboard = false` gives it back.
- **sandbox-exec deprecation** (macOS). Apple marks it deprecated but has not removed it, and Chromium and VS Code still use it.
- **Landlock subpath limitations** (Linux). Landlock cannot deny access to subpaths within allowed directories. If a parent directory is allowed, all children are allowed. Certain fine-grained macOS rules therefore cannot be replicated on Linux, for example denying `.config/gh/extensions` while allowing `.config/gh/hosts.yml`. When Bubblewrap is active, user deny paths (`--deny-path` / `deny.paths`) ARE enforced despite this, via mount masks (see the platform comparison table). The built-in fine-grained rules stay macOS-only.
- **Credential directories linked into a grant** (Linux). Landlock denies `~/.ssh`, `~/.aws`, `~/.netrc` and the rest of the credential lists only by not granting them. When one is a symlink into a tree that is granted, say `~/.ssh -> ~/dotfiles/ssh` with the dotfiles repository as the project, a `--repo-dir` root or `allow.read ~/dotfiles`, Landlock grants the credential at its target along with the tree, and a writable grant makes it writable too ([#551](https://github.com/navikt/cplt/issues/551)). With Bubblewrap active, cplt masks each such entry at its resolved path (an empty tmpfs over a directory, the unreadable placeholder over a file), binds back on top every grant inside it that names the entry itself or its resolved path and follows no symlink outside the entry below that (`allow.read ~/.ssh/known_hosts`, a directory such as `~/.ssh/config.d`, the `--allow-gpg-signing` files; a link inside the entry, such as `~/.ssh/config -> conf.d/work`, is the user's and is bound back at its target), read-only unless that grant is writable, then re-applies any deny mask, read-only overlay or pin that falls inside a re-bound directory so the re-bind cannot lift it, and pins the directories above the target inside a writable tree so it cannot be renamed aside and recreated. **Without Bubblewrap this is not enforced**: the launch warns for each entry, naming the entry, its target and the grant that covers it. Three shapes stay open even with Bubblewrap: a link whose target does not exist at launch (nothing to mask, so the agent can create it inside a writable grant), a target under `/tmp` (the mask is skipped there, as for deny paths, and the launch warns), and a `DENIED_HOME_SUBPATHS` file that resolves inside its own granted tool directory (`~/.m2/settings.xml` in a linked `~/.m2`), which is the limitation above, linked or not; one linked out of that directory is masked like the rest. An `allow.*` path from any config layer or the command line whose own spelling passes through a symlink into a credential (`docs/hosts -> ../ssh/id_ed25519` inside the project) is ignored at load, with a warning: the agent can plant or repoint such a link, and the approved spelling names neither the entry nor the key. A link inside the entry does not count, on any platform: `allow.read ~/.kube/config` with `config -> clusters/prod.yaml`, or `~/.aws/credentials -> creds/work`, is kept, since the agent cannot write inside the entry (masked under Bubblewrap, never granted otherwise). One there that leads on through a link outside the entry is refused like the rest. Links above the entry's name are resolved, not vetted, which leaves one narrow shape: an approved `vendor/ssh/known_hosts` in a writable tree whose `vendor` the agent later turns into a link onto the tree holding the linked `~/.ssh` target reaches it by the resolved name and passes. It needs an `allow.*` entry already spelled with a credential's resolved directory name below a directory the agent can replace, and it reaches only files under that entry. The Landlock rules cplt adds on its own are checked before they are emitted, with or without Bubblewrap: an agent directory, its `write_files`, an AppDir, or an `--allow-gpg-signing` file that resolves into, or around, a credential entry (or, for the GPG files, anywhere outside `~/.gnupg`, onto its private keys, or onto anything but a regular file) is not granted, and the launch says which.
- **The shell alias.** `cplt --shell-install` is convenience, not a boundary. It shadows the command names an agent answers to — `copilot`, or both `antigravity` and `agy` — in interactive shells that read your rc file, and each alias pins `--agent` so the name you type is the agent that launches ([#509](https://github.com/navikt/cplt/issues/509)). It still does nothing for an agent you have not installed an alias for, for an absolute path (`/opt/homebrew/bin/copilot`), for `\copilot` or `command copilot`, or for a non-interactive shell, a script, or a launcher that never sources the rc file. Aliasing is how you get the sandbox by habit; typing `cplt` is how you get it for certain.
- **The PATH shims.** `cplt --shell-install --shims` (opt-in, [#514](https://github.com/navikt/cplt/issues/514)) reaches further than the alias: any process whose PATH starts with `~/.local/share/cplt/bin`, including `zsh -c`, scripts and IDE-spawned agents. It is still not a boundary. An absolute path, a reordered PATH, or a launcher that never ran a shell starts the agent unsandboxed, and `cplt doctor` can only report the shadowing it sees in its own PATH. **Shim tampering** is the risk the shims add: a shim is what your next `copilot` runs, outside any sandbox, so an agent that could rewrite one would escape at the next launch. Once the directory exists, the macOS profile denies writes to it after every user allow (so `allow.write ~/.local` does not reach it) and denies renaming each of its ancestors inside such a grant, so the agent cannot move `cplt` aside and plant a fresh `cplt/bin`. On Linux, Bubblewrap binds the directory read-only and pins the same ancestors; with Landlock alone, which cannot subtract a write from an ancestor grant, the directory is protected only by nothing granting it write by default. Both rules are emitted only when the directory exists, so a user who never opted in gets the same profile as before. Inside the sandbox the shim directory is dropped from PATH, so the agent's own name resolves to the real binary, and a shim reached by path while `__CPLT_WRAPPED` is set refuses (exit 126) rather than starting cplt inside itself. The rc lines that put the directory on PATH are skipped when `__CPLT_WRAPPED` is set, so a `zsh -c` or `fish -c` inside the sandbox does not put it back. A shim runs `cplt` by name, a PATH lookup: whichever `cplt` comes first on the PATH of the shell that ran the shim is the one that sandboxes the agent. Something that can put a `cplt` ahead of the real one on that PATH could just as well put a `copilot` there, so this adds no reach, but the shim is only as trustworthy as that PATH, and a missing `cplt` makes it exit 127 rather than run the agent. The sync that runs at every launch and shell start only adds shims and never runs a binary; removing a shim, and the `--version` probe that tells Block's `goose` from pressly's, happen only in `--shell-install --shims` (`cplt doctor` reports an unvetted `goose` or `pi` without running it), since a shim removed on a thin IDE PATH would let the agent run unsandboxed, and a probe would run whatever `goose` came first on PATH, unsandboxed. A shim with no agent behind it fails closed: cplt skips its own shims when it resolves the agent and stops with "not found". A process outside the sandbox, running as you, can of course rewrite the shims; so could it rewrite your rc files.
- **Code quality.** The sandbox cannot judge whether code written by Copilot contains backdoors. That is a code review problem.
- **`~/.config/gh/hosts.yml` token.** It can contain a plaintext GitHub token and is normally readable inside the sandbox; gh can instead store the secret in the OS credential store. A deny on gh's config directory blocks sandboxed file reads where enforced, not host extraction or token handover. See [Honest gaps](#honest-gaps).
- **pnpm's global config dir.** pnpm keeps its global settings in `config.yaml` and the registry tokens from `pnpm login` and `pnpm config set --global //registry/:_authToken` in `auth.ini` in the same directory (`rc` before pnpm 11). The pnpm tool-dir entry grants the XDG spelling, `~/.config/pnpm` (or `$XDG_CONFIG_HOME/pnpm`), read and write as a whole directory. That is the directory pnpm uses on Linux, and on macOS when `XDG_CONFIG_HOME` is set. Without it, macOS pnpm uses `~/Library/Preferences/pnpm`, and there cplt grants `config.yaml` alone, read-only. By default the agent can therefore read those tokens, and it can rewrite `config.yaml` or `rc` to point the host's own pnpm at another registry or turn lifecycle scripts back on for the next unsandboxed install. `pnpm install` does not write there; only `pnpm config set --global`, `pnpm login` and `pnpm logout` do. `sandbox.protect_pnpm_config` (default off, staged under [#264](https://github.com/navikt/cplt/issues/264)) makes the directory read-only and denies `auth.ini` and `rc`, as `~/.npmrc` is denied: on macOS as literal denies after every user allow, and on Linux by replacing the directory grant with a read-only grant on `config.yaml` alone, since Landlock cannot carve a file out of a granted directory. A `config.yaml` that resolves onto a token file or into a credential directory gets no grant on Linux. On macOS the directory's write deny also comes after every user allow, and its ancestors inside a writable grant are pinned against rename, so it stays read-only when `XDG_CONFIG_HOME` sits in the project or an `allow.write` tree; a path the profile cannot name refuses the launch. On Linux a grant that covers the directory (the same `XDG_CONFIG_HOME`, or an `allow.read` on `~/.config`) gives the token files back, because Landlock adds rules together, and the launch warns when one does. An exact `allow.read` on one token file gives it back, as for `~/.npmrc`. `config.yaml` stays readable with the key on, and pnpm 11 also accepts an `_auth` token there; a token kept in `config.yaml` is not covered.
- **Interpreter-based temp execution.** The sandbox blocks *direct* exec from `/tmp` (Mach-O/ELF binaries, dlopen), but it cannot block `bash /tmp/evil.sh` or `node /tmp/evil.js`, because the exec target is the interpreter (`/bin/bash`, `/usr/bin/node`), not the script file. Sandboxing interpreters would break Copilot.
- **`.vscode/` project configs.** The agent can write `.vscode/tasks.json`, `launch.json`, and `settings.json`, which VS Code may auto-execute outside the sandbox. This is an IDE trust boundary issue, not a sandbox scope issue. Mitigation: review `.vscode/` changes in `git diff` before committing, and set `"task.autoRunTasks": "off"` in VS Code.
- **Write+exec in home cache dirs.** The dependency stores (`~/.cargo/registry`, `~/.cargo/git`, `~/.gradle`, `~/.m2`, `~/.nuget`, `~/go/pkg`, and pnpm's content-addressable store) are writable and can have shared libraries **mapped** executable from them, because build tools need write for dependency downloads and `dlopen` for proc-macro dylibs, JNI and cgo native libs. None of them can `execve()` a binary: macOS emits a compensating `(deny process-exec)` for every `write && !process_exec` tool dir, and since [#243](https://github.com/navikt/cplt/issues/243) Landlock's `EXECUTE` right follows `process_exec` alone. pnpm's separate `package-manager-store` is an explicit exception because pnpm downloads and runs the version pinned by `packageManager`; see [Landlock cannot express `map_exec`](#landlock-cannot-express-map_exec) for the remaining backend gaps. A rogue agent could still write a malicious JAR to `~/.m2` or a Gradle plugin to `~/.gradle` and have the build load it, but the executed code stays sandboxed. `~/Library/Caches` (macOS) is broadly allowed for dev tool caches (go-build, Homebrew, pip), while browser and app caches (Chrome, Firefox, Discord) are denied via regex prefix rules, so new dev tools need no allowlist maintenance. `--allow-cache-exec <SUBDIR>` opts into the same write+exec trade-off for one named subdir such as `ms-playwright` or `pnpm/dlx`, under `~/Library/Caches` (macOS) or `~/.cache` (Linux). A rogue agent could write a binary there and execute it, but execution stays sandboxed. On Linux the subdir is validated as a traversal-free relative path before a Landlock execute rule is granted, so `../../bin` cannot escape the cache dir. The Linux base is always `~/.cache`, never `$XDG_CACHE_HOME`. Landlock binds a rule to the directory its path resolves to, so an entry reached through a symlink inside `~/.cache` (at the entry, or above it as `~/.cache/pnpm` is for `pnpm/dlx`) is granted at its target. cplt resolves the target when it validates the config and refuses one that is exactly `/`, `/tmp`, `$HOME`, a parent of `$HOME` or a system root such as `/usr` or `/etc` (the root itself, not a path below it); anything inside a dot directory in `$HOME` other than `~/.cache`, or inside `~/bin`, because the host loads code from there on its own (`~/.config/systemd/user`, `~/.config/autostart`, `~/.config/environment.d`, `~/.config/fish/conf.d`, `~/.bashrc.d`, `~/.local/bin`, `~/.config/nvim`, `~/.vscode/extensions`, `~/.claude`, `~/.copilot`); anything inside `/run`, `/var/tmp` or `/dev/shm`; a credential directory, cplt's state, the project, or anything overlapping any other path the policy grants. It never creates a linked entry's target, so a planted link cannot make a directory for a later session to fill. Otherwise it grants the target with a warning, because `~/.cache` is writable and an earlier session could have planted the link; `sandbox.refuse_cache_exec_links` (default off, staged under #264) refuses every such link instead. A symlinked `~/.cache` itself can only be the user's (the sandbox cannot write `$HOME`); its target gets the same checks, and the key refuses it too. The checks are a denylist and not proof: with the key off, a link an earlier session planted at an existing directory they do not cover, such as a tool prefix outside `$HOME` that the host runs programs from and no rule names, gets write and execute there on the next launch, and the warning is what tells the user. **Swap after validation is closed.** The rule carries the canonical path, and both the fork path (`precompute`) and the bubblewrap re-entry helper open it with `openat2(RESOLVE_NO_SYMLINKS)`, which refuses a symlink in any component, and stop the launch on failure. Bubblewrap binds the same canonical path, but `mount(2)` resolves its source and destination separately, so a link swapped in and out between the two lookups can mount another tree's root at the granted path, where a symlink-free walk reaches it. The helper therefore also requires the inode it opened to be the one the parent opened on the host (`st_dev`/`st_ino`, which a bind mount shares with its source), and a refusal there stops the launch rather than falling back to Landlock-only. A session that keeps swapping the path can still make bubblewrap's own bind fail before the helper runs. Auto-detect treats that like any bubblewrap start-up failure and falls back to Landlock-only with its usual warning: the grant still lands on the checked directory, but bubblewrap's mount masks are gone for that run. `use_bubblewrap = true` turns the fallback into a refusal. A mismatched mount anywhere else changes only mount-level writability; Landlock inside the namespace is still what grants write and execute, on the checked inode. Kernels or seccomp profiles that refuse `openat2(2)` (Linux 5.6, below Landlock's 5.13) fail such a launch closed. The same applies to Cypress's Linux state directory. Prefer it over `--allow-cache-exec-any`, which opens the entire cache tree.
- **User-granted exec trees** (`allow.exec` / `--allow-exec`). A tool prefix outside the default tool directories — a relocated Homebrew or toolchain root — gets read and execute, never write. Two grants are refused outright rather than granted narrowly: an unsafe root — `/`, `/tmp`, `$HOME` and any ancestor of it, or a platform system directory such as `/usr` or `/etc` — and any tree overlapping a writable one — the project directory, an `allow.write` grant, a writable tool directory such as `~/.cache` (use `--allow-cache-exec` there), a **writable agent data directory** (`~/.claude`, `~/.local/share/opencode`, `~/.pi/agent`, `~/.config/fish` — granted by the backends from the agent's own layout, not by config, which is why they were missing from the check), the **git common dir** of a worktree or bare repo, or a tree the backends make writable with no `allow.write` at all: `/tmp` and `/dev/shm` on Linux, `/private/tmp` and `/private/var/folders` on macOS ([#299](https://github.com/navikt/cplt/issues/299); use the scratch dir, or `--allow-tmp-exec` if you really mean all of temp — it does not cover `/dev/shm`, which has no grant to withdraw). The overlap is refused because writable plus executable is a binary-drop staging path, and neither backend can subtract the write from the exec: Landlock unions a write rule on an ancestor with an exec rule on a child with no way to remove it, and the only Linux alternative — a bubblewrap `ro_protect` mount — is absent on any host without user namespaces. Refusing is also the one answer both backends give alike. On macOS the write-deny for the granted tree is emitted last in the profile, after every allow, because SBPL is last-match-wins. Code executed from the tree still runs inside the sandbox.
- **The cplt binary's own exec grant** (Linux). The gh and git guard wrappers are `exec <cplt> git-gate …`, so Landlock has to grant read+execute on the cplt binary or every guarded command dies with "Permission denied" ([#348](https://github.com/navikt/cplt/issues/348)). The grant names the one file, resolved through `/proc/self/exe`, so it cannot disagree with what the wrapper execs. It also passes the same writable-tree overlap check every `allow.exec` grant gets, because Landlock is additive: cplt installed under a tree that is writable-but-not-executable would take `WriteFile` from that tree's rule and `Execute` from this one, and the agent could overwrite cplt and run it. `/tmp` is exactly that shape by default — untarring a release there to try it out is enough — while `~/.local/bin`, `~/.cargo/bin` and `/usr/local` are read-only and already executable. On an overlap the grant is **skipped with a warning naming the tree and telling you to install cplt elsewhere**, not granted: the guards then fail loudly on every command, which is the right way round, since a silently writable-and-executable cplt binary announces nothing. Trees that are already executable — the project and scratch dirs, write+exec by design — are not an overlap; the grant adds nothing there. macOS is unaffected: it grants `process-exec` profile-wide.

- **User-granted write trees** (`allow.write` / `--allow-write`). Since [#243](https://github.com/navikt/cplt/issues/243) a granted tree is writable but **not executable**: `process-exec` is granted profile-wide on macOS, so before that fix any `allow.write` grant was silently also an exec grant — the same binary-drop pair `allow.exec` grants are refused for. On Linux a write rule never carried execute in the first place, so the two backends now agree. Three execute rights are re-issued after the deny, and only where they fall inside the granted tree: the project directory and the scratch dir, both write+exec by design, and the `EXEC_IN_WRITABLE` table in `sandbox_policy.rs` — `~/.gradle/jdks`, `~/.konan/dependencies`, `~/.bun/install` and the two pnpm `package-manager-store` directories (`~/Library/pnpm/` and `~/.local/share/pnpm/`), which were already exec-allowed before any grant. Everything else loses execute, including tool directories: `allow.write = ["~/.cargo"]` makes `~/.cargo/bin` writable, and a writable `~/.cargo/bin` is a trojan that outlives the session, so it does not also stay executable. If you need both, they belong in two grants on two trees — and `allow.exec` refuses the overlap if they are not. cplt warns at launch when a grant actually shadows a tool directory it grants execute on, naming the directory: nothing is dropped, but the tree loses a default it had, and the tool failing later points at nothing. The warning is narrow on purpose — an ordinary `allow.write` on a work tree is silent.
- **Named repositories** (`--repo-dir` / `sandbox.repo_dirs`). A repository the user names gets the project directory's grant: read, write **and** execute. That is the point of the flag and the reason siblings needed a feature rather than a documentation note — an `allow.write` grant is deliberately non-executable, so a sibling granted that way can be edited but its own build and tests cannot run. The consequence is stated plainly: **each named root is a second binary-drop staging tree**, identical in posture to the project directory. A user who only needs to edit a tree should use `allow.write`, and the startup summary says which of the two they have, distinguishing a root nested inside the project (no new file access — it already inherited the project grant) from one beside it (a new read/write/execute tree). Everything that protects the project tree protects a named root: the `PROTECTED_IN_ROOT` and `PROTECTED_IN_GITDIR` tables are emitted per writable root, so `.git/hooks`, `.git/config`, `.cplt.toml` and the rest stay unwritable in it, and an `allow.exec` grant overlapping a named root is refused exactly as one overlapping the project directory is. A named root that is a linked worktree or bare checkout also gets its shared gitdir granted read+write — without it `git` there fails with `not a git repository` — and the persistence denies are emitted after that grant, so they still win. The git guard follows the named set: each root's default branch and remote URLs are captured at launch, parent-side with the trusted git, and baked into the wrapper, so a push inside a named root is judged by that root's own protected branch rather than the launch repository's — and never re-derived inside the sandbox, where `refs/remotes/*/HEAD` is agent-writable (GHSA-cm6f-3wjh-x9qx). `allow_push` rules carry **launch/named-root identity** ([#424](https://github.com/navikt/cplt/issues/424)): a rule naming a remote is pinned to that remote's URL in every repository in scope, and it authorizes a push only if the push *also* runs in one of them. Without the second half the two halves of the guard disagree about what a repository is — `protect_default_branch_only` judges the repository the push runs in, while a URL-only rule would authorize from anywhere, including a clone the agent made underneath the project. When the scope could not be captured at launch (no trusted git in the parent) the rule falls back to URL identity alone and the launch says so; that condition is decided parent-side and the agent cannot bring it about.

A named root's `.cplt.toml` is loaded for its `[deny]` section and nothing else. `[deny]` can only tighten, so it opens no grant channel, needs no approval and keys no trust entry — which is why loading it from N repositories does not multiply the `--accept-repo-config` bypass class, and why that flag is not refused alongside `--repo-dir`. `[propose]` from a named root is never consulted (a committed one gets a line saying so; an uncommitted one has already had its grants stripped at the loader, so there is nothing to report). Per-root approval — letting a named root propose *and* be approved — is a separate feature and is not built. Deny paths anchor to the repository that wrote them, so the union across roots is exactly "each repository's deny applies inside itself"; `deny.env` is the exception and is process-wide, which is tightening and is announced. A `.cplt.toml` in a named root that cannot be read **warns**, and the launch continues — the same answer the launch repository's own unreadable config has always given ([#472](https://github.com/navikt/cplt/issues/472)). It used to stop the launch, on the argument that a restriction its owner wrote is missing; that argument is sound and applies equally to the launch repository, so having two answers to one question was the defect. The warning says what was lost in the same breath: the session is less restricted inside that repository than its config asks for. What makes this defensible rather than a hole is that the file grants nothing — `[propose]` from a named root is never consulted — so only a tightening can go missing, never a permission. It also removes a denial-of-service: a named root is agent-writable, Landlock cannot deny `.cplt.toml` inside it, and `.git/info/exclude` hides a new file from `git status`, so fatal handed a previous session a way to stop every later launch with a file the user could not see. `sandbox.refuse_invalid_repo_config` (off by default, user config only) makes an unreadable, unparseable or invalid `.cplt.toml`, and one with an unrecognized `[deny]` key, fatal for the launch repository and every named root. An unrecognized `[propose]` key stays a warning so that files stay forward-compatible. With the key on, the denial of service comes back, and it is wider than the uncommitted-file case above. The loader reads `HEAD:.cplt.toml`, and a sandboxed session can commit to HEAD on macOS and on Linux, in the launch repository or a named one, so any session can commit a broken file and stop later launches. The commit shows in `git log`, and the refusal says which copy it read. What the key buys is narrow: a typo or a broken edit cannot silently drop `[deny]` rules. It does not stop an adversarial session, which can commit a valid file with `[deny]` removed. Nothing in cplt detects that, because a committed repo config is by design the repository's own statement of policy. With the key off, the warning above is the whole behaviour ([#385](https://github.com/navikt/cplt/issues/385) M-01). Validation is re-run on **every** launch, not only when the root was written: a persisted entry that has stopped being a git toplevel, acquired a symlinked final component, or become an unsafe root stops the launch rather than being silently dropped. The Linux gaps that already apply to the project directory apply once per named root: Landlock enforces none of the protected-path tables. Bubblewrap covers repositories nested inside a writable root as well as the root's own `.git`, by finding them at launch — read-only binds *and* the rename pins that make those binds mean something. macOS matches at any depth, because there the same entries are a regex rather than a list of paths; on Linux they are found by a bounded breadth-first walk, and the bounds are part of the security statement: **three levels** below each root and **20 000 directories** in total, symlinked directories not followed, dependency and build directories not descended into (they are still tested for being repositories themselves). An agent that creates more than 20 000 directories in a granted tree can push a real repository past the cap; the launch says so when bubblewrap is active, and says nothing on a Landlock-only host, where none of these binds exist in the first place. Three shapes stay uncovered when nested: a **bare** repository (no `.git` to find), and a **worktree** or **submodule**, whose hooks live in a shared gitdir that nothing resolves for a nested repository — the launch repository and named repositories do get theirs resolved.

**A nested repository planted during the session** ([#576](https://github.com/navikt/cplt/issues/576)). Everything above protects repositories through paths spelled `<repo>/.git/<name>`. A session can sidestep that by building a git directory under any other name, writing `core.fsmonitor` or `core.hooksPath` into its config, and then pointing a new `<dir>/.git` at it: a `gitdir:` pointer file, a symlink, or the directory itself renamed into place. None of those writes a denied path, and git run in `<dir>` afterwards runs the planted program on the host. So can a git-aware shell prompt, the moment the user `cd`s there. On Linux a plain `git init` and `git config` in a new subdirectory do the same, because bubblewrap only protects repositories that exist at launch and Landlock protects none. What covers it:

- **Every platform, always on: an end-of-session check.** Before the session, cplt records every `.git` below the project and each named repository, using the walk described above but with no depth limit (the 20 000-directory budget stays). Afterwards it walks again and prints an error naming each directory whose `.git` is new, or whose kind, pointer or symlink target, `config`, `config.worktree`, `commondir`, or hooks (each hook's name, symlink target and content, and the `hooks` directory's own inode, mtime and ctime, so a change behind an unlistable `hooks` still shows) changed. The user is told not to run git there until they have checked it. This is detection, not prevention: it relies on the user reading the message. When the git directory a new or changed entry resolves to (a pointer target, a symlink's target, a `commondir`) is outside every root, the line says where it is. The roots themselves are tested too: a root with no `.git` and no git-directory layout at launch (a project that is not a repository, or `--project-dir <repo>/sub`) that has one at the end is reported as new. A root that was a repository at launch is not fingerprinted; its own `.git` is covered by the profile rules above, except for a `.git` planted directly inside it (`<project>/.git/.git`), which is reported by that name. Deeper plants inside a gitdir, such as `<project>/.git/objects/.git`, are neither reported nor, with `sandbox.deny_nested_git` off, blocked: the walk does not descend into `.git`. Git obeys one only when run with its working directory inside the gitdir. It does not look inside dependency and build directories (`node_modules`, `target`, `vendor`, …) or below `allow.write` grants.
  Three variants need no ordinary `.git` and are reported too. A **case variant** such as `.GIT`: on a case-insensitive volume (the APFS default) git opens it when it looks up `.git`. The walk finds `.git` by a filesystem lookup rather than by comparing names, so it sees exactly what git sees. A **git-directory layout** written straight into a directory: git's discovery accepts a directory with a `HEAD` and either `objects` and `refs` beside it or a `commondir` file naming where they are, and obeys the `config` it finds (`safe.bareRepository` defaults to `all`). The check counts any `HEAD` (a dangling symlink to `refs/heads/main` included) with either of those, and follows `commondir` to fingerprint the config and hooks there too. Setting `safe.bareRepository = explicit` in your global git config closes this variant outside cplt. A **symlink to a directory**: `<project>/tools -> /private/tmp/evil` makes git run in `tools` obey `/private/tmp/evil`'s config. The walk does not descend into symlinks, but it tests each one for being a repository by following it. Whether one is a repository *at check time* is not enough, though: the repository can sit one level down (`pkgs -> /private/tmp/s` with `/private/tmp/s/app/.git`), or the link can dangle and be armed later from outside this project's sandbox. So every symlink below the roots that leads to a directory, or dangles, is recorded with its `read_link` target, and any that is new or re-aimed and leads outside every root is reported, whatever is at the other end. "Leads outside" is decided step by step: the lookup is followed one component and one link at a time, as the kernel does it, and if any real path it reaches, or any symlink it follows on the way, is outside every root (directories that are ancestors of a root excepted, so a full `/Users/me/proj/src` spelling is fine) the link is reported, even when the lookup ends back inside. Shapes this catches: `pkgs -> /tmp/l` with `/tmp/l -> <project>/src`, where `/tmp/l` can be re-aimed later from anywhere; the same with `l` placed directly beside the project, in its parent directory; and `dotdot -> /tmp/stage/x/../../<project>/src` with `x` a real directory today, where the kernel's `..` lands somewhere else once `x` is replaced by a symlink. Links to regular files are ignored, since git does not run in one. Links that stay inside a root are not reported this way. Tools that create directory links out of the project during a session are reported too; known sources are Nix `result` links and Bazel `bazel-*` output links. The walk skips `.tox`, `.nox` and `.direnv` for the same reason (virtualenvs full of links out), and does not descend into the dependency directories listed above.
  **Unreadable directories.** A directory the walk is not permitted to list (`chmod 311`) hides everything below it. Its inode, mtime and ctime are recorded. It is named in an error when it was readable at launch, is new, or was unreadable at launch but its `stat` changed since (the session opened it, changed something, and closed it again); it is only counted in a warning when it is exactly as it was at launch. A listing that fails for any other reason is counted in a warning.
  **The directory budget.** The walk goes level by level in name order, so when it stops it has skipped everything deeper and every later name on the level where it stopped. If the project was under the budget at launch and over it at the end, the session created the directories, and that is reported as an error saying so. If it was already over at launch, a warning says what was not checked.
  **The window after the check.** The scan runs after the session's process tree has settled (the same probe the change audit uses). A descendant that closes the probe descriptor and detaches can outlive it and plant afterwards; cplt does not kill the process tree (see the settle-probe notes on why a process group is not used). When the session leaves processes running, the report says a repository created after the check is not reported. With both `sandbox.audit` and `--observe-domains` off there is no probe, and nothing is said about the window.
  **Residuals of the check.** Nothing watches the far end of a link or pointer that leads outside every root. One that existed at launch, or was reported once, can be re-aimed after the check by changing what is at its target, from outside this project's sandbox, and no later session reports it. The launch record trusts the disk as it is at launch: a repository planted by a process that outlived the previous session's check is part of the next session's baseline and is not reported then. Git follows `include.path` and `includeIf` targets and a `core.hooksPath` directory; the check fingerprints none of those, so a change there, to a path the config already named at launch, is not reported. A config or hook longer than 1 MiB is compared by its first MiB, length, inode and change time, not its full content.
- **macOS, opt-in: `sandbox.deny_nested_git`.** Denies `file-write-create` on `^<root>/.+/\.[gG][iI][tT]$` for every writable root except the managed worktree root (`sandbox.allow_git_worktrees`), which keeps its own rules so `git worktree add` can write `<root>/<name>/.git`. That blocks creating the `.git` name itself as a new pointer file, symlink, hard link, `mkdir`, or a file or directory renamed onto the name, in any letter case (each verified with `sandbox-exec`). It also denies `^<gitdir>/(.+/)?\.[gG][iI][tT]$` for every gitdir the profile knows (each writable root's `.git`, the worktree common dir, and the resolved gitdirs of writable grants whose repository data is not at `<grant>/.git`), because git run with its working directory inside a gitdir looks for a `.git` there first: `<project>/.git/refs/.git` would be obeyed by a prompt that `cd`s into `.git/refs`. For gitdirs below a root the first rule already covers this; the second is what covers a common dir outside every root. **Residuals:** it does not block moving in an *ancestor* of a `.git`. `mkdir -p /private/tmp/stage/sub/.git && mv /private/tmp/stage/sub <project>/a/sub` succeeds, because only `sub` is created below the project; any writable staging area outside it (`/private/tmp`, `/var/folders`) works. Nor does it block a symlink out of the project (`<project>/tools -> /private/tmp/evil`), which creates no `.git` below the root either. The end-of-session check reports the moved-in ancestor as a new repository and the symlink as a link leading outside the project. It is off by default under the staged-rollout rule because it breaks `git worktree add` into the project and fixtures that create a `.git` there. It does not block a git-directory layout either. A profile rule cannot say "a `config` next to a `HEAD`", and denying the names `HEAD`, `objects`, `refs`, `commondir` or `config` below the project would break far more than it protects. Only the end-of-session check covers that variant.
- **Linux: detection only.** Landlock cannot deny a path inside a tree it allows, and bubblewrap binds only paths that exist, so creating a `.git` cannot be blocked. Setting `sandbox.deny_nested_git` on Linux prints a warning saying so rather than doing nothing silently.

- **Landlock cannot express `map_exec`.** <a id="landlock-cannot-express-map_exec"></a>macOS separates `file-map-executable` (mapping a dylib's pages executable) from `process-exec` (running a binary). Landlock has no such split: its `EXECUTE` right is checked on `execve()` — `file_open` with `FMODE_EXEC` — and there is no hook for `mmap(PROT_EXEC)`, which a dynamic loader reaches with `READ_FILE` alone. cplt used to compute the Landlock execute bit as `process_exec || map_exec`, so every dependency store that carries `map_exec` for dylib loading was **write+execute on Linux and nowhere else** ([#243](https://github.com/navikt/cplt/issues/243)). The bit now follows `process_exec` alone. Three trees keep `EXECUTE` on Linux anyway, each recorded in `EXEC_IN_WRITABLE` with its reason and a `LinuxCoverage::Gap`, because Landlock cannot subtract the parent's write grant and the bubblewrap read-only bind that could is absent on hosts without user namespaces:
  - `~/.gradle/jdks` — Gradle provisions toolchain JDKs here and execs them. macOS grants the same exec and takes the write back at the tail of the profile; Linux cannot do the second half, so the tree stays write+execute there.
  - `~/.dotnet` — `DOTNET_ROOT` for SDKs installed by `dotnet-install.sh`. macOS re-grants exec through the configured `dotnet_root`; Landlock has no counterpart rule.
  - `~/.konan` — Kotlin/Native execs `clang++` from the LLVM toolchain it downloads into `~/.konan/dependencies`. A macOS build showed that link step failing with `Operation not permitted` until the toolchain was granted exec ([#323](https://github.com/navikt/cplt/issues/323)). macOS now grants exec on `~/.konan/dependencies` only and takes the write back at the tail of the profile, the same shape as `~/.gradle/jdks`. Linux still grants `EXECUTE` on the whole of `~/.konan`.
  The `.dotnet` entry and the Linux half of `.konan` are **stated gaps, not decisions**: the fix was written and verified on macOS, and neither a real .NET nor a Kotlin/Native build could be run on a Linux host to show whether dropping `EXECUTE` breaks them. A wrong carve-out either reopens the hole or breaks every user of the tool, so the pre-existing right is kept until a Linux host can settle it.
- **Kotlin/Native toolchain on macOS** ([#323](https://github.com/navikt/cplt/issues/323)). `~/.konan/dependencies` is executable and read-only, so the agent cannot drop a binary there and run it. Four things are left. K/N opens `~/.konan/dependencies/cache/.lock` for writing on every build, so that one file takes data writes. It gets no create, unlink, link or mode rights, so the agent can put bytes in it but cannot replace it, hard-link a binary to that name or make it executable. A first K/N build inside cplt cannot download the toolchain, because the write is denied. The failure names the path under `~/.konan/dependencies`, and running that first build outside cplt once fixes it. The rules match the resolved path, so if `~/.konan/dependencies` is already a symlink to another volume, K/N cannot exec from it. `KONAN_DATA_DIR` moved away from `~/.konan` misses the whole `~/.konan` grant, as a relocated `GRADLE_USER_HOME` does.
- **Playwright Chromium runtime** (macOS, `allow_cache_exec = ["ms-playwright"]`). Enabling browser testing grants system permissions well beyond the normal `process-exec` and `file-map-executable` rules:
  - `(allow syscall*)`, meaning all syscalls including Mach traps. Chromium uses undocumented traps that vary by macOS version and cannot be enumerated in a stable allowlist.
  - `(allow system-socket (socket-domain AF_UNIX))` for IPC between the browser, renderer, and GPU processes.
  - `(allow iokit-open-user-client)` for GPU capability probing, unscoped because IOKit class names are hardware-dependent.
  - `(allow mach-register)` scoped to three narrow namespaces: `^org\.chromium\..+$` for Crashpad and inter-process IPC, anchored with `$` and requiring at least one character after the prefix; `^com\.google\.chrome\.for\.testing\.MachPortRendezvousServer\.[0-9]+$` for Playwright's Chrome for Testing rendezvous service, fully anchored with a numeric PID suffix; and the `com.google.chrome.for.testing.apps.` app-shim namespace with a suffix of exactly 64 uppercase hexadecimal characters. The emitted SBPL spells that suffix as 64 adjacent `[0-9A-F]` atoms because counted repetition did not match in Seatbelt. Lowercase, non-hexadecimal, shorter, longer, and other product or bundle-ID variants remain denied. Denying either Chrome for Testing registration causes `EPERM (1100)` and prevents the browser from completing startup and CDP navigation.

  Unix socket operations for Chrome's `SingletonSocket` use `[^/]+/[^/]+` for the `var/folders` path segments, so a match cannot cross directory boundaries. All filesystem, network, and credential denies stay enforced independently. These rules activate only when `allow_cache_exec` contains `"ms-playwright"` or any subpath such as a versioned Chromium directory (first path component match); `allow_cache_exec_any` and unrelated entries do not trigger them. Without them, `chrome-headless-shell` segfaults (`SEGV_ACCERR`) during browser initialization, while Chrome for Testing fails its Mach registrations.

  With the same explicit Playwright opt-in, cplt creates one short socket base named `/private/tmp/cplt-pw-<32 lowercase hex>` and sets `PWTEST_SOCKETS_DIR` to that exact path. Creation is atomic from a cryptographically random session ID; the directory is a current-user-owned, non-symlink directory with mode `0700`. A guard owns it for the full child lifetime and removes only that exact directory on exit. A hard termination such as `SIGKILL` skips that guard and leaves the empty directory behind; it carries no capability once the process is gone, and reclaiming it automatically would need a descriptor-relative deletion primitive cplt does not have today. The fixed 53-byte shape is independent of `HOME` and scratch, and leaves conservative headroom below Playwright's 103-byte Unix-socket limit after its observed longest domain and fallback socket suffix are appended.

  The macOS profile grants only `network-bind` and `network-inbound` for local Unix sockets and `network-outbound` for remote Unix sockets beneath that concrete validated directory. It does not grant socket operations on `/private/tmp` itself, siblings, project or scratch paths, and adds no file or temp-execution permission; the existing `/private/tmp` file rules and execution denies remain unchanged. Ambient and inherited values cannot move the automatic capability elsewhere. An explicit `--pass-env PWTEST_SOCKETS_DIR`, from the flag or from `sandbox.pass_env` in config, preserves the caller's value and suppresses both automatic directory creation and its SBPL socket rules; repo `deny.env` still applies last. Passing the key through without exporting a value leaves the child with no socket directory at all, so cplt warns that Playwright will fall back to a `TMPDIR` path that is usually too long.

  **macOS nested sandbox:** Chrome helpers inherit cplt's Seatbelt profile, so Chromium's own Seatbelt initialization fails with `forbidden-sandbox-reinit`. Chromium must therefore launch with `--no-sandbox`. Playwright used as a library already does that by default, and for Playwright MCP, which turns it back on, the same `ms-playwright` opt-in sets `PLAYWRIGHT_MCP_SANDBOX=false` for the child. This is the treatment cplt already gives Gradle's nested `sandbox-exec`, and it keeps a cplt-only workaround out of the MCP server configuration that editors and CLIs share with machines that have no cplt around them. An explicit `--pass-env PLAYWRIGHT_MCP_SANDBOX` hands the choice back to the caller. Any other Chromium launcher still needs its own flag. Chrome and all helpers remain inside the outer cplt profile.

  Launching Chromium this way removes its OS-enforced child privilege separation. A compromised renderer receives the complete cplt Playwright profile, including project read/write access, `syscall*`, AF_UNIX sockets, and IOKit user clients. cplt remains the enforcing boundary, and its filesystem, network, environment, and credential restrictions still apply. This is an explicit trade-off of the `ms-playwright` opt-in, which is the only thing that disables Chromium's sandbox: without it cplt sets nothing, and no browser process is launched outside cplt.

  **Linux:** `--allow-cache-exec ms-playwright` grants Landlock execute on `~/.cache/ms-playwright` (the XDG equivalent), so the browser binary runs. The macOS Seatbelt/Mach permissions above have no Linux analogue. The remaining difference is Chromium's *own* sandbox: on Linux it builds a setuid-less sandbox from user namespaces (`unshare`/`setns`/`clone` with `CLONE_NEW*`), and cplt's seccomp-bpf filter denies `unshare`/`setns` with `EPERM`, because user-namespace creation is a sandbox-escape tool (see "Defense layers"). cplt deliberately does **not** relax the filter for browser testing. Run Chromium with its own sandbox disabled instead (`--no-sandbox`, or Playwright `chromiumSandbox: false`). cplt's Landlock + seccomp is the enforcing boundary, so Chromium's nested sandbox is redundant inside it. `/dev/shm` is already allowed, so `--disable-dev-shm-usage` is not required.
- **Cypress Electron runtime** (macOS, `allow_cache_exec = ["Cypress"]`). Cypress registers `com.electron.cypress.MachPortRendezvousServer.<pid>` while `cypress verify` starts its Electron smoke test. The explicit cache-exec entry grants `mach-register` only for that fully anchored bundle ID with a numeric PID suffix and `iokit-open-user-client` only for `RootDomainUserClient`, which Chromium's power monitor opens through `IORegisterForSystemPower`. Other `com.electron.*` services and IOKit user clients remain denied, and neither `allow_cache_exec_any` nor a similar cache name activates the rules. These permissions give sandboxed processes access to the system-power user client without granting `syscall*` or `system-socket`. The same opt-in grants read/write under `~/Library/Application Support/Cypress`, where Cypress keeps browser profiles and project state, then explicitly denies process execution and executable mapping there. Linux gets the equivalent non-executable read/write grant under `${XDG_CONFIG_HOME:-~/.config}/Cypress`; it has no Mach IPC or IOKit equivalent. The cache itself (`~/Library/Caches/Cypress`, `~/.cache/Cypress`) is writable and executable like any cache-exec entry. The setting is global-only, so repository configuration cannot grant it.
- **Project build scripts.** The agent can modify `Makefile`, `package.json` scripts, `build.gradle`, `.github/workflows/`, and the like. These are legitimate Copilot targets and cannot be blocked. Code review (git diff) before running builds or committing is the mitigation.
- **POSIX shared memory** (macOS). `ipc-posix-shm-*` is allowed because Node.js needs it for DNS and system queries. An agent could in theory use SHM as an IPC channel to processes outside the sandbox, but that requires a cooperating process already running on the machine.
- **DNS tunneling.** Name lookups through the system resolver are possible on macOS, `proxy.forced` included, unless `proxy.deny_dns` is on. Direct UDP DNS is blocked under `proxy.forced` on both platforms and unrestricted otherwise. See [Honest gaps](#honest-gaps) for why we accept this.

## Real-world attack landscape (2025-2026)

These are the attack vectors and infrastructure seen in real supply chain attacks. cplt is designed to mitigate them.

### Attack kill chain

Supply chain attacks through AI coding agents follow a consistent pattern:

```
1. INFECTION          2. RECONNAISSANCE       3. CREDENTIAL HARVEST    4. EXFILTRATION
postinstall hook   →  hostname, IP, user,  →  ~/.ssh/*, ~/.aws/*,  →  HTTP POST to C2
or patched file       env vars, OS info        .env, npm tokens        or DNS tunnel
```

### Observed incidents

| Incident | Year | Vector | Impact |
|---|---|---|---|
| **Shai-Hulud** | 2025 | Compromised npm maintainer accounts | Self-replicating worm hit 700+ packages, stole npm tokens and AWS keys |
| **CamoLeak** | 2025 | Prompt injection in PR comments | Copilot Chat exfiltrated private code via GitHub image proxy (CVE-2025-59145, CVSS 9.6) |
| **RoguePilot** | 2026 | Prompt injection in GitHub issues | GITHUB_TOKEN leaked from Codespaces, enabling full repo takeover |
| **YOLO Mode** | 2025 | Agent writes to .vscode/settings.json | Auto-approved all commands, giving RCE (CVE-2025-53773) |
| **MCP Poisoning** | 2026 | Hidden instructions in npm metadata | AI agents extracted SSH keys from dev machines, invisible to user |
| **axios RAT** | 2026 | Trojanized npm package by STARDUST CHOLLIMA | Hidden RAT deployed to any system where an AI agent ran `npm install` |

### Exfiltration infrastructure (observed in the wild)

| Category | Domains/services | Why attackers use them |
|---|---|---|
| **Discord webhooks** | `discord.com/api/webhooks/*` | Write-only, no authentication needed, blends with legitimate traffic |
| **Webhook capture** | `webhook.site`, `pipedream.com`, `requestbin.com` | Disposable endpoints, no signup required |
| **Tunneling** | `ngrok.io`, `localtunnel.me`, `serveo.net` | Reverse shells through NAT/firewall boundaries |
| **Paste sites** | `pastebin.com`, `paste.ee`, `hastebin.com` | Credential dump staging for later retrieval |
| **File sharing** | `transfer.sh`, `file.io`, `0x0.st`, `catbox.moe` | Exfiltration of SSH keys and .env files |
| **Telegram** | `api.telegram.org` | Bot API as a write-only C2 channel |
| **IP recon** | `ipinfo.io`, `ifconfig.me`, `checkip.amazonaws.com` | Victim network fingerprinting |
| **Cloudflare Workers** | `*.workers.dev` | Free hosting for C2 relays, resistant to takedown |
| **Ethereum dead-drop** | Smart contract to Cloudflare-fronted domains | C2 URL rotation without code changes, impossible to take down |

cplt has a built-in blocklist covering most of these: [`blocked-domains.txt`](blocked-domains.txt), compiled into the binary and applied on every install whenever the proxy runs. `api.telegram.org` and `*.workers.dev` are not on it, and neither are Discord webhooks (`discord.com/api/webhooks/*`): they are path-based, and a domain list cannot block a path without blocking all of `discord.com`. Your own `proxy.blocked_domains` file adds to the built-in list; it does not replace it.

### What gets stolen (in order of attacker priority)

1. **npm/pip tokens.** Enables worm propagation (Shai-Hulud took 700+ packages using stolen tokens).
2. **CI/CD tokens.** GITHUB_TOKEN, AWS keys from environment variables.
3. **SSH keys.** `~/.ssh/id_*`
4. **Cloud credentials.** `~/.aws/credentials`, `~/.config/gcloud`
5. **Environment files.** `.env`, `.env.local` (API keys, database URLs).
6. **Network topology.** Internal IPs, DNS servers, hostnames, all recon for lateral movement.

### How cplt defends against each step

| Kill chain step | Attack technique | Sandbox defense | Verdict |
|---|---|---|---|
| **1. Infection** | `postinstall` hook runs code | **Blocked by default.** Hardening injects `npm_config_ignore_scripts=true`, `pnpm_config_ignore_scripts=true`, `YARN_IGNORE_SCRIPTS=true` (yarn 1) and `YARN_ENABLE_SCRIPTS=false` (yarn 2+, dependencies only) | ✅ **Stopped** |
| **2. Recon** | Read hostname, IP, env vars | Can read process env vars (needed for Copilot), hostname | ⚠️ Partial leak possible |
| **3. Credential harvest** | Read ~/.ssh, ~/.aws, .env | **Kernel-blocked.** macOS Seatbelt denies the read syscall. | ✅ **Stopped** |
| **4a. HTTP exfil** | POST to discord/webhook/C2 | Only port 443 allowed. On macOS localhost and the SSH agent socket are blocked too; on Linux neither is, and UDP is unrestricted unless `proxy.forced` is on (see [Linux-specific limitations](#linux-specific-limitations)). Credentials are unreadable, so the blast radius is small. The proxy blocklist helps if enabled. | ⚠️ **Partially mitigated** |
| **4b. DNS tunneling** | Encode data in DNS queries | Not inspected; DNS bypasses the proxy. On macOS lookups work even under `proxy.forced` and a fail-closed allowlist, because the system resolver (mDNSResponder) is reachable; opt-in `proxy.deny_dns` closes it. On Linux `proxy.forced` blocks direct UDP DNS | ❌ **Not stopped** on macOS by default; ⚠️ narrowed with `proxy.forced` + `proxy.deny_dns` (trustd's certificate URL fetches remain). On Linux `proxy.forced` blocks direct UDP DNS; lookups through a local Unix-socket resolver (nss-resolve, nscd) are not blocked below kernel 7.1 and untested |
| **4c. Reverse shell** | Connect back via ngrok | Non-standard ports blocked; `ngrok.io` blocked when proxy enabled; localhost blocked | ⚠️ **Partially mitigated** |
| **5. Binary staging** | Drop RAT into cache dir and execute | **Kernel-blocked by default.** `~/Library/Caches` has no `process-exec` or `file-map-executable`, and `/tmp` exec is denied. `--allow-cache-exec <SUBDIR>` grants exec to one named subdir, and the write+exec risk applies there. `--allow-exec <PATH>` grants exec on a named tool prefix, but never write: a grant overlapping the project dir or an `allow.write` grant is refused at startup on both backends. | ✅ **Stopped** (⚠️ opt-in exemption available) |
| **Worm propagation** | Republish infected packages | Can't read npm tokens (in ~/.npmrc, kernel-blocked), unless the user turned on `sandbox.allow_build_credentials` or `allow.read ~/.npmrc` | ✅ **Stopped** (⚠️ opt-in exemption available) |

### Localhost zero-copy on macOS

With `--allow-localhost-any`, cplt allows the local-socket check used by Darwin
`sendfile()`, which has no remote sockaddr. That allow precedes an addressed-IP
deny and the existing destination allows, so it cannot authorize TCP connections
or UDP traffic to other destinations merely because the source socket is bound
to loopback. It is absent under `proxy.forced` and when `allow_localhost_any` is
off. Kernel tests cover IPv4/IPv6 transfers in both directions and unauthorized
TCP/UDP destinations with and without explicit loopback binding. The addressless
check also permits zero-copy on already-established non-loopback sockets; it is
not a destination check. Ordinary writes already work on established sockets,
including inherited ones. The new rules preserve restrictions on acquiring a
connection, not a guarantee that every subsequent send is destination-filtered.

### Honest gaps

**Network is port-restricted, with optional domain filtering.** SBPL (Seatbelt Profile Language) has no domain-based filtering at the kernel level, and Copilot CLI connects to CDN-backed endpoints (`api.business.githubcopilot.com`) whose IPs change and cannot be enumerated. So we allow outbound TCP on port 443 only, with `--allow-port` for extras such as `--allow-port 80`. On macOS, SSH agent access and localhost outbound are blocked at the kernel level; on Linux neither is, see [Linux-specific limitations](#linux-specific-limitations). That leaves:

- A compromised agent CAN make HTTPS requests to attacker-controlled servers on port 443
- A compromised agent CAN speak any protocol on port 443, SSH included: `ssh.github.com:443` is reachable without `--allow-port 22`, and under proxy-forced mode through a CONNECT tunnel, because the proxy does not inspect tunnel contents and a `github.com` allowlist entry matches its subdomains. What stops SSH is the missing key, not the port, see [SSH over port 443](docs/known-impacts.md#ssh-over-port-443)
- A user allowlist cannot shut the agent out of its own infrastructure: the agent's own hosts (for Copilot, `github.com`, `githubcopilot.com` and the rest of its infrastructure list, not the package registries) are always added to it, so the agent CAN reach them and anything a subdomain match covers. To exclude one, put it in the blocklist, which is checked after the allowlist and wins. For OpenCode with a GitHub Copilot provider connected (a `github-copilot` entry in its `auth.json`), or logged in with the host gh token, the Copilot infrastructure hosts are added the same way
- A compromised agent CANNOT exfiltrate cloud credentials from env vars (env is sanitized; only the safe allowlist passes through)
- A compromised agent CAN exfiltrate project source code and Copilot auth tokens
- A compromised agent CANNOT connect to local services (localhost is blocked on macOS; on Linux use `--with-proxy`, see [Linux-specific limitations](#linux-specific-limitations))
- A compromised agent CANNOT use loaded SSH keys **on macOS**, where `(deny default)` plus the per-path `network-outbound … unix-socket` allows leave the agent socket unreachable at the kernel level. **On Linux it CAN below kernel 7.1**: Landlock gains the unix-socket `connect()` right only at ABI v9, and the agent socket is not in the set bubblewrap masks, so the withheld `SSH_AUTH_SOCK` is the only barrier and an agent that sets it itself can use the loaded keys. bwrap's private `/tmp` hides the stock OpenSSH socket but not a desktop agent under `$XDG_RUNTIME_DIR`, see [Linux-specific limitations](#linux-specific-limitations)
- A compromised agent CANNOT connect on non-standard ports such as 8080 or 3000 unless `--allow-port` is used
- A compromised agent CANNOT exfiltrate SSH keys, cloud credentials, or npm tokens (kernel-blocked from reading them)
- A compromised agent CAN request GPG signatures but CANNOT exfiltrate private keys. On macOS this needs `--allow-gpg-signing`; on Linux the agent socket is reachable whether or not the flag is set, so the capability is there by default (see [Linux-specific limitations](#linux-specific-limitations))
- The proxy logs and filters all outbound connections by default, including Copilot CLI traffic (via `NODE_USE_ENV_PROXY=1`), and enforces port restrictions matching the sandbox policy. Use `--no-proxy` to disable.

*Mitigation:* `--allowed-domains allowed-domains.txt` restricts traffic to known Copilot endpoints, the built-in blocklist blocks known exfiltration infrastructure (add your own with `--blocked-domains`), and `--proxy-log proxy.log` gives a post-session audit trail. All traffic, Copilot's own Node.js connections included, routes through the proxy.

**JVM IPv4 stack forcing.** macOS SBPL `"localhost"` filters do not match Java NIO's IPv4-mapped addresses (`::ffff:127.0.0.1`), because SBPL accepts only `*` or `localhost` as the host part and rejects literal IPs. cplt injects `-Djava.net.preferIPv4Stack=true` via `JAVA_TOOL_OPTIONS`, forcing the JVM onto pure AF_INET4 sockets, so connections to `127.0.0.1` stay IPv4 and `"localhost:PORT"` rules match. `--allow-localhost <PORT>` therefore works for Java, and the old `"*:*"` nuclear option is gone. Overriding `JAVA_TOOL_OPTIONS` via `--pass-env` loses this protection; fall back to `--allow-localhost-any`. On Linux (Landlock) the flag is not injected, as the kernel handles addresses differently.

**`--allow-private-domain` weakens DNS rebinding protection for named domains.** For a domain listed in `proxy.allow_private_domains` (or `--allow-private-domain`), the proxy skips the post-DNS private IP check. That is intentional for corporate intranet services such as `intern.nav.no` that legitimately resolve to RFC 1918 addresses. The accepted risk: if DNS for a listed domain is poisoned or hijacked, a compromised agent could reach arbitrary private hosts on your internal network, not just the intended service. All other proxy checks (port, allowlist, blocklist) still apply. Only list domains you control and whose DNS you trust.

**`proxy.upstream` delegates private-address defense to the upstream proxy.** When
`proxy.upstream` is set, cplt classifies the address *it* resolves for the target
name, then forwards the **name** — not that address — to the upstream in a nested
`CONNECT host:port`. The upstream resolves it again, in its own network and with
its own resolver, and cplt cannot see or pin the address the tunnel actually
lands on. Two consequences follow, and both are accepted:

- A **split-horizon** name that resolves publicly for cplt and privately for the
  upstream passes cplt's resolved-IP guard on the public answer and still reaches
  the private host.
- A name that **does not resolve locally at all** gets no resolved-IP
  classification: `resolve_locally` returns `None`, and on the upstream path that
  is read as "only the corporate proxy can resolve this", so the tunnel is
  forwarded anyway (`classify_resolved`, `src/proxy.rs`).

Everything that does not depend on the resolved address still applies to every
upstream-forwarded target, before the forward happens: the port policy, the
fail-closed allowlist, the blocklist, and the pre-DNS private-hostname gate that
rejects IP literals in a private range and `localhost` / `*.localhost` /
`*.local` names. What does not apply is any guarantee about the *final* IP.

This is deliberate and will not be enforced. Pinning the checked IP — forwarding
`CONNECT 93.184.216.34:443` instead of the name — would break split-DNS and
internal-name resolution, which is the entire reason upstream mode exists. So the
trust boundary in this mode is the upstream proxy and the network segment it
sits on: cplt filters which *names* reach it, and the upstream decides where they
go. Do not use `proxy.upstream` with an upstream you would not trust to enforce
its own egress policy.

**An upstream proxy credential crosses the network in cleartext.** Only the
`http` scheme is accepted for `proxy.upstream`; an `https://` upstream is
rejected rather than silently downgraded, and cplt implements no TLS-to-proxy
path. Userinfo in the upstream URL (`http://user:pass@host:8080`) is base64-encoded
once at startup and sent as a `Proxy-Authorization: Basic` header over a plain TCP
connection to that proxy, on every CONNECT. Anyone who can read that segment reads
the credential; `Basic` is encoding, not encryption. The credential is redacted in
`cplt config show`, in startup output and in `Debug` — that protects the logs, not
the wire.

cplt does not refuse userinfo for a non-loopback upstream, because Basic auth to a
corporate proxy over a trusted internal segment is ordinary and refusing it would
break real deployments. The trust boundary is therefore the network between cplt
and the upstream. Where that segment is not trusted, point `proxy.upstream` at a
loopback forwarder that holds the credential itself, or use a credential-free
upstream that authenticates by source address.

**Derived Linux grants follow symlinks (Landlock).** Landlock rules are attached
by opening each path with `O_PATH | O_CLOEXEC` and **no `O_NOFOLLOW`**
(`src/sandbox_landlock.rs`), and the path derivation that feeds them uses
`std::fs::canonicalize`, which resolves symlinks by definition. A rule therefore
binds to whatever inode the path resolves to at launch, not to the directory that
was inspected when the grant was derived.

That matters for **derived** grants — the ones whose final path cplt composes or
resolves rather than taking verbatim: an `allow_cache_exec` entry, which names a
subdirectory *relative* to the cache root and is what `cplt init` proposes from
what it found on disk; a canonicalized `core.hooksPath`, gitdir or common dir; a
detected tool directory. An attacker who already has write access inside such a
location can replace the named subdirectory with a symlink between one launch and
the next, and the read, write or exec right meant for it attaches to the
attacker's target inode instead.

The condition it needs is real but not small: control of a recognised derived
path, and two launches. It is **not fixed** — there is no `O_NOFOLLOW` open and no
post-open inode verification today. It is stated here rather than claimed away.
Whether macOS shares it has not been established. Seatbelt is known to resolve
symlinks when enforcing *deny* rules — that is what [Symlink attack
protection](#symlink-attack-protection) and its tests cover — but whether an
*allow* rule is re-evaluated per access or captured when the profile is compiled
is a different property, and nothing here tests it. Do not read the deny-side
result as covering the allow side.

**Symlinked tool directories are granted at their target, on both platforms.**
A `HOME_TOOL_DIRS` entry that is a symlink, or sits under one (`~/.cargo ->
/opt/cargo`, a dotfiles-managed home), is resolved at launch and its permissions
are granted on the target: Landlock does this by following the link, and the
macOS profile names the target next to the `$HOME` path, because Seatbelt
matches the resolved path. The `DENIED_HOME_SUBPATHS` credential denies
(`~/.m2/settings.xml` and the rest) are emitted at the resolved path too, so
following the link does not open them. A target is **refused**, with a warning
and no grant at all, when it is inside or contains a credential directory or
hard-denied file, contains a `DENIED_HOME_SUBPATHS` file linked in from another
name (`~/.cache -> ~/dotfiles` with `~/.npmrc -> ~/dotfiles/npmrc`), lies in
cplt's state directory, or is `/`, `$HOME`, an ancestor of `$HOME` or a platform
system root — the same bar a relocated `CARGO_HOME` meets. On macOS a target
the profile cannot name (one containing `( ) " ; \`) is refused the same way.
When an executable tool directory's grant lands in the same tree as a writable
one (`~/.cargo/bin` and `~/.cargo/registry` linked to one directory, or
`CARGO_HOME=~/.cache/cargo`), cplt drops the executable one with a warning,
because Landlock would combine the two grants into a writable, executable tree.
Any other target is granted, including one outside `$HOME`. The
between-launches caveat above applies: whoever can replace a tool directory with
a symlink chooses where its grant lands next time. None of cplt's default grants
makes a tool directory's parent writable; an `allow.write` on one (say
`~/.cargo`) hands that choice to the agent, within the bar above.

**`~/.config/gh/hosts.yml` is readable.** cplt grants `hosts.yml` and `config.yml` read-only, not the whole config directory, including at an absolute `GH_CONFIG_DIR` or `$XDG_CONFIG_HOME/gh` override. `hosts.yml` can hold a plaintext token; gh can instead keep the secret in the OS credential store. Copilot's environment substitute, the guard's one-shot cache, and its exec-token cache are separate channels. With the guard disabled, real gh can answer from whatever credential source the sandbox lets it reach. A compromised agent can exfiltrate any token it can read through permitted network destinations. `--deny-path ~/.config/gh`, or the relocated directory, blocks sandboxed file access where enforced. It does not restrict gh running in cplt's unsandboxed parent, suppress environment or cache handover, or force a native Keychain login.

**The nested denies stop at `node_modules`.** On macOS the project-path denies also match at any depth below a writable root, except inside a `node_modules` directory ([#618](https://github.com/navikt/cplt/issues/618)). Packages ship these names — `thread-stream@4.2.0` contains `.claude/settings.local.json` — and the deny made `pnpm install` fail with `EPERM`, and removing such a package fail too. No supported agent loads its config from inside a dependency directory: they read it from the directory the session opens in and, for some, its ancestors, and nobody opens a session in `node_modules/<pkg>`. The exception also gives the agent nothing new: code under `node_modules` already runs on the host whenever the user runs an npm script or the test suite outside cplt, so an agent that can write there can plant code without any agent config file. The deny at the root and the rules for every other nested directory are unchanged. A workspace package reached through a `node_modules` symlink is still denied, because Seatbelt matches the resolved path. Seatbelt matches the exemption case-insensitively (`Node_Modules` is exempt too), and a `node_modules` directory can serve as a staging area for the moved-in-ancestor trick (move `sub` in, write `sub/.claude/settings.json`, move it back), which already works through `/private/tmp` without this exception (see the `sandbox.deny_nested_git` residuals above). Linux was not affected: the bubblewrap walk that finds nested repositories never descends into `node_modules`.

**A protected config file does not protect the script it names.** The project-path denies cover the *declaration* — `.claude/settings.json`, `.mcp.json`, `opencode.json`, `.pi/settings.json`, `.github/hooks`, `.agents/plugins` — so on macOS an agent cannot introduce a hook or an MCP server that did not exist before. (On Linux under bubblewrap that holds only for paths present at launch, per the caveat above; a declaration file that does not exist yet is not protected until it does.) The denies do not cover what an existing declaration points at. A repository that already ships

```json
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/on-start.sh"
```

or an `.mcp.json` entry running `node ./scripts/mcp.js` has a protected declaration and an unprotected target: the script body is an ordinary project file, writable by design, and it runs unsandboxed on the host at the next session with no fresh trust prompt, because trust is per-directory and remembered. Demonstrated end to end for both a Claude Code hook and an `.mcp.json` target.

This is not closable by a path table — any repo-relative script named by trusted config is the surface, and the set is whatever the repository happens to contain. What bounds it: the route must already exist in the repository, since the agent cannot add a declaration naming a new script — what it rewrites is the body of a script the committed config already invokes; and the same server-side controls that bound every other project-file change apply, since the rewritten script has to survive review like any other diff. If a repository ships such a hook and runs untrusted agents against it, treat the hook script as security-relevant code and review changes to it accordingly.

**`block_auth_token` is best-effort, not a same-UID boundary.** With gh guard and `block_auth_token` enabled (both the default), cplt withholds `GH_TOKEN` from the environment (unless you exported it to Copilot, set `inject_token`, or the Keychain substitute carries it), caches the token to `$SCRATCH/.gh-token` (mode `0600`), serves it once via the `gh` wrapper's `gh auth token` callback, and deletes the file after the first read. That keeps the token out of every child's `/proc/*/environ`, and the deletion narrows the exposure window. It does **not** make the token confidential against an adversarial agent. The scratch dir *is* the agent's `TMPDIR`, and the `gh` wrapper runs as the agent's own UID inside the sandbox, so anything the wrapper can read, the agent can read. A same-UID `deny` rule would be illusory and would break the legitimate wrapper read, so cplt does not add one. An agent that `cat`s `$TMPDIR/.gh-token` before the legitimate consumer still gets the token. Treat `block_auth_token` as reducing accidental and env-based leakage, not as a boundary against a hostile agent. The same holds for the exec token, `$TMPDIR/.gh-exec-token`: the `gh` wrapper reads it on every call, so it is never deleted during the session.

A repo `deny.env` naming `GH_TOKEN` removes that environment variable and suppresses both `.gh-token` and `.gh-exec-token`. With `block_auth_token` enabled, the wrapper then has no one-shot token to serve. This is not a credential-wide denial: `GITHUB_TOKEN` or `COPILOT_GITHUB_TOKEN` may survive, substitution or opt-in injection can use another permitted name, and a retained Keychain grant or readable `hosts.yml` can remain a credential source.

Denying only `GITHUB_TOKEN` or `COPILOT_GITHUB_TOKEN` leaves cache eligibility open. A soon-to-be-denied child token does not suppress the exec cache. Injection selects the first of `GH_TOKEN`, `GITHUB_TOKEN`, `COPILOT_GITHUB_TOKEN` that is not denied. These are the current channel-specific rules, not a uniform "no GitHub credential" policy.

Both cache consumers use `__CPLT_GH_TOKEN_DIR` to locate the actual producer
scratch directory, including with `--pass-env TMPDIR`. Launch clears an ambient
locator and sets its own only when caching a retrieved token. A wrapped process
without that locator does not fall back to a stale token under TMPDIR or TMP.
This preserves cache-channel denial; it is not a boundary against a same-UID
agent that can read or modify its own environment and scratch files.

The one-shot cache can supply Copilot when no exported token survives and no gh-token substitute resolves. The exec cache supplies sandboxed gh separately when eligible. Denying `GH_TOKEN` suppresses both caches; it does not guarantee that every credential source is unavailable.

*Possible mitigation:* a repo-scoped MCP proxy or a fine-grained PAT that limits token scope to the current repository. See issue #4.

**`--allow-browser` grants a sandbox escape, and it cannot be scoped.** The flag (`sandbox.allow_browser`, off by default) emits `(allow lsopen)` so an agent can hand an https URL to your browser during OAuth sign-in. Launch Services starts the target through **launchd, outside the Seatbelt profile**, so what the flag actually grants is "launch any application on this machine, unsandboxed". `open -a Terminal script.sh` is the whole exploit. Wrapping `open` to accept only `http://` and `https://` was investigated for [#251](https://github.com/navikt/cplt/issues/251) and rejected on two measured facts.

- **`lsopen` has no filter in SBPL** — no URL, no bundle id, no path. Every profile under `/System/Library/Sandbox/Profiles` that uses the operation emits it bare, exactly as cplt does. There is no narrower form to write.
- **The grant is reachable without the `open` binary.** A PATH shim only shadows a name; `LSOpenCFURLRef()` calls Launch Services directly. Measured on macOS 15 with a ten-line C program linking CoreServices, compiled outside the sandbox and run inside a real cplt session against `file:///System/Applications/Calculator.app`: **without** `--allow-browser` the call returned `-54` and launched nothing; **with** it, the call returned `0` and Calculator was running outside the sandbox. No `open` process existed in either run. Separately, the blanket `(allow process-exec)` leaves `/usr/bin/open` executable by absolute path, which a PATH shim never sees.

So a shim would constrain only an agent that types `open` politely, which is not the threat model, and shipping one would misrepresent the flag as bounded. cplt does not ship one. Leave the flag off and prefer signing in outside cplt. Copilot's default desktop login can launch a browser; explicit `copilot login --device-code` lets you open the URL yourself without this grant. If a sign-in flow needs the grant, restore its actual prior value and config scope afterwards; use `--unset` only if the key was originally unset there. `cplt config set` treats the key as dangerous and asks for confirmation, and `detect` never proposes it.

**The gh/git guards are a best-effort command filter, not a kernel boundary.** The "gh guard" and "git guard" rows in the threat-model table describe command-level interception. Four properties bound what they can promise.

- **On by default, and both enforce.** Both guards default to `enabled = true` and to `mode = "block"`. The gh guard blocks with default-deny unknown subcommands, scope check, `block_auth_token`, `allow_api_write = false`. The git guard blocks too, scoped by `protect_default_branch_only = true`: a push to `main`/`master` is refused, a feature-branch push is not, and `prevent_push`/`prevent_force_push` are on underneath. Two guards in one product with opposite defaults was the earlier state, and the softer one covered the operation with the worse blast radius (#386). `--preset strict` drops `protect_default_branch_only`, so every push is refused; `git_guard.mode = "warn"` goes back to observing. Opt out of either with `--no-gh-guard` / `--no-git-guard` or `enabled = false`; `--preset permissive` and `--preset full-trust` turn both off.
- **PATH-shim enforcement.** The guards write `gh`/`git` shims into a scratch `bin/` dir and prepend it to `PATH`; the shim calls back into cplt for a policy decision before `exec`ing the real binary. The real `/usr/bin/git` and `/usr/bin/gh` are untouched, so any agent that invokes the binary by **absolute path** (`/usr/bin/git push`), **escapes the alias** (`\git`, `env git`), **runs the real binary under another name** (`ln -s "$(command -v git)" g && PATH=$PWD:$PATH g push`), **resets `PATH`**, or **shells out from another runtime** (`subprocess.run(["/usr/bin/git", "push"])`) bypasses the guard entirely. Command classification (force-push detection, scope checks, `gh auth token` blocking, DELETE blocking) therefore only constrains a *cooperative* agent, not an adversarial one.
- **Repository scope is pinned at sandbox startup.** Before the agent starts, cplt invokes the pre-resolved Git binary and reads only the local `remote.origin.url` of the project root and of every repository named with `--repo-dir` / `sandbox.repo_dirs`, with config includes and inherited `GIT_*` variables disabled. A named root whose origin is not a GitHub URL is warned about and left out. That verified scope set is baked into the shim. A successful check sets a host-qualified `GH_REPO`, clears `GH_HOST`, and rejects conflicting hostname flags before executing `gh`; failing to determine startup scope blocks the command. Runtime working directories, nested repositories, mutable Git configuration, and environment overrides cannot retarget the check.
- **`gh pr merge` is refused unless `gh_guard.allow_pr_merge` is on (default off).** With it on, the shim lets a merge through only when all of these hold at merge time: the pull request is in the scope set; its author is the account `gh` is logged in as; and an active ruleset on its base branch, one that account cannot bypass (`current_user_can_bypass = "never"`), requires at least one approving review and dismisses it on a new push (`dismiss_stale_reviews_on_push` or `require_last_push_approval`). Required status checks do not count, because the pull request's author controls what CI reports. The facts come from read-only `gh` calls made by the shim with the user's token (`pr view`, `GET /user`, `GET /repos/{o}/{r}/rules/branches/{base}`, `GET /repos/{o}/{r}/rulesets/{id}`). Any lookup error refuses. `--admin` is refused in every spelling, and so is any flag the shim does not know `gh pr merge` to take. The shim then runs `gh pr merge <number> ... --match-head-commit <sha>` with the number and head commit it checked, so a bare `gh pr merge` is not resolved from the current branch a second time, and an agent-supplied `--match-head-commit` naming another commit is refused. GitHub, not cplt, then enforces the rules on the merge itself. Limits: classic branch protection is not read, so a branch protected only that way is refused; the lookups run in the agent's environment, so an agent that can redirect `gh`'s API traffic can forge the answers; and the base branch, or its rules, could be changed between the check and the merge. `gh api` writes to `repos/{o}/{r}/pulls/{n}/merge` and `repos/{o}/{r}/merges` are refused even with `allow_api_write`, and the merge mutations (`mergePullRequest`, `enablePullRequestAutoMerge`) are not in the GraphQL allowlist and stay refused. That closes the direct merge routes, not every way to move the base branch: `allow_api_write` still permits a contents `PUT` with `branch=main`, a `git/refs` `PATCH` and `merge-upstream`. Rulesets on the branch stop those, not the shim. In `mode = "warn"` or `"audit"` a refused merge still runs, as every refused command does in those modes.

**GraphQL reads are allowlisted.** `gh api graphql` queries must start at `repository(owner:, name:)` for a repository in scope (#414), and every field below that must be on a fixed allowlist, checked against the type it is selected on. What a query can read is pull requests of that repository (number, title, state, URL, draft flag, branch names, ID), their review threads (ID, resolution and outdated state, path, lines, diff side), each thread's comments (ID, body, URL, creation time, path) and a comment author's login, plus pagination fields and `__typename`. Fragments of any kind are refused, so a comment author cannot be read as a `User`. Nothing on the list leads to another repository, a file, the viewer, or a user's or organization's data. The three allowed mutations are checked more tightly, since each target node is looked up and must belong to a repository in scope. The lookup runs inside the sandbox with the agent's own `gh`, so like the rest of the guard it binds a cooperative agent, not a hostile one.

The guards raise the bar against accidental and prompt-injected-but-cooperative misuse. They do not substitute for the kernel-enforced filesystem and exec isolation that holds against an adversarial agent. On the *network* side, proxy-forced mode (issues #53 and #117) is the kernel-backed complement: it forces all connections through the cplt proxy at the packet level (DNS lookups through the system resolver are the exception, see DNS tunneling below) rather than via tamperable `HTTPS_PROXY` env vars, so a bypassed `git push` or `gh api` write still has to traverse the proxy. Command-level intent (`GET` vs `DELETE` to `api.github.com`) stays invisible to a CONNECT proxy, so the guards and the proxy cover different layers.

**DNS tunneling is the one channel we cannot inspect.** Outside `proxy.forced` DNS is unrestricted on both platforms. Under `proxy.forced` direct UDP DNS is blocked on both, but lookups through the system resolver still work on macOS.

- **macOS:** by default the profile allows the system resolver socket, `/private/var/run/mDNSResponder`, which nearly everything uses to resolve names. Lookups of any name therefore still work under `proxy.forced` and a fail-closed allowlist. The query leaves the machine through the system resolver, not the proxy, and does not appear in the proxy log. The allowlist limits which hosts the agent can connect to, not which names it can look up. **`proxy.deny_dns = true`** (opt-in, [#653](https://github.com/navikt/cplt/issues/653)) closes this under `proxy.forced`: the profile drops the socket and denies the mDNSResponder Mach services (`com.apple.dnssd.service`, which Network.framework and NSURLSession resolve through, and its `com.apple.mDNSResponder*` siblings). `proxy.forced` itself denies `com.apple.nsurlsessiond`, which would otherwise run a background `URLSession` transfer, name lookup included, outside the sandbox and the proxy. Only the proxy then resolves names. Tools that resolve before they use the proxy stop working; see [DNS lockdown](docs/known-impacts.md#dns-lockdown-proxydeny_dns-macos). What it does not close: system daemons that make network requests on the agent's behalf resolve outside the sandbox. `trustd`, which TLS needs, looks up and fetches the AIA, OCSP or CRL URLs of any certificate the agent has verified, so a crafted certificate still sends a chosen name to DNS.
- **Linux:** under `proxy.forced`, seccomp allows only TCP sockets for IPv4 and IPv6, so direct UDP DNS is blocked. A host whose `nsswitch.conf` uses nss-resolve (varlink over `/run/systemd/resolve/io.systemd.Resolve`) or nscd reaches that socket over AF_UNIX, which seccomp allows and Landlock gates only from kernel 7.1 (ABI v9), so lookups probably still work there; we have not tested it.

If you need a hard egress boundary on macOS, turn on `proxy.forced` with `proxy.deny_dns`, and monitor DNS or put a network-level control in front of the machine for what remains.

What limits the damage: bandwidth is ~15 KB/s at best given the encoding overhead in subdomain labels, it needs an attacker-controlled authoritative DNS server, the most valuable targets (credentials, tokens, keys) are kernel-blocked from being read, and DNS monitoring detects it by the high-entropy subdomain queries to unusual domains.

*Possible mitigation:* route DNS through a local resolver that logs and rate-limits queries, or block DNS entirely and use a pre-configured resolver for known domains. Practical impact is low, since credentials are already inaccessible.

**Terminal injection (`TIOCSTI`) is denied by policy, not by either kernel.**
`TIOCSTI` pushes a byte into a terminal's *input* queue, so it is command
execution in whatever shell reads that terminal next — including the shell
outside the sandbox that cplt was launched from. Neither platform blocks it for
free, and the wording here has been wrong in both directions before.

- **macOS.** XNU permits `TIOCSTI` on the caller's **own controlling terminal**;
  it was reproduced succeeding outside the sandbox. It refuses the ioctl with
  `EPERM` on any *other* tty, which is why a peer `/dev/ttysNNN` is not an
  injection target even under the `--allow-write /dev` break-glass — that flag
  restores output forgery and input capture on peer terminals, not injection into
  them. What denies the ioctl inside a cplt session is the profile's
  `(deny default)`. It is **not** `(allow file-ioctl)`, which cplt emits
  unconditionally and which does not lift the default deny here. Any statement
  that "the macOS kernel blocks TIOCSTI" is wrong; the control is Seatbelt.
- **Linux.** The kernel gate is `CONFIG_LEGACY_TIOCSTI`, which is `default y`
  upstream. Fedora, Debian and Arch disable it; self-built kernels and many
  vendor and cloud kernels do not, and kernels before 6.2 predate the gate and
  permit `TIOCSTI` with no capability at all. So on Linux the availability of
  the primitive is a property of the kernel the user happens to be running, and
  cplt cannot assume it is absent. Landlock does not help: it has no rule that
  reaches an ioctl on an inherited descriptor. What denies it is the seccomp
  filter: `build_seccomp_filter` in `src/sandbox_landlock.rs` (step 2b) returns
  `EPERM` for any `ioctl` whose request is `TIOCSTI` or `TIOCLINUX`, on any
  descriptor. It is applied in every mode, with or without Bubblewrap
  (GHSA-q3p2-6x2x-8w8w).

The exposure is the same on both platforms and is not about peer terminals at
all: `/dev/tty` and the inherited descriptors 0/1/2 name the agent's own
controlling terminal, and that terminal is the user's shell.

**Reconnaissance leaks basic host info.** Hostname, IP address, OS version, and the sanitized subset of env vars are readable by any code inside the sandbox. This is unavoidable, because Copilot itself needs the information.

*Possible mitigation:* a future hardening category could mask the hostname and inject synthetic env values, at the risk of breaking tools that depend on accurate system info. Low priority, since recon without credential access has little value.

**Key files are denied by exact name by default, not by extension.** The default name patterns for key files block a file named exactly `.pem`, `.key`, `.p12`, `.pfx` or `.jks`. They do not block `server.pem`, `tls.key` or `keystore.jks`, which is where keys usually live, so an agent can read and overwrite those on macOS. `sandbox.deny_key_files_by_extension` (off by default under the staged-rollout rule) denies any file name that ends in one of those extensions inside the project and every other granted tree. It is scoped to those trees rather than global so the system CA bundles (`/etc/ssl/cert.pem`) stay readable. Like the exact-name patterns, it is lifted for read inside the extracted dependency stores (`~/go/pkg/mod`, `~/.cargo/registry`), and a `--deny-path` inside or above a store still wins over that carve-out (#597). On Linux neither form applies: Landlock cannot deny a file by name pattern.

**Project source code is readable and writable.** The agent needs read/write access to the project directory. That is its job. A compromised agent could exfiltrate source over HTTPS on port 443.

*Possible mitigation:* a read-only project mode (`--read-only-project`) for review-only workflows. Outbound bandwidth tracking could flag bulk exfiltration, meaning large POSTs relative to Copilot's normal API pattern, but that needs deep packet inspection.

**`~/.copilot/` session history is broadly accessible.** The sandbox grants read/write to all of `~/.copilot/`, including the session store database (`session-store.db`) holding every past conversation and `session-state/` with per-session artifacts. Copilot's runtime manages these from inside the sandbox and needs the access. A compromised agent could read past conversations to extract business logic, architecture decisions, or referenced credentials.

*Possible mitigation:* `--deny-path ~/.copilot/session-state` blocks access to other sessions' artifacts, at the cost of cross-session features. Scoping the session store to the current session would require changes to Copilot's runtime, since it is a single SQLite file.

Denied credential paths and filtered environment variables reduce what can be exfiltrated. Deliberately granted auth files, environment tokens, guard caches and any Keychain items reachable under a retained grant remain exposed to the agent, alongside project source code.

#### Managed worktree root (`sandbox.allow_git_worktrees`)

Off by default (#531). When on, the session gets one more project-grade tree:
`~/.cplt-worktrees/<id>`, read, write and execute, so sub-agents can run
`git worktree add "$CPLT_WORKTREE_ROOT/<name>"`. What that grants and what it
does not:

- **One repository's root, never the parent.** `<id>` is the first 128 bits of
  SHA-256 over the canonical Git common directory, so every worktree of one
  repository shares it and a second clone does not. `~/.cplt-worktrees` is not
  granted, so other repositories' roots stay unreadable, unwritable and
  non-executable. The path is derived, not configurable.
- **User config only.** `.cplt.toml` cannot set or propose the key. A repository
  cannot give itself a new executable tree outside its checkout.
- **Steering and path tricks fail the launch.** The common directory is accepted
  only in the two layouts Git writes (the gitdir itself, or
  `<common>/worktrees/<name>`), so a planted `commondir` cannot point the launch
  at another repository's root. `~/.cplt-worktrees` and the root must be real
  directories owned by the user (set to mode 0700), and the canonical path must
  equal the expected one. The directories are opened `O_NOFOLLOW |
  O_DIRECTORY` and their owner and mode are checked and set through that
  descriptor. These checks run on every launch, in case the root was replaced
  between sessions. Inside a session the root's name is pinned
  (`file-write-unlink` on its exact path), so the agent cannot move it away.
  A `CPLT_CONFIG` inside the root is refused, like one inside a named
  repository.
- **No new trust.** The root is not a repository and is not added to the gh
  scope, the audit's repository list, or the trust store. Approval stays keyed
  on the repository (#527), so launching from a managed worktree uses the
  existing approval and creates none.
- **`cplt worktree add`: the parent makes the checkout.** The sandboxed
  `cplt worktree add <name> <ref>` sends one request to a per-session Unix
  socket, `$CPLT_WORKTREE_SOCKET`. The sandbox may connect to that one path
  (`network-outbound`, `path-literal`) and to nothing else. The socket is in a
  short random directory under `/private/tmp`, mode 0700, using the existing
  private socket-directory guard. Its exact directory has a write deny,
  including rename and unlink; no directory read or execution grant is added.
  Socket length is independent of HOME. No secret: the client is
  the sandboxed agent, the authority the sandbox already has. The parent
  checks out `<ref>` detached into `~/.cplt-worktrees/.staging`, which the
  sandbox cannot write, then validates the tree and renames it into the root
  with `renameatx_np(RENAME_EXCL)`. A name that exists is refused, never
  replaced. Rules:
   - The ref is resolved with an explicit, launch-pinned common git directory,
     never by rediscovering the launch checkout. Both `GIT_COMMON_DIR` and
     `--git-dir` name it. Directory identities are checked before use. No fetch,
     no remote: `GIT_NO_LAZY_FETCH=1`, `protocol.allow=never`, and an empty
     `GIT_ALLOW_PROTOCOL` also deny per-protocol config overrides.
   - Before the agent starts, bootstrap Git queries freeze the launch checkout's
     HEAD and its protected tree entries. They are hardened content-free queries;
     tree enumeration explicitly pins the common directory. The snapshot stays
     private and contains path bytes, regular-file mode and blob id, never file
     contents. Replacement objects are disabled throughout broker Git use.
     Launch HEAD must name a commit; tree queries fail closed at 1 MiB or 200,000
     entries. No incomplete snapshot is accepted.
     HEAD alone is not approval: protected files in the launch checkout must
     exist with the recorded raw bytes and executable modes. The bootstrap
     opens ancestors and files no-follow, copies at most 1 MiB per file into
     private staging and hashes those copies without filters. A mismatch,
     unborn HEAD or unavailable snapshot disables the broker with a warning
     and no socket variable; the session's existing managed-root grant remains.
     Launch name validation is projected onto tracked HEAD entries and their
     ancestors. Local/ignored config is not trusted or propagated; dependency
     directories absent from HEAD are not traversed. The staged requested tree
     still receives the full name scan, including every tracked alias.
   - Every request-time broker Git child, including config queries and ref resolution, runs
     under `/usr/bin/sandbox-exec -p` with an immutable copy of the final session
     profile. Without that profile, requests fail closed. Kernel read denies
     apply to symlinked refs, config includes and recursive object alternates.
     Checkout adds read/write only for this request's private staging directory,
     with execution there denied. It grants no additional common, base or
     source-directory access. Private config prevents executable drivers;
     Seatbelt prevents publishing data the caller cannot read.
     The agent profile explicitly denies staging reads and writes even when
     HOME is under temp or a user grant overlaps the base. Literal ancestor
     write denies pin the base against rename without blocking managed-root
     descendants. These rules are reapplied after OpenCode v2 amendments and
     before the broker captures the final profile. Only a broker Git child gets
     the exact random staging exception, with execution still denied there.
     The host opens the private index no-follow/nonblocking and requires a
     regular file with link count one before copying it into shared admin.
   - Requested protected paths must equal the frozen launch snapshot, derived
     from `PROTECTED_IN_ROOT` with its subtree and nested flags. Matching uses
     conservative ASCII case folding; comparison preserves exact path bytes,
     mode and blob id. Additions, deletions, changes and case renames refuse the
     request before checkout. Symlinks and gitlinks at protected paths or their
     ancestors are refused. After checkout, raw protected bytes are hashed with
     filters disabled and compared again: attributes such as `ident` must not
     transform a protected file. Different protected content requires preparing
     the worktree outside cplt, with no new approval path.
     ASCII matching is only the early tree check. At launch and before publish,
     every root/nested protected spelling is looked up through the filesystem,
     component by component without following symlinks. Its actual directory
     entry must use the exact declared spelling, and every protected file must
     occur in the approved snapshot. This rejects APFS aliases such as
     `ſettings.json` and `hooKs` without rejecting unrelated Unicode names.
  - Hooks are off (`core.hooksPath=/dev/null`). A `filter.*` entry in any
    config scope, including the user's global config, refuses the request,
     because private checkout cannot reproduce filtered content. The refusal
     names keys only. It is not a security barrier: checkout uses private
     config, HEAD, index and objects with an alternate pointing to the pinned
     common objects. `git read-tree --reset -u <commit>` runs in private staging
     with `GIT_CONFIG_GLOBAL=/dev/null` and `GIT_CONFIG_NOSYSTEM=1`; no common
     config or linked-worktree admin is loaded. Config edits after preflight
     cannot install filters or promisor fetches in this checkout. Alternates
     can load further objects, not config. Git parsing corrupt objects remains
      an accepted dependency risk.
     This is not a promise of raw-byte fidelity for ordinary files: Git
     attributes may transform them, and private config ignores user checkout
     settings. Only protected files receive the raw-byte equality check.
   - Refused in the tree: a symlink that is absolute, dangling, uses `..` after
     a named component, or resolves outside the
    worktree, a `.git` other than the pointer, and a bare repository layout
     (`HEAD` with `objects` and `refs`, or with `commondir`). The tree must hold
      at most 200,000 entries.
     Bare markers are case-insensitive and counted regardless of file type,
     including executable regular files and symlinks, using the same predicate
     as the launch/exit checks. Private metadata uses `.git-admin`, a spelling
     excluded from public names, so names such as `git` and `GIT` cannot collide.
  - The `.git` pointer is written as `gitdir: <common>/worktrees/<id>`, and the
     admin `gitdir` back link is set to the final path before the rename.
     Admin directories use random `cplt-<hex>` names, `mkdirat` and no-follow
     directory descriptors. HEAD, commondir, gitdir and index use exclusive
     no-follow opens; no existing file is truncated. No host git runs against
     this shared admin directory after installation.
  - No branch is created. A failed request removes the staging directory and
     its own admin files through the saved descriptor. Only an empty directory
     whose inode still matches is removed. Agent namespaces are never deleted
     recursively.
  - Requests are served one at a time. A base lock (`~/.cplt-worktrees/.lock`)
    serialises sessions. Each request line is at most 4 KiB, each reply is at
     most 4 KiB. Reading the request has an absolute 10 s deadline. One 60 s
     operation deadline covers nonblocking lock acquisition, all Git commands,
     output draining and validation. Output is capped at 1 MiB per stream.
     Shutdown cancels request reads, lock waits and commands. The client waits
      70 s for a reply; socket writes have a 10 s timeout.
     Private staging deletion and failed-job cleanup run outside that operation
     budget. Filesystem stalls and large cleanup work can extend shutdown time;
     the 60 s budget is not a comprehensive wall-clock bound.
     Queue time is outside each request's operation budget. A 70 s client
     timeout does not cancel queued work; diagnostics tell the caller to check
     the destination before retrying.
  - Plain `git worktree add` in the sandbox is unchanged: it runs git directly
    and gets none of the checks above. The launch-time and exit-time link
    checks still cover what it creates.
  - Not covered: a session killed mid-request (`kill -9`) leaves its socket
    directory, and any half-made staging directory and admin dir, behind.
    Nothing outside the private socket directory, `.staging` and
    `<common>/worktrees` is touched,
    and `git worktree prune` clears an admin dir whose path is gone. A stale
    staging directory is not removed automatically.
- **No isolation between sub-agents.** All worktrees in a session share one
  grant. A sub-agent can write every other sub-agent's worktree, and every
  sub-agent can still write the launch checkout. The root keeps parallel work
  on separate branches and directories; it is not a security boundary between
  agents.
- **Protections.** On macOS the per-root denies apply at every depth under the
  root: `.github/hooks`, `.claude/settings.json`, `.cplt.toml`, `.mcp.json`
  and the rest of `PROTECTED_IN_ROOT`, and the rename pins on their ancestors.
  The shared `.git/hooks` and `.git/config` keep their existing denies, and
  `worktrees/<name>/config.worktree` is denied by suffix. Verified by kernel
  tests in `tests/e2e_projects.rs`.
- **Worktree links: kernel pins plus a strict check at launch and exit.** Two
  files decide which config and hooks Git on the host reads for a worktree,
  and the agent can write both. `<common>/worktrees/<id>/commondir` aimed at
  `<root>/x/` would make Git read `<root>/x/config`, which the agent can write
  (`core.fsmonitor` runs on the host). A `<root>/<name>/.git` pointer aimed at
  `<root>/g` does the same through `<root>/g/config` and `<root>/g/hooks`.
  What the kernel blocks: rewriting a `commondir` in place
  (`file-write-data`); rewriting or unlinking any `<root>/.../.git` (the
  nested-gitdir rules every writable root gets); and creating a `.git`, in
  any letter case since on case-insensitive APFS Git opens `.GIT` for `.git`,
  at `<root>/.git` or at `<root>/<name>/<anything>/.git` (a new file, a
  symlink, a mkdir and a rename onto the name). What it does not block:
  deleting and recreating a `commondir`, creating a new admin directory,
  moving a worktree aside and writing a new `<root>/<name>/.git`, and moving
  in a directory that already holds a `.git`. **Deny residual:** the create
  rule only sees the name being created. `mkdir -p
  /private/tmp/stage/sub/.git && mv /private/tmp/stage/sub <root>/x/sub`
  creates only `sub` under the root, so it succeeds, and the planted `.git`
  is there. The deny does not block that plant; the walk below finds it. Nor
  can a rule express a bare-repository layout or a symlink out of the root.
  Because unlinking `<root>/<name>/.git` is denied, **`git worktree remove`
  fails inside cplt.** It gets far enough to delete the worktree's files and
  its admin directory, leaves the `.git` pointer, and the next launch refuses
  to start until that directory is deleted and `git worktree prune` is run.
  Remove worktrees outside cplt; the agent brief says so.

  The check compares exact text rather than following links, because a link
  that resolves correctly through a symlink today can be re-aimed tomorrow by
  changing the symlink. At every launch with the key on, and at session end,
  cplt requires for every admin directory `<common>/worktrees/<id>` that
  `commondir` reads exactly `../..` and `gitdir` names an existing regular
  `.git` file by an absolute path with no symlink, `.` or `..` in it
  (`<root>/<name>/.git` when it is inside the root). Both must be regular
  files, opened without following symlinks. Then it walks the whole root.
  The only `.git` allowed, in any letter case, is `<root>/<name>/.git` as a
  regular file with exactly that name that reads exactly
  `gitdir: <common>/worktrees/<id>`, with no symlink on that path, and whose
  admin directory's `gitdir` reads exactly `<root>/<name>/.git`. Also
  reported:
  - a bare-repository layout in any directory: `HEAD` with `objects` and
    `refs`, or `HEAD` with a `commondir`, of any file type (Git checks
    `objects` and `refs` with `access(X_OK)`, which an executable regular
    file passes);
  - anything directly in the root that is not a directory;
  - any symlink below the root, dangling or not, unless it stays inside its
    own worktree: its target text, joined to the link's directory and
    normalised without following anything, lies inside the worktree (a `..`
    is accepted only before the first name), and it resolves inside the
    worktree today. Resolving inside is not enough on its own:
    `wt/l -> /private/tmp/s/d` with `/private/tmp/s -> wt` resolves inside,
    and re-aiming `/private/tmp/s` later, outside the root where nothing
    checks it, sends Git in `wt/l` to a planted repository. A link met on
    the way is inside the worktree and held to the same rule, so nothing
    outside is traversed. Links that stay inside, like npm's
    `node_modules/.bin/x -> ../pkg/bin/x` through a workspace link, are
    allowed.

  Anything it cannot read and a tree past its bounds (64 levels,
  `sandbox.worktree_walk_max_dirs` directories, 100 000 by default) is a
  finding, and the launch refuses to start. At session end it runs the same
  check and prints an error naming each directory not to run Git in. That
  error is advisory: nothing stops Git from running there if you do.

  **With the key off**, the session is not granted the root, but it can
  still rewrite a worktree's `<common>/worktrees/<id>/commondir` in place:
  that deny is part of the key-on profile only, so the key-off profile stays
  exactly as on main, where any linked worktree's `commondir` is writable the
  same way. So whenever this repository's root exists, cplt runs the same
  check at launch and at session end with the key off too, and prints the
  same error. It does not refuse the launch, since the session grants
  nothing in the root. A root it cannot inspect (a permission error on
  `~/.cplt-worktrees` or the root) or a repository whose common directory
  cannot be established is reported, not treated as no root. Submodules inside a
  managed worktree are refused by the same rules. The strict text also
  refuses worktrees Git wrote with relative paths
  (`worktree.useRelativePaths`); turn that option off for this repository.
- **The window after the session-end check.** The check runs when the agent's
  process has exited: after the audit's settle wait for its descendants (at
  most two seconds) when the change audit or `--observe-domains` runs, and at
  once otherwise. A descendant that detaches, or outlives that wait, can plant
  in the root after the check, and nothing reports it until the next launch
  runs the check again. cplt does not kill the session's process tree; see
  the settle-probe notes in `src/audit.rs` on why a process group is not used.
  When the audit runs and the tree has not settled, the audit's own warning
  says processes were left running.
- **macOS only.** On Linux the launch fails with the key on, and `config set`
  refuses to turn it on. Landlock cannot subtract a path from the granted
  root, and bubblewrap re-binds only paths that exist at launch, at fixed
  depths, never `<root>/<worktree>/<rel>`. So nothing inside the root would
  be kernel-enforced.
- **Residuals.** Everything written to the root outlives the session: cplt
  never deletes worktrees or branches. The agent can empty the root or plant
  files you later run outside cplt, the same as in the project directory. The
  end-of-session audit does not inspect the worktrees' contents; it prints a
  line saying so.


#### Keychain access is all-or-nothing

The macOS Keychain grant is two SBPL file rules on `~/Library/Keychains` plus the
blanket `(allow mach-lookup)` that reaches securityd. **SBPL cannot narrow it to
one keychain item.** There is no `keychain` operation in the Seatbelt profile
language — `sandbox-exec` rejects `keychain`, `keychain-access`,
`keychain-access-group` and `security-item-read` as unbound variables — and
per-item arbitration happens inside securityd, past the sandbox boundary. So the
choice is the whole login keychain or none of it.

What the grant reaches is bounded by each item's own ACL, not by cplt: an item
whose ACL allows all applications, trusts `/usr/bin/security`, or was set to
"Always Allow" comes out silently. On a developer machine that is a lot more than
the agent's own token — measured on one, the readable set included `gh:github.com`,
`Bitwarden`, `bw_session`, `GnuPG`, and several `* Safe Storage` items. Items
gated on Touch ID or a password are not silently extractable.

Verified by execution: denying only the two file rules is enough. Under a profile
that is otherwise `(allow default)`, `security find-generic-password -s
"Claude Code-credentials" -w` returns the 510-byte credential (exit 0); add
`(deny file-read* file-write* (subpath "$HOME/Library/Keychains"))` and the same
command fails with `SecKeychainSearchCopyNext: The specified item could not be
found in the keychain` (exit 44). Blocking securityd's Mach service instead is
neither necessary nor sufficient on its own.

**On for Copilot and Claude Code, off for the others.** One config key gates the
trade, `sandbox.keychain_substitute`. Unset, it is on for Copilot and Claude Code
and off for every other agent. An explicit value applies to every agent:

```toml
[sandbox]
keychain_substitute = false   # keep the Keychain grant, Copilot included
```

Copilot's default was enabled after the one-shot gh-token test described below.
When no exported substitute resolves and stored gh retrieval fails, prints
nothing, or has no trusted gh, the grant stays. Other token channels are
independent of that decision. Claude Code is on by default for the same
reason (#695): it drops the grant only when `CLAUDE_CODE_OAUTH_TOKEN` is set,
and Claude Code then authenticates from that variable alone (see below). Without
the variable the grant stays, so nothing changes for a Claude user who has not
run `claude setup-token`; `cplt --agent claude check` suggests it while the
grant is in place. With the key `false`, the Keychain grant is exactly what
`needs_keychain()` says, for every agent, as in every release before the key
existed. It stays off for the other agents because of the shape of the failure:
if the trade misjudges an agent, the user can neither authenticate nor recover
*from inside the sandbox*, since the recovery path is the credential store the
trade just removed. That is what PR #173 hit, and what the
first Antigravity verification for this change turned out to be — it passed only
because a stale fallback file happened to exist on the test host. Nobody's
authentication should change until they ask for it.

**Copilot editor launchers (#753).** A VS Code-provided launcher can require
the Keychain even with `GH_TOKEN` supplied. On macOS cplt refuses a recognized
editor launcher when substitution is active and directs the user to install
standalone Copilot. Binary resolution prefers standalone installs over both
the older `copilotCLIShim.js` scripts and launchers under
`github.copilot-chat/copilotCli`. The Keychain deny is unchanged; cplt never
restores the grant to make an editor launcher work. `doctor` reports the same
refusal. See [known impacts](docs/known-impacts.md#copilots-vs-code-launcher-and-keychain-substitution).

**If your agent cannot authenticate with the key on:** setting
`sandbox.keychain_substitute = false` restores the broad Keychain grant on the
next macOS run. It does not stop exported Copilot tokens or
`gh_guard.inject_token` from taking precedence. To test Copilot's native login,
also set `gh_guard.inject_token = false` and clear `COPILOT_GITHUB_TOKEN`,
`GH_TOKEN` and `GITHUB_TOKEN` in a subshell. gh file/cache sources can still be
available, so success alone does not identify the source. Restore each setting
to its actual prior value and scope; unset it only if it was originally unset
there. See [the recovery sequence](docs/known-impacts.md#the-same-vault-prompt-on-macos).
If the stored login is missing, sign in with the standalone agent outside cplt.

**What the key does when it is on.** Per agent:

| Agent | Grant dropped when (Copilot and Claude Code by default, others with the key `true`) | What the agent holds instead | Refresh |
|---|---|---|---|
| Copilot | A nonblank exported token survives `deny.env`, or stored gh retrieval succeeds into a permitted name without a detected account mismatch | that GitHub token, in the environment | cplt does not renew it; Copilot's API/session-token renewal under this handover was not established |
| Claude Code | `CLAUDE_CODE_OAUTH_TOKEN` is set | that OAuth token | none — see below |
| Antigravity | `~/.gemini/antigravity-cli/antigravity-oauth-token` holds a complete token (including `project_id` or `user_tier` for GCP auth) | that file | refreshes into that file |
| goose | never (provider-dependent) | — | some providers refresh through the keyring mid-session |

The trade is not free. Whole-Keychain read+write is exchanged for a full OAuth
token sitting in the agent's environment, readable by every process it spawns and
exfiltratable over the permitted HTTPS egress. That token is narrower than the
keychain but it is not narrow: `CLAUDE_CODE_OAUTH_TOKEN` is a working Anthropic
credential for the account, and Copilot's `GH_TOKEN` carries every scope `gh` was
granted (typically `repo` and `workflow`). What changes is blast radius — one credential the
agent was going to use anyway, instead of every credential the user owns.

That variable is **not** in `ENV_ALLOWLIST` and does not match any allowlisted
prefix, so it is not something the sandbox passes through: it is forwarded by
`apply_deny_env_and_credential` only on runs where the trade actually applied.
Because the key is on for Claude Code by default, an exported
`CLAUDE_CODE_OAUTH_TOKEN` reaches Claude Code without `--pass-env`, and the
Keychain grant goes in its place. With `sandbox.keychain_substitute = false` it
still needs `--pass-env`, as before, and no other agent receives it.
`keychain_substitute_vars_are_never_allowlisted` asserts it. Copilot's
three token variables are the one exception, and not a new one: they were
allowlisted for Copilot long before this trade, so an exported one already reached
the agent and still does with the key off.

**Why cplt does not pre-extract the Keychain item itself.** Copilot's stored
credential representation, selected-account contract and renewal behavior are
not established. cplt retrieves gh's stored github.com token, not Copilot's
Keychain secret. Evidence for another agent's format does not establish
Copilot's format. `Claude Code-credentials` holds an access token with a
few hours of life and a refresh token, and Claude Code rewrites the item in place
(observed: created 26 Aug, modified 2 Sep, `expiresAt` 3h40m out). Handing the
agent that access token and then taking the Keychain away produces a session that
can lose renewal when secure storage becomes unavailable. A proposed stored
credential handover must establish its lifetime and renewal path.

**Why each agent lands where it does.**

- **Claude Code** — `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`) is built
  straight into the credential without reading secure storage, with
  `refreshToken: null, expiresAt: null`, so no refresh path runs. Verified against
  claude 2.1.258: with `~/Library/Keychains` denied, `claude auth status` reports
  `loggedIn: true, authMethod: oauth_token`. The residual risk is that there is no
  recovery when a long-lived token finally expires — on a 401 Claude Code
  deliberately keeps the env token rather than adopting the stored credential, and
  tells the user to mint a fresh one. `ANTHROPIC_API_KEY` is deliberately *not*
  accepted as a substitute: with a claude.ai login present, Claude Code reports
  `authMethod: claude.ai` and treats the key as merely available, so dropping the
  grant on its account would silently move a subscription user onto per-token API
  billing. Pass it explicitly with `--pass-env ANTHROPIC_API_KEY` if that is what
  you want.

  MCP OAuth tokens are the cost. Claude Code keeps them in the Keychain on macOS
  and falls back to plaintext `~/.claude/.credentials.json` when secure storage is
  unavailable
  ([credential management](https://code.claude.com/docs/en/authentication.md#credential-management)).
  With the grant dropped, each MCP server that uses OAuth asks for one fresh
  sign-in, and the new token then sits in that file, which the agent can read and
  write. Those MCP tokens are exposed; that is a smaller blast radius than every
  Keychain item whose ACL lets the agent through.
- **Antigravity** — no broker; the grant is dropped only when `agy`'s fallback
  token file is already there and holds a complete credential (`token` plus
  `project_id` or `user_tier` when `auth_method` is `"gcp"`). `agy` prefers its
  keyring and writes the file only
  when the keyring fails: its own strings are "Failed to save token to keyring,
  falling back to file", "Failed to load token from keyring, falling back to
  file" and "Keyring SaveToken timed out ... falling back to file storage". So a
  user whose keyring works has **no** such file (or only a stale incomplete GCP
  token left by an earlier aborted sign-in when the keyring was denied), and
  deleting the grant outright
  strands them — verified by execution: with the file moved aside, `agy models`
  under cplt's real profile returns exit 0, and under the same profile minus the
  two Keychain rules it exits 1 with "Please sign in to view available models".
  Recovering from that needs a browser re-login, and `--allow-browser` is off by
  default. When a complete token file *is* present the trade is safe, also verified: `agy
  models` authenticated, refreshed an already-expired access token, and persisted
  the new one there, with `~/Library/Keychains` denied. Note the honest cost —
  that file holds a refresh token in plaintext at mode 0600 — but `agy` put it
  there itself, with or without cplt. Because `~/.gemini/antigravity-cli` must
  stay writable for `agy` to persist refreshed tokens, a compromised session can
  delete or corrupt `antigravity-oauth-token` so the next launch falls back to
  granting `~/Library/Keychains`. One case fails silently rather than loudly:
  `agy logout` outside cplt clears the keyring but can leave the fallback file
  behind, so a cplt session keeps authenticating with a credential the user
  believes is revoked. Every other way the file goes bad — missing, empty,
  incomplete, unreadable, corrupt, expired past its refresh token — either keeps
  the Keychain grant or surfaces as a plain sign-in error.

- **goose** — not eligible, and that is a finding rather than a
  gap. goose's `Config::get_secret` does read the uppercased environment
  variable before its keyring, so precedence is not the problem; the session
  lifetime is. Its GitHub Copilot provider re-reads `GITHUB_COPILOT_TOKEN`
  through that path whenever its cached API info expires, and its OAuth
  persistence layer writes *refreshed* credentials back into the keyring with
  `set_secret` — both mid-session, not at startup. Which of those applies
  depends on the provider goose is configured for, out of the several hundred it
  embeds, so a substitute would have to match the configured provider's key
  rather than any variable from goose's env hints: a developer with
  `OPENAI_API_KEY` exported and goose pointed at Anthropic would otherwise lose
  the keyring and the login with it. `GOOSE_DISABLE_KEYRING` does not rescue it
  either — it sends the same writes to `secrets.yaml` in goose's config dir
  (`$XDG_CONFIG_HOME/goose`, `~/.config/goose` by default), which cplt grants
  read-only. Determined by reading goose's source
  (`aaif-goose/goose`), not by inspecting the credential's shape.

- **Copilot** — on by default since #696. Probed (#277) with copilot 1.0.89 on macOS, running
  `copilot -p ... --silent` under cplt's real profile with `keychain_substitute`
  on and no `~/Library/Keychains` rule in it. With `GH_TOKEN` set to the output of
  `gh auth token` (an OAuth `gho_` token), Copilot authenticated and answered.
  With `GH_TOKEN` set to a well-formed but invalid token, it failed at startup
  with `Failed to fetch GitHub CLI user login (401): Bad credentials`. So under the
  dropped grant the environment token is what authenticates, and a bad one fails
  loudly rather than falling through to anything else. `copilot help environment`
  documents `COPILOT_GITHUB_TOKEN`, `GH_TOKEN`, `GITHUB_TOKEN` in that order of
  precedence over stored credentials.

  The usual Copilot user exports nothing and signed in through `gh`. For that
  case cplt runs `gh auth token --hostname github.com` itself at launch (the same
  trusted-path, host-pinned call `gh_guard.inject_token` uses) and hands the
  result over as `GH_TOKEN`, or as the first of the three names the repo's
  `deny.env` does not strip. If `gh` has no token the grant stays.

  What changes for the user, and what was not verified:
   - **A rejected token can leave no working fallback.** With the Keychain granted, a
    rejected `GH_TOKEN` did *not* stop Copilot: the same invalid token under
    the key-off profile, and outside cplt, still answered, so Copilot falls back
    to its stored login when the environment token fails. With the grant dropped
    there is nothing to fall back to. A stale `GITHUB_TOKEN` exported for
    something else, or a stale gh login, will show up as a sign-in error;
    unset the variable, run `gh auth refresh` or `gh auth login` on the host,
     or follow the [native-login recovery sequence](docs/known-impacts.md#the-same-vault-prompt-on-macos).
     The observed fallback is version- and credential-specific, not a guarantee.
   - **The account check is partial.** Before handing over
    `gh auth token`, cplt compares `gh`'s github.com `user:` with the `acct`
    attribute of Copilot's own Keychain item (`copilot-cli`,
    `https://github.com:<login>`), read on the host with
    `/usr/bin/security find-generic-password` without `-w`/`-g`, so the secret
    is not read and nothing prompts. With several `copilot-cli` items, cplt
    compares against the item whose account matches gh's login, or the first
    one `security` returns when none does; which account Copilot is actively
    using cannot be determined safely, since `~/.copilot/config.json` is
    writable by the agent and is not consulted. A different user, or an item
    on another host (GitHub Enterprise), keeps the grant and the launch summary
    says why. No item, or a `security` error or timeout (1 s), lets the
     substitute proceed. An exported token is used as-is, without this check.
     The independent `gh_guard.inject_token` channel does not perform the
     comparison; keeping the grant for a mismatch does not suppress injection.
    Once the grant is kept for a mismatch, the agent has Keychain write access
    for that session and could edit the item so the next launch keeps it too,
    the same exposure as before this default.
  - **The token sits in the agent's environment** — the same exposure
    `gh_guard.inject_token` has, which is why that key is marked dangerous. The
    trade here is that token instead of the whole login Keychain.
   - The #277 evidence covers one-shot `-p` runs with a gh OAuth token.
     It does not establish selected-account preservation, a classic `ghp_` PAT,
     onboarding or long-session renewal. See the separately maintained
     [authentication evidence](docs/copilot-auth-testing.md) for later probes
     and their limits.

When no substitute credential resolves, the grant stays and the session summary
says so. This preserves native-login access, not a guarantee that a login exists
or succeeds.
A repo `.cplt.toml` `deny.env` entry naming a substitute variable counts as "not
resolved": that list is stripped from the child environment, so honouring it as a
substitute would leave the run with neither Keychain nor token from a checked-in
file.

## Defense layers

### A property that holds across all of them: no silent grants

A grant or setting that cannot be honoured fails loudly at the point it is
written. It is never accepted and then quietly dropped.

This is a security property, not a usability one. A restriction that silently
does nothing leaves an operator believing a path is closed when it is open, and
nothing in the tool contradicts that belief. The failure is invisible by
construction: the config still lists the setting, `cplt config show` still prints
it, and the sandbox still starts.

The property has been broken in both directions and fixed each time: `allow.read`
on a hard-denied file worked on Linux while being silently overridden on macOS
(#207); `--allow-socket` emitted file rules that `connect()` never consults, so
it granted and denied nothing on Linux (#240); `allow.write` inside a credential
directory was inert on macOS while working on Linux (#291); read-only grants
under `/tmp` disappeared inside bubblewrap's private tmpfs (#299); the `[audit]`
section was settable and displayed while no code consumed it (#309).

Where a control genuinely cannot be enforced on a platform, that is documented as
a stated gap with the kernel reason for it, not left as an absence. The Linux
sections below say where those gaps are.

### Layer 0: Environment variable sanitization

By default `cplt` clears the child process environment and re-adds only safe variables from an allowlist, so credentials cannot leak through inherited env vars.

**How it works:**
1. `cmd.env_clear()` removes all environment variables
2. Variables matching `ENV_ALLOWLIST` (77 safe vars) are re-added from the parent process
3. Variables matching `ENV_PREFIX_ALLOWLIST` (14 prefixes: `LC_*`, `COPILOT_*`, `COREPACK_*`, `JENV_*`, `ASDF_*`, `MISE_*`, `FNM_*`, `NVM_*`, `PYENV_*`, `SDKMAN_*`, `TESTCONTAINERS_*`, `YARN_*`, `AGY_*`, `OTEL_*`) are re-added
4. `--pass-env VAR` adds explicit vars (repeatable)
5. `ENV_ALWAYS_DENY` vars (`NO_COLOR`, `FORCE_COLOR`, `SSH_AUTH_SOCK`, `SSH_AGENT_PID`) are always stripped

**Deliberately allowed:** `GH_TOKEN`, `GITHUB_TOKEN`, `COPILOT_GITHUB_TOKEN`. Copilot needs a GitHub token to function, and this is an accepted trade-off.

**OpenTelemetry (`OTEL_*`):** OTel configuration vars such as `OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_SERVICE_NAME`, and `OTEL_RESOURCE_ATTRIBUTES` pass through via the `OTEL_` prefix. `OTEL_EXPORTER_OTLP_HEADERS` may carry opt-in auth headers such as `Authorization=Bearer <token>`, an accepted trade-off in the same class as `GH_TOKEN`, and only present when the user has configured an exporter. The `is_secret_suffix` deny-list still strips any `OTEL_*_TOKEN`, `_AUTH`, `_SECRET`, `_KEY`, `_PASSWORD`, or `_CREDENTIALS` var.

**Deliberately blocked:** `AWS_*`, `AZURE_*`, `NPM_TOKEN`, `DATABASE_URL`, `VAULT_TOKEN`, `SSH_AUTH_SOCK`, Docker vars, CI tokens.

**Git configuration:** `~/.gitconfig`, `~/.gitconfig.local`, and `~/.gitignore_global` are exact read-only exceptions, so normal Git and `gh` workflows can load conventional user configuration. Git's XDG defaults are read-only too: `~/.config/git/config`, plus `ignore` and `attributes` (the default `core.excludesFile` and `core.attributesFile`; without the ignore file git warns and drops your global ignore rules, so `git add -A` would stage files you ignore everywhere). Only those three files, on both platforms: the rest of `~/.config/git` can hold `credentials`, git's XDG cleartext credential store, which is a hard deny like `~/.git-credentials`, so Linux no longer grants the directory. An `includeIf` target elsewhere in that directory needs its own `allow.read` (see [docs/known-impacts.md](docs/known-impacts.md#linux-fewer-home-config-files-are-readable-behaviour-change)). Both backends grant the same home config files from one list (`HOME_CONFIG_FILES` in `sandbox_policy.rs`). That list includes yarn 1's rc files, `~/.yarnrc`, `~/.yarnrc.yml` and `~/.config/yarn/config`, because yarn 1 stops when it cannot read them (#881). Either can hold a registry token, which the agent can then read; `~/.npmrc` stays denied. Both are read-only like git's config, because `yarn-path` in them names code the host's yarn runs. `~/.config/yarn` itself is readable as a directory node only on macOS; on Linux, Landlock grants it with its contents (`global/`, the packages from `yarn global add`), and not at all when it resolves onto or around a credential directory. Shell rc files (`~/.zshrc`, `~/.bashrc`, `~/.profile`, `~/.bash_profile`, `~/.zprofile`) are not on it, because they routinely export tokens; a shell the agent starts runs without them on either platform. Grant one with `allow.read` if a workflow needs it. Each exception follows a symlink to its target, because a dotfiles-managed home points `~/.gitconfig` at a stowed repo and the kernel checks the resolved path, not the one git opened. Other include files stay blocked unless explicitly allowed — an `include.path` outside the exceptions aborts the git command rather than being skipped.

"Read-only" has to hold at the target as well, because the target can sit inside a tree the agent may write: the dotfiles repo is the project, a `--repo-dir` root, or lies under an `allow.write` grant (#524). What holds, per platform:

- **macOS:** writes are denied at the `$HOME` path and at the resolved target, after every write grant, so the target stays read-only inside the project. The directories between the outermost writable tree holding the target and the target cannot be renamed or removed, so `mv dotfiles d2 && mkdir dotfiles` cannot swap in a fresh file. The writable root itself (the project, the `--repo-dir` root, the `allow.write` grant) is not pinned: moving it away is harmless, because recreating it needs write on its parent, which no grant gives. If `~/.config/git` is itself a link, `config`, `ignore` and `attributes` at its target are write-denied even when they do not exist yet; a new `config` could set `core.fsmonitor` or `core.hooksPath` and run code in the next git command outside the sandbox. If `~/.config` is the link and has no `git` directory yet, creating `git` there is denied, so it cannot be made a symlink to somewhere writable. A dangling link, such as `~/.gitconfig` pointing at a file the dotfiles repo does not have yet, is denied at the path its target would be created at. A target whose path cannot be written into the profile (it contains `"`, `(`, `;` and the like) and sits in a writable tree stops cplt at launch rather than going unprotected.
- **Linux with Bubblewrap:** the target is bound read-only over the writable tree, and the same directories are pinned as mountpoints, so they cannot be renamed. Bubblewrap cannot bind a file that does not exist, so a target that is missing at launch is created first, as an empty file owned by you (#553): `config`, `ignore` and `attributes` in a linked `~/.config/git` (and the `git` directory itself when `~/.config` is the link and has none), and the target of a dangling `~/.gitconfig`, `~/.gitconfig.local` or `~/.gitignore_global` link. Only targets inside a writable tree are created, never under the system temp dirs (Bubblewrap gives the sandbox its own `/tmp` and `/dev/shm`), and cplt says which at launch. `--print-profile` and `cplt check` create nothing; the profile lists what a launch would create. Git reads an empty config, ignore or attributes file the same as a missing one. Writing is different: `git config --global` writes to `~/.config/git/config` when that file exists and `~/.gitconfig` does not, so once cplt has created `config` in a linked `~/.config/git`, `git config --global` on the host writes into your dotfiles repo instead of creating `~/.gitconfig`. The files are left in place after the run, so they show up as untracked files in your dotfiles repo. cplt resolves the path itself and follows only your own link in `$HOME` and links outside every writable tree, so the repo cannot choose where the file lands: a symlink inside the writable tree on the way (a committed `gitconfig` that is itself a link) is refused, and so is a target inside a git directory. The only directory cplt creates is `git` under a linked `~/.config`; a dangling `~/.gitconfig` whose directory is missing gets nothing. The file is created with `openat2(RESOLVE_NO_SYMLINKS)`, so a link swapped into the path after the check fails the creation; on kernels before 5.6, which lack `openat2`, only the file's own name is checked then. When cplt refuses or fails, it warns, and that file stays creatable for the run. The existing-target binds and pins are checked by unit tests of the overlay and pin sets; the missing-target case has an end-to-end test under Bubblewrap.
- **Linux without Bubblewrap:** not enforced. Landlock can only add grants, so it cannot take the write back from a file inside a writable tree. That includes a run where Bubblewrap is installed but fails its startup check and cplt falls back to Landlock: missing targets are created only after that check passes. cplt creates nothing and warns at launch with the path of each target, existing or missing.

The cost lands on the user who edits their dotfiles repo inside cplt. Any write to a linked file fails, and so does anything that replaces it: `git checkout`, `git pull`, `git stash pop` or `git reset --hard` that change it, and an editor that saves by writing a temporary file and renaming it over the original. Git stops at the first file it cannot replace, so the working tree can be left half-updated. Moving or deleting a directory that holds a linked file fails too. The error is `Operation not permitted` on macOS, and `Read-only file system` or `Device or resource busy` on Linux. Run those operations outside cplt; see [known impacts](docs/known-impacts.md#git-restrictions).

On both platforms the link is resolved once, at launch, and only the file it ends at is protected. Two things fall outside that. An intermediate link in a chain (`~/.gitconfig -> link -> file`) that lives in a writable tree can be re-pointed. And on Linux, a missing target cplt did not create stays creatable: without Bubblewrap, or when cplt refused or failed to create it (see above). A new `config` can set `core.fsmonitor` or `core.hooksPath`, which run code in the next git command outside the sandbox; `ignore` is git's default excludes file, so an agent can hide files from `git status` through it.

The config is readable; the credentials it names are not. `credential.helper = store` puts cleartext tokens in `~/.git-credentials`, which is a hard deny no grant can reopen, and `url.<base>.insteadOf` rewrites or a `core.sshCommand` path only tell an agent where a secret lives — `~/.ssh`, `~/.gnupg` and every credential directory stay denied, and a symlinked exception whose target resolves into one of them is still denied, because the deny block is emitted after the grant and SBPL is last-match-wins.

**Escape hatch:** `--inherit-env` disables sanitization and inherits all env vars, still stripping `ENV_ALWAYS_DENY`. This is dangerous. Use it only for debugging.

### Layer 0.25: Security environment hardening

Beyond sanitization, `cplt` injects hardening environment variables that disable dangerous tool behaviors inside the sandbox. The system is declarative and category-based so new categories are easy to add.

**How it works:**
1. `HARDENING_ENV_VARS` is a compile-time list of `(name, value, category)` tuples
2. Each variable belongs to a `HardeningCategory`, for example `LifecycleScripts` or `GitHardening`
3. Variables are injected unless their category has been opted out via CLI flag
4. If a user explicitly passes a variable via `--pass-env`, their value is preserved

**Currently injected variables:**

| Variable | Value | Category | Purpose |
|---|---|---|---|
| `npm_config_ignore_scripts` | `true` | LifecycleScripts | Block npm and pnpm 10 postinstall hooks |
| `pnpm_config_ignore_scripts` | `true` | LifecycleScripts | Block pnpm 11+ postinstall hooks (pnpm 11 stopped reading `npm_config_*`) |
| `YARN_IGNORE_SCRIPTS` | `true` | LifecycleScripts | Block yarn 1 lifecycle scripts. Set only when the launch directory shows yarn 1 and not yarn 2+, since yarn 2+ rejects the setting and aborts. See [known impacts](docs/known-impacts.md#lifecycle-scripts-postinstall-hooks) |
| `YARN_ENABLE_SCRIPTS` | `false` | LifecycleScripts | Block Yarn Berry lifecycle scripts |
| `GIT_TERMINAL_PROMPT` | `0` | GitHardening | Prevent git credential prompts |
| `GIT_CONFIG_COUNT` | `2` | GitSigning | Number of git config overrides |
| `GIT_CONFIG_KEY_0` | `commit.gpgsign` | GitSigning | Override commit signing config |
| `GIT_CONFIG_VALUE_0` | `false` | GitSigning | Disable commit signing (private keys inaccessible) |
| `GIT_CONFIG_KEY_1` | `tag.gpgsign` | GitSigning | Override tag signing config |
| `GIT_CONFIG_VALUE_1` | `false` | GitSigning | Disable tag signing (private keys inaccessible) |

**Why this matters:** Supply chain attacks such as axios in March 2026 use `postinstall` hooks to execute malicious payloads. Blocking lifecycle scripts eliminates that whole attack class. `npm install` still downloads packages, no arbitrary code runs, and explicit commands like `npm run build` still work normally. Git signing is disabled because `~/.ssh` and `~/.gnupg` are denied by the sandbox, so attempting to sign would fail with EPERM. Disabling it via env var gives a clean, error-free experience.

**Escape hatches:**
- `--allow-lifecycle-scripts` disables the `LifecycleScripts` category. Use it when `npm install` requires postinstall hooks, for example native module compilation.
- `--allow-gpg-signing` disables the `GitSigning` category and adds targeted SBPL rules for GPG access. See the GPG signing risk analysis below.

### Layer 0.5: Native module write protection

Copilot keeps host-executable code in two directories: `~/.copilot/pkg/`, holding native modules such as `keytar.node` and `pty.node`, and the extracted SEA runtime — `~/Library/Caches/copilot/pkg/` on macOS, `~/.cache/copilot/pkg/` on Linux. Both are write-protected, blocking a persistence attack where a rogue agent replaces code that then executes *unsandboxed* the next time Copilot runs outside `cplt`. Writes to those directories from a normal session are not a loss: the SEA extraction that populates the cache runs before the sandbox is entered, and auto-update is disabled inside it (`--no-auto-update`).

**The extraction preflight runs unsandboxed, and the `-p exit` fallback is a real agent session.** The preflight spawns `copilot` twice outside the sandbox, as the user: `--version` to trigger extraction, and `-p exit` as a fallback for versions whose `--version` takes a lazy path. `-p` is prompt mode. Three things bound those spawns, and it is worth being precise about what they do and do not bound.

What is bounded: the preflight refuses to run a `copilot` binary that lives under the project directory; both spawns get `env_clear()` and a rebuilt environment holding only `HOME`, `PATH`, `TMPDIR` and the four cache-path overrides the SEA loader consults (`COPILOT_PKG_CACHE_HOME`, `COPILOT_CACHE_HOME`, `COPILOT_HOME`, `XDG_CACHE_HOME`), so no token, cloud credential or `NODE_OPTIONS` reaches them from the ambient environment; and both run with the Copilot package cache as their working directory, never the project, so a repository cannot reach the session through a checked-in instruction file. The preflight runs after the launch confirmation, so declining the prompt spawns nothing.

What is **not** bounded: this is still a full agent session. `HOME` has to be passed for extraction to target the right directory, so the session reads `~/.copilot`, starts whatever MCP servers the user has configured there — unsandboxed, as the user — and reaches the model using the stored credential, which lives on disk rather than in the environment. The change above removes the inherited working directory and the ambient secrets. It does not make `-p exit` inert, and this paragraph should not be cited as though it did. Constraining the session itself would need the preflight to run under a sandbox of its own.

**The two platforms enforce this differently, and Linux is weaker.** macOS emits SBPL write-denies for both. Landlock can express neither: `~/.copilot` is granted read+write+execute wholesale so Copilot can reach its session store and native modules, and Landlock cannot subtract a subpath from an allowed tree; and the execute rule that lets Node spawn the extracted helpers from `~/.cache/copilot/pkg` unions with the read+write grant `HOME_TOOL_DIRS` gives all of `~/.cache`, which left that directory writable *and* executable. On Linux the protection is therefore carried entirely by the Bubblewrap read-only overlay — the same mechanism behind the `.git/hooks` and agent config-dir denies — with the same two caveats: **without bubblewrap it is unenforced**, and a path that does not exist at launch cannot be bound and so is not protected ([#328](https://github.com/navikt/cplt/issues/328)).

### Layer 0.6: Copilot install directory auto-detection

When Copilot CLI is installed via a non-standard Node version manager (`n` at `~/n/`, Volta at `~/.volta/`, a custom npm prefix), its package directory falls outside the static `TOOL_READ_DIRS`. At startup, cplt resolves the copilot binary path, walks up at most 4 ancestors looking for a `package.json` with `"name": "@github/copilot"`, and adds that directory to the sandbox read allowlist. Safety checks:
- **Package identity:** parsed via `serde_json`, so only the real Copilot package is accepted
- **Unsafe root rejection:** `/`, `$HOME`, `/tmp`, and similar are rejected
- **SBPL injection validation:** path characters are validated before profile interpolation

### Layer 0.7: Global git hooks protection

Git's `core.hooksPath` points to a directory of user-configured hooks that run on commit, push, and so on. If it is not allowed, the sandbox makes git fail with EPERM instead of the ENOENT it gives for missing hooks. cplt auto-detects the hooks path and allows reading it. Safety checks:
- **Write denied:** `(deny file-write*)` explicitly blocks writes to the hooks directory, preventing persistence attacks even if the path overlaps a writable sandbox directory
- **Under `$HOME`:** paths outside the home directory are rejected, which prevents arbitrary filesystem reads
- **Depth >= 3:** the path must have at least 3 components under `$HOME`, so `~/.config/git/hooks` is fine and `~/hooks` is too broad
- **Unsafe root rejection:** `/`, `$HOME`, `/tmp`, and similar are rejected

### Layer 0.8: Inherited file descriptor sealing

The kernel sandbox decides what the agent may *open*. It says nothing about what is already open when the agent starts, and an inherited descriptor needs no `open(2)` at all — `cat <&3` reads a file the SBPL profile denies, and an inherited socket carries traffic the proxy never sees. Whatever launched cplt (an IDE, a wrapper script, a service manager) may be holding non-CLOEXEC descriptors on exactly such files, and they cross `sandbox-exec` and `bwrap` alike straight into the agent.

Before every agent spawn, cplt marks every descriptor above stderr `FD_CLOEXEC`, so nothing survives the `execve`. Details that matter:

- **`FD_CLOEXEC`, not `close(2)`.** The sealing runs as a `pre_exec` hook, and at that point Rust's `std` is still holding a CLOEXEC pipe it uses to report `execve` failure back to the parent. Closing descriptors blindly closes that pipe too, and the parent then reads EOF and reports a *successful* spawn for a binary that never ran.
- **stdin/stdout/stderr are untouched.** `std` has already dup2'd them into 0/1/2 by the time the hook runs.
- **How the mark is applied.** Linux does the whole range in one syscall: `close_range(3, ~0U, CLOSE_RANGE_CLOEXEC)`, kernel 5.11+, called by syscall number so the binary takes no glibc 2.34 symbol dependency and still starts on older distributions. Where that is unavailable — macOS, and Linux before 5.11 — cplt walks descriptor numbers instead, bounded by the highest descriptor that is actually open (`/proc/self/fd`) rather than by the soft `RLIMIT_NOFILE`. That bound used to be the limit itself, which a unit file can set to `infinity`: the walk then became roughly a billion `fcntl` calls between fork and exec, with the banner already printed and no timeout anywhere on the path (#525). The walk's bound is read in the parent, so a descriptor opened between that read and the fork falls outside it; what this layer exists to catch are the caller's descriptors, which predate the process, and everything cplt opens for itself is `O_CLOEXEC`. The `close_range` path has no such window.
- **The Linux bubblewrap path preserves exactly two descriptors.** The policy pipe and the confirm pipe are deliberately not CLOEXEC, and the in-namespace re-entry helper reads them by fd number. They are named in an explicit keep list and have their CLOEXEC flag cleared after the sweep.
- **One descriptor is preserved on every path:** the audit's settle probe (GHSA-c47q-c3c8-7wrf). It is a pipe cplt created and holds the only read end of, and handing the write end to the session is how cplt learns that the whole process tree has finished. It is exempted in the seal itself rather than at each spawn site, so a spawn path added later cannot quietly re-seal it — and `CLOSE_RANGE_CLOEXEC` cannot skip a descriptor inside its range, so the probe is marked with everything else and then un-marked by number, with the keep list. Sealing it would be silent: the read end sees EOF at once and every session reports itself settled. Nothing else is preserved on any path.
- **Ordering.** The seal is registered before the Landlock `pre_exec` hook, so the descriptors Landlock opens for its own ruleset are not swept.

**Compatibility note:** cplt has no protocol for accepting a descriptor from its caller, so there is nothing legitimate to break. The one scenario worth naming is a parent that spawns cplt as a Node IPC child (`NODE_CHANNEL_FD=3`); that variable is not in the environment allowlist, so in the default sanitized mode the descriptor was already useless to the agent, and under `--inherit-env` an IPC channel back to the launching process is precisely the ambient capability the sandbox exists to remove.

### Layer 1: Seatbelt kernel sandbox (sandbox-exec)

The primary defense is Apple's mandatory access control framework, enforced in the XNU kernel. All restrictions apply to the sandboxed process **and all its children**, and there is no way to shed the sandbox after `sandbox_init()`.

#### Profile structure

```
(deny default)                          ← Block everything by default
(import "bsd.sb")                       ← Allow basic system library access
(allow process-exec/fork)               ← Allow running programs
(allow file-read/write project_dir)     ← Project access
(allow file-read ~/.copilot)            ← Auth token access + native modules
(allow file-read ~/.config/gh/hosts.yml)← GitHub CLI auth (2 files only)
(allow file-read ~/.config/git/config)  ← Git config (read-only)
(allow file-read core.hooksPath dir)    ← Global git hooks (auto-detected, if set)
(deny  file-write core.hooksPath dir)   ← Prevent persistence via hook modification
(allow file-read copilot_install_dir)   ← Copilot CLI package dir (auto-detected)
(allow file-read/write /private/tmp)    ← Temp file access
(deny process-exec /private/tmp)        ← But no executing from tmp!
(allow unix-socket .java_pid*)          ← JVM Attach API only (--allow-jvm-attach, regex-restricted)
(allow unix-socket MSBuild<pid>)        ← MSBuild worker-node IPC only (--allow-msbuild, regex-restricted)
(deny  unix-socket /tmp/*)              ← All other unix sockets blocked (SSH agent, MSBuild Server, etc.)
(deny file-* ~/.ssh, ~/.aws, ...)       ← Sensitive dirs blocked
(deny network-outbound (remote tcp))    ← Block all outbound TCP by default
(allow network-outbound *:443)           ← Then allow HTTPS port only (use --allow-port for extras)
(deny network-outbound localhost:*)     ← Block localhost SSRF (default)
(allow network-outbound localhost:PORT) ← Carve-out for proxy (ephemeral port, assigned at runtime)
;; With --allow-localhost-any: replace deny with (allow ... localhost:*)
;; Java IPv4-mapped issue solved by -Djava.net.preferIPv4Stack=true in JAVA_TOOL_OPTIONS
```

> **Network and socket note (macOS profile).** Every socket statement here describes the Seatbelt profile; on Linux unix socket `connect()` is not gated by Landlock below kernel 7.1, and only the sockets bubblewrap masks are removed there, see [Linux-specific limitations](#linux-specific-limitations). Outbound TCP is restricted to port 443 by default, with `--allow-port` for more. Localhost outbound is blocked, which stops the agent reaching a service bound on your machine. SSH agent access (unix sockets) is blocked. JVM Attach API sockets (`/tmp/.java_pid*`) are available via `--allow-jvm-attach`, opt-in and regex-restricted to `.java_pid<PID>` only; all other unix sockets in `/tmp` stay blocked. MSBuild worker-node IPC sockets (`/tmp/MSBuild<PID>`) are available via `--allow-msbuild`, opt-in and regex-restricted to `MSBuild<PID>` only. That does NOT allow the persistent MSBuild Server, whose socket is named `MSBuildServer-<hash>` and never matches the regex; cplt also unconditionally sets `DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER=1`, so that server is never started or reused, including one started outside the sandbox. SBPL supports no domain-based rules, so filesystem isolation is the primary security control.

**Key design decision:** Deny rules are placed AFTER allow rules. In Seatbelt's evaluation model with `(deny default)`, more-specific rules override broader ones, and later rules take precedence at equal specificity. Our deny rules for `~/.ssh` therefore correctly override the broader temp and system allows.

#### Protected paths

Directories always denied (read and write):

- `~/.ssh`, `~/.gnupg` (cryptographic keys)
- `~/.aws`, `~/.azure` (cloud credentials)
- `~/.kube`, `~/.docker` (infrastructure access)
- `~/.nais` (Nav platform credentials)
- `~/.password-store` (pass password manager)
- `~/.config/gcloud` (Google Cloud credentials)
- `~/.config/op` (1Password CLI)
- `~/.terraform.d` (Terraform credentials)
- `~/.config/cplt` (cplt's own state — see below)
- `~/.nav-pilot` (nav-pilot's own state — see below)

Two of those are not credentials. `~/.config/cplt` holds the trust store, the blocklist caches and the self-update staging area: an agent that writes it tampers with the sandbox containing it, or swaps the binary `cplt update` is about to install. It is the one entry with **no** per-file override — the whole subtree is refused on every grant key, because every file in it decides what the next run may do. cplt's launch state (markers such as `opencode-snapshot-clean`, the first-run lock, the Copilot extraction verdict) lives in `$XDG_CONFIG_HOME/cplt` when `XDG_CONFIG_HOME` is absolute, else here ([#830](https://github.com/navikt/cplt/issues/830)). Both roots get the same treatment, a file left in `~/.config/cplt` from before #830 is still read, and a launch is refused when `XDG_CONFIG_HOME` puts the state root inside a writable tree or contains characters the macOS profile cannot name safely. `config.toml` and `trust/` do not move.

`~/.nav-pilot` is the same argument for a different tool ([navikt/copilot#858](https://github.com/navikt/copilot/issues/858)). It holds nav-pilot's `config.toml`, the pinned agentpakke revisions under `pakker/`, and the record of which sandbox waivers the user approved for a pakke. An agentpakke may ask its installer to approve a waiver — today only `proxy.allow_private_domains`, which relaxes the DNS-rebinding guard for one named host — and that approval is what the record holds. If an agent inside a session could write it, the agent would approve its own waiver for the next launch and the consent would mean nothing. The pinned revisions are the same argument one level down: they are the trees the next launch runs.

Unlike `~/.config/cplt`, a grant **inside** `~/.nav-pilot` still works, and that is load-bearing rather than an oversight. A Tier 2 nav-pilot launch passes cplt `--allow-read ~/.nav-pilot/pakker/<owner>-<repo>/<sha>/<client>/<context>` for the payload it is about to run, and that grant has to reach the ruleset. A grant naming the directory itself is refused, like every other entry here.

**Per platform.** On **macOS** the deny is a `(deny file-read*)`/`(deny file-write*)` pair emitted after every user allow, so it survives an `allow.write` covering `$HOME`. On **Linux** it is deny-by-omission: Landlock is grant-only, so a path in this list is simply kept out of the ruleset, and `sandbox::prepare` refuses a grant that would put it back. That form needs **neither bubblewrap nor a directory that already exists**, which is why `~/.nav-pilot` is protected here rather than through the host-persistence guard — a machine that has never run nav-pilot has no `~/.nav-pilot` to bind, and the host-persistence mechanism would have silently skipped it. In a default session with no wide `allow.write`, the directory was already unreachable on both platforms; what this entry adds is that one line of user config cannot undo that.

Directories explicitly allowed (read-only):

- gh's `hosts.yml` and `config.yml` (read-only at the effective config path; stored secrets may instead be in the OS credential store, see [Honest gaps](#honest-gaps))

Files always denied (hard blocks):

- `~/.netrc` (HTTP credentials)
- `~/.git-credentials` (cleartext tokens from `credential.helper = store`; a read-only exception that symlinks onto it, such as a dotfiles `~/.gitconfig`, is refused rather than granted)
- `~/.pypirc` (PyPI credentials)
- `~/.gem/credentials` (RubyGems credentials)
- `~/.vault-token` (HashiCorp Vault)

Files denied by default, overridable via `--allow-read` for private registries:

- `~/.npmrc` (npm registry configuration)
- `~/.config/pnpm/auth.ini` and `~/.config/pnpm/rc` (pnpm's global registry tokens), only with `sandbox.protect_pnpm_config`; see [Out of scope](#out-of-scope)

`sandbox.allow_build_credentials` (config-only, default off, marked dangerous, [#463](https://github.com/navikt/cplt/issues/463)) re-allows `~/.npmrc`, `~/.gradle/gradle.properties` and `~/.m2/settings.xml` as the same per-file grants three `allow.read` lines would produce. **With it on, the agent can read every registry token in those files and send it anywhere the network policy allows.** The proxy and egress allowlist are then the only control between those tokens and the outside. Each file goes through `first_party_read_target`: a symlink into a credential directory or onto another credential file, a directory, or a user-owned hardlink is refused with a warning, so `~/.npmrc -> ~/.ssh/id_ed25519` does not become a grant on the key. A target with an SBPL-unsafe character, or a file that fails to resolve for any reason but absence, is refused with a warning too. A `--deny-path` or `deny.paths` entry covering a file drops it from the grant. `.cplt.toml` cannot set the key.

The grant is read-only on macOS. On Linux it is read-only for `~/.npmrc` only: `~/.m2/settings.xml` and `~/.gradle/gradle.properties` sit inside the read/write `~/.m2` and `~/.gradle` tool-directory grants, which Landlock cannot carve a file out of, so both are readable and writable whether the key is on or off. A user deny on either is enforced only by a Bubblewrap mount mask; without Bubblewrap it has no effect on them, and cplt warns at launch naming each file.

#### Symlink attack protection

SBPL resolves symlink targets at the kernel VFS layer during path evaluation. cplt includes integration tests that demonstrate this: reading a denied file such as `.env` through a symlink with an innocuous name is blocked by the kernel.

The flip side: an SBPL rule is checked against the resolved path only, and a rule naming the link spelling matches nothing once a symlink sits on the way (`sbpl_path_filters_match_the_resolved_path_only` in `tests/integration.rs`). A dotfiles home where `~/.ssh -> ~/dotfiles/ssh` or `~/.netrc -> ~/dotfiles/netrc` was therefore unprotected on macOS whenever a grant covered the target, for example a project directory, `--repo-dir` root or `allow.read` on `~/dotfiles`. The credential directory and file denies above, the git config write denies and the GPG and Docker rules now name both the `$HOME` path and its resolved target, resolved as deep as the path exists, as the `DENIED_HOME_SUBPATHS` denies and re-allows already did for symlinked tool directories ([#543](https://github.com/navikt/cplt/pull/543)). A target resolves as deep as the path exists, and a dangling link is followed to where its target would be created, so an agent cannot create a missing `~/dotfiles/ssh` inside a writable grant and fill it.

A deny at the target holds only while the directories above it keep their names. With a stow layout (`~/.ssh -> ~/dotfiles/ssh/.ssh`) and the dotfiles repo as the project, `mv ssh ssh2` would move the key out from under the deny. So every directory between the outermost writable tree holding a target and the target itself gets a `file-write-unlink` deny: it stays writable, but it cannot be renamed or removed inside the sandbox (`mv ssh` and `mv git` in a dotfiles project fail). The tree root is not pinned; its parent is not writable, so a moved root cannot be recreated.

With `--deny-path` on a symlinked `~/.docker` or `~/.gnupg`, or on a directory holding its target, `--allow-docker` and `--allow-gpg-signing` withhold their re-allows. The path is compared against both spellings, since `--deny-path` is stored resolved.

**Remaining gap:** a target whose path contains a character cplt refuses to put in a profile (`"`, `(`, `)`, `;`, `\`) is left out. The deny then names only the `$HOME` spelling, which the kernel never checks, so **the credential stays readable at its target** through any grant covering it. cplt warns at launch, naming the entry and the target. It does not refuse to launch.

On **Linux** the same layout stays exposed and this is not fixed: Landlock is grant-only, so a grant on `~/dotfiles` covers `~/dotfiles/ssh` whatever `~/.ssh` points at, and bubblewrap masks only `--deny-path` entries and the built-in socket set, not the credential lists. It is the same limit as a grant on an ancestor of `~/.ssh`.

#### Tool directory permissions

Home tool directories (`~/.cargo`, `~/.nvm`, and friends) use a per-directory permission model (`HomeToolDir`) with granular `process_exec`, `map_exec`, and `write` flags:

| Directory                                                                                     | process-exec | file-map-executable | file-write | Rationale |
|-----------------------------------------------------------------------------------------------|---|---|---|---|
| `.local/bin`, `.mise`, `.nvm`, `.pyenv`, `.cargo`, `.rustup`, `.sdkman`, `go/bin` | ✅ | ✅ | varies | Contain executable binaries and shims |
| `Library/pnpm`, `.local/share/pnpm` | ❌ | ❌ | ❌ | PATH-visible executables receive exact file grants; recursive execution would also open the writable `store/` |
| `.gradle`, `.m2`, `.konan`, `go/pkg`                                                          | ❌ | ✅ | varies | JNI/cgo/Kotlin native libs loaded via dlopen, no direct executables |
| `.yarn`                                                                                       | ❌ | ❌ | ✅ | Yarn Berry global cache, JavaScript packages only, no native binaries |
| `Library/Caches`                                                                              | ❌ | ❌* | ✅ | Broad allow for dev tool caches; browser/app caches denied via regex prefix rules (com.apple.*, com.google.*, org.mozilla.*, etc.), with Xcode dev tools (com.apple.dt.*) re-allowed |

\* Exception: `~/Library/Caches/copilot/pkg/` has `file-map-executable` and `process-exec` for Copilot's native modules and helper binaries (`pty.node`, `spawn-helper`, `rg`). A `file-write*` deny prevents write-then-exec attacks. The two exec allows sit after the broader deny rules, and the write deny and the rename pin on `~/Library/Caches/copilot` sit after every allow, so an `allow.write` on `~/Library/Caches` cannot reopen them, since SBPL is last-match-wins. Such an `allow.write` also denies `process-exec` on the whole tree after every allow; the `pkg` exec allow is re-issued after that deny, and the write deny still follows it. cplt creates `copilot/pkg` as real directories (mode 0700) before every launch, whether or not a cache variable moves extraction, since the deny and the pin only hold on a path that exists: a missing `~/Library/Caches/copilot` could otherwise be planted mid-session as a symlink to a tree the agent writes, and Copilot's loader searches the default for a newer runtime. When `copilot` or `pkg` resolves elsewhere through a symlink outside every writable tree, the same rules are also emitted at the target; a symlink inside a writable tree, which the agent could have planted and can re-point, stops the launch on both platforms.

**Security principle:** every writable and executable directory is a potential binary-drop staging path. Denying both `process-exec` and `file-map-executable` on `~/Library/Caches` eliminates that at the kernel level. Non-dev caches (browsers, system apps, communication tools) are denied via `DENIED_CACHE_PREFIXES` regex rules in the SBPL profile, so new dev tools work without code changes, because their cache dirs do not use these prefixes.

#### Scratch directory

When `--scratch-dir` is enabled, cplt creates a per-session directory at `~/Library/Caches/cplt/tmp/{session-id}/` with full `read/write/exec/map-exec` permissions. This is a controlled exception to the TMPDIR exec deny.

- **Why it exists:** `go test`, `mise` inline tasks, and `node-gyp` compile to `$TMPDIR` and then execute. The sandbox blocks that, which breaks those tools. On macOS, JVM processes need it too, because `java.io.tmpdir` defaults to `/var/folders/...` and ignores the `TMPDIR` env var; cplt injects `-Djava.io.tmpdir`, `-Djansi.tmpdir`, and `-Djava.rmi.server.hostname=localhost` via `JAVA_TOOL_OPTIONS` to redirect JVM temp usage to the scratch dir and keep RMI communication on localhost.
- **Security model:** the scratch dir has both write and exec, which is the accepted trade-off. Mitigations:
  - **Scoped path:** only the specific session subpath has exec, not all of `~/Library/Caches/cplt/`
  - **0700 permissions:** owner-only access, verified at creation
  - **Symlink rejection:** the base path is validated as a real directory, not a symlink
  - **Owner check:** `stat()` verifies the directory owner matches the current uid
  - **SBPL injection guard:** the path is validated against metacharacters before interpolation
  - **Ephemeral:** cleaned up on exit via RAII Drop, and stale dirs are GC'd after 24h on startup
- **On by default:** disable with `--no-scratch-dir` or `sandbox.scratch_dir = false` in config.

### Layer 2: CONNECT proxy (logging and domain filtering)

A localhost CONNECT proxy intercepts all outbound traffic by default. cplt injects `HTTP_PROXY`, `HTTPS_PROXY`, and `NODE_USE_ENV_PROXY=1` into the sandbox environment, which routes traffic from Copilot CLI (Node.js), `gh` (Go), `curl`, and any other tool through the proxy. Use `--no-proxy` to disable.

Copilot CLI bundles Node.js v24.11.1, which supports `NODE_USE_ENV_PROXY=1` (added in Node.js v24.5.0). With that variable set, Node.js natively honors `HTTP_PROXY`/`HTTPS_PROXY`.

| Component | Language | Routes through proxy? |
|---|---|---|
| Copilot CLI | Node.js | ✅ Yes (via `NODE_USE_ENV_PROXY=1`) |
| `gh` CLI | Go | ✅ Yes (via `net/http.ProxyFromEnvironment()`) |
| `curl` | C | ✅ Yes |

**Historical context:** earlier versions of Copilot CLI used a Node.js runtime that did not support proxy env vars, and injecting them broke the auth flow. That stopped being true as of Copilot CLI 1.0.24+ with bundled Node.js v24.11.1.

**Design decision:** the proxy is enabled by default and listens on an OS-assigned ephemeral port (port 0), so there are no fixed-port conflicts. Use `--no-proxy` to disable for a single run, or set `proxy.enabled = false` in config to disable permanently.

The proxy provides:

1. **Connection logging.** Every CONNECT target is logged with timestamp and status.
2. **Domain blocklist.** A configurable file-based blocklist with subdomain matching.
3. **Port enforcement.** Only port 443 and `--allow-port` values are permitted, matching the sandbox policy.
4. **DNS rebinding protection** and **private IP blocking**, both covered below.

#### Proxy implementation safety

The proxy handles CONNECT tunnels only, and returns 405 for anything else. Each TCP connection processes exactly one request, with no HTTP keep-alive and no request pipelining, which eliminates HTTP request smuggling by design.

- **Buffer:** fixed 8192 bytes, single read, no allocation amplification
- **Connection limit:** 64 concurrent connections max, excess dropped
- **Binding:** `127.0.0.1` only, not reachable from the network
- **Invalid UTF-8:** replaced with U+FFFD via `from_utf8_lossy`, which matches no domain, so it fails safe
- **Relay timeout:** 60-second read timeout on both directions, preventing idle connection resource exhaustion

#### DNS rebinding defense

A naive proxy checks the hostname string ("api.github.com") against a blocklist before connecting. An attacker can register a domain that resolves to `127.0.0.1`, so the hostname check passes but the connection reaches localhost.

Our defense follows [OWASP SSRF Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) guidance:

```
1. Check hostname against blocklist           → block known-bad domains
2. Check hostname patterns (localhost, .local) → fast-path reject
3. DNS resolve hostname → IP address           → get actual target
4. Check RESOLVED IP against private ranges    → catch rebinding
5. Connect to the resolved IP (not hostname)   → pin the address, prevent TOCTOU
```

Step 5 is the critical one. We connect to the `SocketAddr` from step 3 rather than re-resolving, which prevents time-of-check-to-time-of-use attacks where the DNS response changes between validation and connection.

#### IP ranges blocked

| Range | RFC | Purpose |
|---|---|---|
| `127.0.0.0/8` | RFC 1122 | Loopback |
| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | RFC 1918 | Private networks |
| `169.254.0.0/16` | RFC 3927 | Link-local |
| `100.64.0.0/10` | RFC 6598 | CGNAT (Tailscale, WireGuard) |
| `198.18.0.0/15` | RFC 2544 | Benchmarking |
| `240.0.0.0/4` | RFC 1112 | Reserved/future |
| `192.0.0.0/24` | RFC 6890 | IETF protocol assignments |
| `0.0.0.0` | N/A | Unspecified |
| `255.255.255.255` | N/A | Broadcast |
| `::1` | RFC 4291 | IPv6 loopback |
| `fc00::/7` | RFC 4193 | IPv6 ULA (private) |
| `fe80::/10` | RFC 4291 | IPv6 link-local |
| `::ffff:A.B.C.D` (private v4) | RFC 4291 | IPv4-mapped IPv6 |

#### Proxy-forced mode (#53)

By default the proxy is **advisory at the kernel level**. The sandbox allows outbound TCP to `*:443`, and traffic reaches the proxy only because cplt injects `HTTP_PROXY`/`HTTPS_PROXY`/`NODE_USE_ENV_PROXY=1`. A raw socket, or an agent that runs `env -u HTTPS_PROXY -u HTTP_PROXY …`, can still reach any host on `:443` **without** traversing the proxy, bypassing all domain filtering.

Proxy-forced mode restricts **kernel-level TCP egress to the proxy port only**, making the proxy the sole sanctioned path off the machine on macOS, and the sole sanctioned TCP path on Linux (see the platform asymmetry below). It is opt-in and off by default; flipping it to the default is tracked in [#71](https://github.com/navikt/cplt/issues/71). When enabled:

- **The proxy is mandatory.** It is forced on. If it was explicitly disabled (`--no-proxy` / `proxy.enabled = false`), the launch is a conflict and cplt **errors out** rather than silently choosing a side.
- **Fail-closed.** If the mandatory proxy cannot bind or start, cplt **refuses to launch the agent**. It never falls back to open networking.
- **Domain filtering is unchanged.** Proxy-forced only changes which port the kernel permits; the proxy still enforces `allowed_domains` / `blocked_domains` on everything it carries. Pairing proxy-forced with an allowlist gives "only these domains, with no way around the proxy" for connections. DNS lookups are the exception on macOS (see [Honest gaps](#honest-gaps)). A default per-agent allowlist is tracked in [#52](https://github.com/navikt/cplt/issues/52).

**Enforcement is not equal across platforms:**

- **macOS (Seatbelt):** the SBPL profile replaces the `*:443` allow with `localhost:<proxy_port>` only. Seatbelt *can* pin to localhost, so there is **no residual** for connections. No direct-network path exists and the `env -u HTTPS_PROXY` and raw-socket bypasses are fully closed. Name lookups through the system resolver still work, so DNS remains a channel outside the proxy unless `proxy.deny_dns` is on.
- **Linux (Landlock):** Landlock drops the `:443` rule and allows only the proxy port. This blocks direct **TCP** `:443` to any host and forces HTTPS through the proxy, but two things stay open. Landlock is **port-based and cannot pin to localhost**, so a narrow `evil.com:<proxy_port>` channel stays reachable if a remote host answers on that exact port. Landlock's own restriction is **TCP-only** — it gates UDP at ABI v10 and cplt handles `AccessNet::ConnectTcp` alone — but in this mode a seccomp rule permits only `SOCK_STREAM` with protocol 0 or `IPPROTO_TCP` for `AF_INET`/`AF_INET6`, so UDP, raw, SCTP and DCCP are closed here on any kernel. DNS tunnelling and QUIC/HTTP-3 leave without touching the proxy in every *other* Linux mode. So this is "no direct TCP `:443` bypass and no non-TCP egress", **not** "no egress except the proxy": the proxy-port channel remains. Closing that residual requires a network namespace, tracked in [#114](https://github.com/navikt/cplt/issues/114).

> **Escape-hatch caveat:** `--allow-port <PORT>` opens a **direct** kernel egress channel on that port, to any remote host, that does not pass through the proxy. Under proxy-forced that channel is not opened ([#297](https://github.com/navikt/cplt/issues/297)): the port is dropped from the SBPL profile and from the Landlock ruleset, and cplt warns that it did so. The port stays in the *proxy's* allowed-port policy, so a proxy-aware tool still reaches `remote:<PORT>` by CONNECT, logged and domain-filtered. A tool that opens a raw socket does not, which is the whole point of the mode; run it without proxy-forced.

### Layer 1L: Landlock + seccomp kernel sandbox (Linux)

On Linux, kernel-level enforcement uses two complementary mechanisms.

#### Landlock LSM (filesystem + network)

[Landlock](https://docs.kernel.org/userspace-api/landlock.html) is a stacking LSM that provides unprivileged, process-level access control. Rules are additive within a ruleset, so access that is not explicitly granted is denied.

**ABI version support:**

| ABI | Kernel | Capabilities |
|-----|--------|-------------|
| v1  | 5.13+  | Filesystem access control |
| v2  | 5.19+  | + file refer (cross-directory rename) |
| v3  | 6.2+   | + file truncate |
| v4  | 6.7+   | + TCP port filtering (bind + connect) |
| v5  | 6.10+  | + ioctl on character devices |
| v6  | 6.12+  | + scoping (cplt requests abstract unix sockets; not signals) |
| v9  | 7.1+   | + `connect()` to pathname unix sockets (`ResolveUnix`) |

cplt requires ABI v1 minimum and requests up to v9. On ABI < v4, network security relies on the CONNECT proxy alone, because Landlock cannot filter TCP ports. On ABI v4+, Landlock denies all TCP connections except to explicitly allowed ports. From v6 abstract unix sockets created outside the sandbox are scoped out of the domain, and from v9 `connect()` to a pathname unix socket is restricted to granted paths. Everything above v1 is best-effort, so on an older kernel the right is silently dropped rather than failing the launch.

**UDP is still not restricted by Landlock**, since its UDP support lands at ABI v10 and cplt handles `AccessNet::ConnectTcp` only. Under `proxy.forced` the seccomp filter closes it instead, by permitting only `SOCK_STREAM` with protocol 0 or `IPPROTO_TCP` for `AF_INET`/`AF_INET6` — an allow-list, so SCTP and DCCP go with it. In every other Linux mode UDP remains unrestricted, deliberately: denying `SOCK_DGRAM` there would break `getaddrinfo(3)` for every non-proxied tool.

Kernel 7.1 is not deployed anywhere yet (Ubuntu 24.04 is 6.8, Debian 13 is 6.12, Fedora 42 is ~6.15), so in practice the v9 unix-socket right is inert and the bubblewrap mount masks below are the whole of that protection.


**Key differences from Seatbelt:**

| Property | Seatbelt (macOS) | Landlock (Linux) |
|----------|-----------------|------------------|
| Granularity | Path regex, file-level deny | Path-based, directory-level allow |
| Default | deny-by-default | deny-by-default |
| Subpath deny | ✅ Can deny subpaths within allowed dirs | ❌ Cannot deny within allowed paths |
| Network | Port-based (all ABIs) | Port-based (ABI v4+ only) |
| Audit logs | Full Seatbelt violation log | None (no audit mode) |
| Privilege | Requires `sandbox-exec` (deprecated) | Unprivileged (any user) |

**Pre-exec safety:** the proxy thread makes the process multi-threaded before `fork`. Landlock rules are pre-computed in the parent process (`PrecomputedSandbox`), and the seccomp filter is installed via raw syscall. The Landlock crate performs small heap allocations in `pre_exec`, which is technically not async-signal-safe but works reliably in practice, because the proxy thread is blocked in I/O syscalls during fork, which minimizes allocator contention.

#### seccomp-BPF (syscall filtering)

A BPF filter blocks dangerous syscalls that could be used to escape the sandbox or escalate privileges:

| Blocked syscall | Reason |
|----------------|--------|
| `ptrace` | Prevents debugging/injecting into other processes |
| `process_vm_readv`, `process_vm_writev` | Prevents cross-process memory access |
| `mount`, `umount2` | Prevents filesystem namespace manipulation |
| `pivot_root`, `chroot` | Prevents root filesystem escape |
| `unshare` | Prevents creating new namespaces |
| `setns` | Prevents entering other namespaces |
| `reboot` | Prevents system disruption |
| `kexec_load` | Prevents kernel replacement |
| `init_module`, `finit_module`, `delete_module` | Prevents kernel module manipulation |
| `swapon`, `swapoff` | Prevents swap manipulation |
| `personality` | Prevents ABI personality changes |
| `add_key`, `keyctl`, `request_key` | Prevents kernel keyring manipulation |
| `io_uring_setup`, `io_uring_enter`, `io_uring_register` | Prevents io_uring (bypass of seccomp/Landlock) |
| `userfaultfd` | Prevents userfaultfd exploitation |
| `perf_event_open` | Prevents perf-based side channels |
| `bpf` | Prevents BPF program loading |
| `iopl`, `ioperm` | Prevents I/O port access (x86_64 only) |
| `modify_ldt` | Prevents LDT modification (x86_64 only) |

The filter uses `SECCOMP_RET_ERRNO` (returns EPERM) rather than `SECCOMP_RET_KILL`, so legitimate probes do not crash.

#### Protected paths (Linux)

The same credential directories and files are denied as on macOS: see [Protected paths](#protected-paths).

Linux-specific tool directories use XDG-style paths:

| Directory | Permissions | Rationale |
|-----------|------------|-----------|
| `~/.cache` | read+write | XDG cache dir (pip, go-build, etc.) |
| `~/.local/share/pnpm` | read-only root with exact grants for existing PATH executables; `store/` read+write; `package-manager-store/` read+write+exec | A pnpm executable that resolves into `store/` (a hardlink at any depth under `store/v*/links/`, or the store binary a pnpm 11 `bin/pnpm` launcher execs) is copied to a per-session read-only shadow before launch, with a `dist` symlink into the writable, non-executable store beside it, so the content-addressable store remains non-executable. The binary a `bin/pnpm` launcher execs is shadowed the same way when it lies anywhere else in the pnpm home, such as a plain file under `global/v11/<hash>/` with no store hardlink, as pnpm 12 installs it ([#936](https://github.com/navikt/cplt/issues/936)). This adds no capability: `global/` is read-only and non-executable to the agent, so it holds less agent-controlled content than the writable store that is already copied, and the copy keeps the no-symlink open, the regular-file and ELF/Mach-O checks, and reads from the checked fd. The launcher's target must resolve inside a pnpm home; a pnpm reached directly on PATH still needs a store hardlink. When the nearest `package.json` from the launch dir upward pins an exact pnpm version already under `store/v*/links/@pnpm/exe/<version>/`, that binary is shadowed instead, under the same no-symlink open and ELF/Mach-O check, since pnpm 11 would spawn it from the store ([#890](https://github.com/navikt/cplt/issues/890)). While a shadow is active, cplt appends each existing `$PNPM_HOME/bin` (and `$PNPM_HOME` itself when it holds a `pnpm`) to the child PATH after the shadow, so the `pnpm setup` rc block finds it present and does not prepend the launcher, which would exec the store binary. No exec grant changes. An rc line that prepends `$PNPM_HOME/bin` unconditionally still bypasses the shadow. `package-manager-store/` deliberately downloads and runs packageManager-pinned versions |
| `~/.local/bin` | read+exec | User-installed binaries |
| `~/.local/share/mise` | read+write+exec | mise tool installations |

#### Linux-specific limitations

1. **No `--show-denials`.** Landlock has no audit logging. Use `strace` for debugging.
2. **No subpath deny.** The entire directory must be allowed or denied. See [Out of scope](#out-of-scope). This is why `--allow-docker` on Linux exposes all of `~/.docker` read-only, including `trust/private`, which the macOS profile denies.
3. **Secret Service API access is a Linux coverage gap.** Denying keyring files does not deny credentials served over D-Bus. Filtering `DBUS_SESSION_BUS_ADDRESS` only removes a discovery hint: an agent can reconstruct the address from the allowed `XDG_RUNTIME_DIR` or name a known socket. Before Landlock ABI v9, filesystem rules do not mediate pathname UNIX-socket `connect()`; seccomp-BPF cannot dereference the address pointer. Neither `deny.env` nor a socket-path filesystem deny closes this API path.

   Measured on Ubuntu 24.04 in Colima, kernel 6.8 reporting Landlock ABI 4, with Landlock + seccomp and no active bubblewrap: a private D-Bus Secret Service returned a test credential while direct keyring-file reads were denied. All 24 token-matrix cases allowed direct D-Bus credential reads, including with all token variables denied, the bus address stripped and a socket `--deny-path`. The standalone reproduction is `python3 hack/probe-linux-secret-service.py /absolute/path/to/cplt`, using a private bus and dummy credential; it requires the tools listed in the script. This is evidence for that backend/version, not every Linux kernel or a desktop agent's native login. Bubblewrap could not be tested because namespace creation was blocked in both the container and VM; its configured bus masks are not a verified default boundary in this environment. See [credential handover](docs/known-impacts.md#linux-keyring-access-depends-on-the-backend-and-agent-version).
4. **No localhost isolation at kernel level.** Landlock network rules are port-based only and cannot distinguish `localhost:443` from `remote:443`. On macOS, Seatbelt blocks localhost outbound separately. On Linux, use `--with-proxy` for localhost SSRF protection, since the proxy resolves DNS and blocks private IPs.
5. **Unix-socket protection depends on the kernel and on bubblewrap.** Landlock cannot restrict `connect()` to a pathname unix socket before ABI v9 (kernel 7.1); the seccomp filter cannot help, since the path arrives behind a pointer BPF cannot dereference; and a read-only bubblewrap bind does not stop a `connect()` either (the `MS_RDONLY` check lives in `mnt_want_write()`, which unix-socket connect never reaches). Three regimes result, and cplt prints which one a run is in:

   | Kernel | bubblewrap | Outcome |
   |---|---|---|
   | ≥ 7.1 (ABI v9) | either | `ResolveUnix` mediates pathname connections; writable-tree grants, including `/tmp` and the project, also allow connections |
   | < 7.1 | active | the known escape sockets are mount-masked; any other pathname socket stays reachable |
   | < 7.1 | absent | no restriction at all |

   The masked set is `$XDG_RUNTIME_DIR/bus`, `$XDG_RUNTIME_DIR/systemd`, `/run/dbus/system_bus_socket`, and — unless `--allow-docker` — the Docker and Podman daemon sockets (`--allow-rootless-docker` lifts only the `$XDG_RUNTIME_DIR/docker.sock` and `$XDG_RUNTIME_DIR/podman` entries, and never one that names or overlaps a rootful, Docker Desktop or Colima endpoint), including Docker Desktop for Linux's `~/.docker/desktop/docker.sock`, which is not under a runtime dir at all. The runtime-dir entries are emitted for `/run/user/<uid>` **and** for `$XDG_RUNTIME_DIR` when that variable points elsewhere, because cplt passes it through to the agent: keying the list on the systemd default alone would mask a path nobody uses on such a host while the banner still counted the escape sockets as masked. Additive, so a wrong or hostile value can only add a mask. The set is fixed at launch and only covers sockets that exist then (`src/sandbox.rs`, `.filter(|p| p.exists())`), so a daemon started *after* cplt gets no mask and stays reachable under `--ro-bind / /` for the rest of the session — which matters most for Docker Desktop, started and stopped interactively far more often than a system `dockerd`. The third row is the common case today, and bubblewrap is absent whenever it is not installed, `--no-bubblewrap` is passed, or auto-detect falls back at spawn time. Sockets outside the masked set (the SSH agent, an arbitrary application socket) remain reachable below 7.1 regardless.

   For the SSH agent the withheld `SSH_AUTH_SOCK` is the only barrier, and how much bubblewrap helps depends on which agent is running. bwrap's private `/tmp` does hide the stock OpenSSH socket (`/tmp/ssh-XXXXXX/agent.<pid>`), which an agent would otherwise have to enumerate. It does nothing for the desktop agents: gnome-keyring/gcr (`$XDG_RUNTIME_DIR/gcr/ssh`), GNOME keyring (`$XDG_RUNTIME_DIR/keyring/ssh`) and systemd's `ssh-agent` (`$XDG_RUNTIME_DIR/openssh_agent`) all sit at a fixed, guessable path under `/run/user/<uid>` that `--ro-bind / /` leaves visible. On a GNOME or KDE desktop, bwrap adds nothing here.

   Below kernel 7.1, filesystem grants for `--allow-socket` and `--allow-gpg-signing` do not mediate pathname connections and are not generally refused when ineffective. cplt already requests `ResolveUnix` best-effort for ABI v9 and `Scope::AbstractUnixSocket` for ABI v6 onward. Abstract-socket scoping does not close the ABI 4–8 pathname gap. For selected known bus/systemd endpoints, require bubblewrap with `sandbox.use_bubblewrap = true`; default auto-detect can fall back and is not security-equivalent. These masks do not cover every custom pathname or abstract socket, and ABI v9's broad writable-tree grants are not a universal API deny.
6. **D-Bus can reach the session manager.** A reachable session bus lets `systemd-run --user <cmd>` request a unit **outside** Landlock, seccomp and the bubblewrap namespaces. Below ABI v9, pathname connections are unmediated unless a mount mask hides the endpoint; from ABI v9, access depends on `ResolveUnix` grants, including writable trees. `linux_tests::keyring_file_deny_does_not_imply_a_unix_socket_boundary` in `tests/integration_linux.rs` checks child success, denied keyring-file reads and actual UNIX-socket payload delivery below ABI v9, or explicit socket denial from ABI v9. The session-manager escape itself remains a code-reading conclusion, distinct from the measured private Secret Service reads above. Require and verify bubblewrap's selected endpoint masks, or use a container or VM without the host bus exposed; neither approach denies every possible D-Bus endpoint automatically.
7. **UDP is unrestricted except under `proxy.forced`.** Landlock gates UDP only at ABI v10, and cplt handles `AccessNet::ConnectTcp` only, so outbound UDP to any host and port, and inbound UDP bind, are unrestricted at the kernel in every Linux mode but one. Under `proxy.forced` a seccomp rule permits only `SOCK_STREAM` with protocol 0 or `IPPROTO_TCP` for `AF_INET`/`AF_INET6`, which removes UDP, raw, SCTP and DCCP on every kernel — at the cost of anything that opens such a socket, since seccomp cannot see the destination address at `socket(2)` and no loopback exemption is expressible. That is wider than "a UDP tool reached through `--allow-localhost`": the JDK opens `socket(AF_INET, SOCK_DGRAM, 0)` for `SIOCGIFCONF` to enumerate interfaces and throws `SocketException` on `EPERM`, which Gradle propagates. Gradle is already unusable under `proxy.forced` on Linux because of the port lock, so the practical impact is marginal, but the failure is not confined to code that sends UDP. The CONNECT proxy carries TCP only, so UDP never touches it, and outside `proxy.forced` DNS tunnelling, QUIC/HTTP-3 and plain UDP exfiltration are covered by no cplt layer on Linux. Making `proxy.forced` the default for new installs is tracked in [#822](https://github.com/navikt/cplt/issues/822). macOS allows only TCP on 443 and on `--allow-port` ports since [#815](https://github.com/navikt/cplt/issues/815), so UDP to remote hosts is denied in every mode and HTTP/3 clients fall back to TCP. The localhost rules (`--allow-localhost <PORT>`, `--allow-localhost-any`) still use `remote ip` and so stay open to UDP on loopback. Outside `proxy.forced` direct TCP/443 is still allowed, so the macOS proxy log is a complete record of connections only under `proxy.forced` (DNS lookups through the system resolver never appear in it).
8. **`--allow-localhost-any` disables ALL kernel network restriction on Linux.** Landlock is port-based and cannot express "any localhost port but no remote host", so opening all localhost ports means dropping *every* Landlock TCP-connect rule. The result is unrestricted outbound TCP at the kernel level, so an agent can raw-socket to any remote `host:port` and exfiltrate directly, not just reach localhost. macOS behaves differently. There, `--allow-localhost-any` swaps one SBPL line, replacing `(deny network-outbound (remote ip "localhost:*"))` with the matching allow. The blanket `(deny network-outbound (remote tcp))` and the `*:443` allow are untouched, so remote egress stays scoped to 443 plus any `--allow-port`. Only loopback opens up. cplt emits a prominent warning when this flag is set on Linux. **Prefer `--proxy-forced`**, which supersedes `allow_localhost_any` (see [Proxy-forced mode](#proxy-forced-mode-53)), or scope to specific ports with `--allow-localhost <PORT>`, which keeps kernel connect-restriction on.

#### MCP host broker: where it runs

The MCP host broker ([#824](https://github.com/navikt/cplt/issues/824), [#834](https://github.com/navikt/cplt/issues/834)) runs a local MCP server such as `nais` on the host and keeps its credential out of the sandbox. On Linux the server's credential sits in the Secret Service, and below Landlock ABI v9 only Bubblewrap's mount masks keep the agent off the D-Bus socket that serves it (limitation 3 above). So on Linux the broker runs only when Bubblewrap wraps the launch and masks every bus and systemd socket that exists. Otherwise cplt prints one line with the fix and leaves the server entries as configured.

| Platform | Broker | Notes |
|---|---|---|
| macOS | runs | Socket in a 0700 dir under `/private/tmp`, one exact Seatbelt rule |
| Linux with working Bubblewrap | runs | Measured in CI on Ubuntu 22.04 and 24.04 |
| Ubuntu 23.10+ / 24.04 before the fix | refused | `kernel.apparmor_restrict_unprivileged_userns = 1` blocks bwrap. cplt and `cplt doctor` read the sysctl and print the one-time fix: load Ubuntu's own `/etc/apparmor.d/bwrap-userns-restrict` with `apparmor_parser -r` when it is there, else write a profile for `/usr/bin/bwrap` with `userns` and load that |
| Ubuntu 24.04 after the fix | runs | The CI job applies the same fix |
| Linux without Bubblewrap (Landlock only) | refused | Until Landlock ABI v9 (kernel 7.1) can mediate the bus socket. cplt says how to install bubblewrap |
| WSL2 | expected to run, not measured | Without systemd there is no `XDG_RUNTIME_DIR`. The CI test runs both with and without one. `nais` needs a Secret Service on the host side: on headless WSL2, install and unlock `gnome-keyring` |

The socket lives in a 0700 `cplt-mcp-<random>` directory under `/tmp`. The policy grants read and write on the socket file alone. Bubblewrap binds that file into its private `/tmp`, and Landlock ABI v9 needs the write right for `connect(2)`. A user `--deny-path` cannot mask it, and cplt refuses the run if one does.

The sandbox gets no D-Bus. With the broker active, Bubblewrap mounts an empty tmpfs over every runtime dir (`/run/user/<uid>` and `$XDG_RUNTIME_DIR`) and over `/run/dbus`, and masks each `unix:path=` or `unix:dir=` that `DBUS_SESSION_BUS_ADDRESS` names. Only paths that exist at launch can be masked. An abstract bus address (`unix:abstract=`, `unix:tmpdir=`) is refused below Landlock ABI v6, which is what scopes abstract sockets. A non-unix bus address is always refused. Hiding the runtime dirs also hides what else lives there, including the gpg-agent socket and rootless Docker or Podman. So when `--allow-gpg-signing` or `--allow-rootless-docker` (or `allow_gpg_signing` / `allow_rootless_docker` in config) is on, cplt keeps the flag and turns the broker off for that run. It says so in one line: pass `--no-mcp-broker <id>` to keep the flag without the broker, or drop the flag to use the broker. `cplt mcp status --json` reports the reason as `off_reason`. With the broker active, Bubblewrap is strict for the run, so a spawn-time failure stops the launch instead of falling back to Landlock with the bus reachable.

### Layer 3: Input validation

#### SBPL injection prevention

All paths interpolated into sandbox profiles are validated against unsafe characters:

```
Blocked: " ) ( ; \ \n \r \0
```

The newline character is the dangerous one. A path containing `\n(allow file-read* (subpath "/"))` would inject a rule granting read access to the entire filesystem. We validate:

- Project directory path
- Home directory path
- All user-specified allow/deny paths, from CLI and config file

Config file paths are additionally canonicalized (resolved to absolute paths) at load time.

#### The profile never becomes a file

The SBPL profile is passed to `sandbox-exec -p` as an argument. It is never written
to disk and never handed over as a pathname.

The profile grants every sandbox write throughout `/private/tmp` and
`/private/var/folders`. While cplt wrote the profile to `$TMPDIR/cplt-*.sb` and
passed `-f <path>`, one sandboxed session could overwrite another session's
profile between the write and the kernel's read — a complete policy replacement,
not merely corruption, since the attacker chooses the replacement text. Measured
at 14 of 15 launches (`profile_cannot_be_swapped_by_another_session` in
`tests/e2e.rs`, which still reproduces the attack against the old code).

An oversized profile fails loudly with `E2BIG` — the argument list must fit in
`kern.argmax` (1 MiB) alongside the environment. The kernel never sees a
truncated profile: `sandbox-exec` either applies the whole thing or refuses to
start. A default profile is about 25 KB and each allow/deny grant adds roughly
2.5 KB, so the ceiling is in the low hundreds of grants.

#### Unsafe root rejection

cplt refuses to sandbox overly broad directories that would hand the agent access to sensitive areas:

- `/` (entire filesystem)
- `/Users` (all user home directories)
- `$HOME` (user's entire home directory)
- `/tmp`, `/private/tmp` (shared temp directories)
- `/var`, `/private/var` (system variable data)
- `/Applications` (installed applications)
- `/System` (macOS system files)

#### CLI path handling

- **Allow paths** (`--allow-read`, `--allow-write`) are canonicalized, and unresolvable paths are warned about and skipped
- **Deny paths** (`--deny-path`) are canonicalized, and unresolvable paths cause a **hard error**, because silently dropping a deny rule is a security risk

#### Session-end upstream apply (macOS)

The git gate strips `-u` from `git push -u` and appends `{cwd, argv}` to a file
in the scratch dir (#402). After the session, the unsandboxed parent reads it
and may write `.git/config`. That makes the parent the first unsandboxed
consumer of output the gate wrote, and the gate runs inside the sandbox, so the
file is agent-controlled. The parent treats every line as hostile:

- It reads the file from its own scratch path, never from `$TMPDIR` or from the
  `__CPLT_SCRATCH_DIR` variable the gate is given (the agent controls the
  gate's environment), through `untrusted::read_untrusted` (no symlink,
  regular file, 64 KiB cap). Nothing happens with `--no-scratch-dir`,
  `--quiet`, or when the session did not settle.
- It accepts only `push -u <remote> <branch|HEAD>`. The gate swaps `HEAD` for
  the branch checked out at push time, so a `git switch` after the push cannot
  move the tracking onto a branch that was never pushed; the parent checks the
  result like any other name. Branch and remote names are limited to a narrow
  character set (no `"`, `[`, `]`, `:`, whitespace, control characters or
  `@{`).
- The cwd must be inside a root before any git runs there, and its repository
  toplevel must equal the project dir or a named root.
- The branch must exist (`rev-parse --verify --end-of-options refs/heads/<b>`),
  the remote must be listed by `git remote`, and `gate_git` must allow
  `push <remote> <b>` with the launch facts.

It then writes exactly two keys, `branch.<b>.remote` and `branch.<b>.merge`
(always `refs/heads/<b>`), with `git config --local` through `git::command`.
The worst a forged line can do is set tracking for an existing local branch to
a remote that already exists in a repository the session was given.

### Layer 4: Per-repo config trust model (`.cplt.toml`)

Repository maintainers can commit a `.cplt.toml` to configure sandbox settings for all contributors. That creates an attack surface, since a compromised or malicious maintainer could weaken the sandbox for everyone who clones the repo. The trust model addresses this with defense-in-depth.

#### Security design principles

1. **Deny-default for permissions.** The `[propose]` section requests sandbox relaxations, but they have **no effect** until the local user explicitly approves them with `cplt trust accept`. Unapproved permissions are silently ignored and the agent runs with the tighter default sandbox.

2. **Deny section is tighten-only.** The `[deny]` section can only add restrictions, blocking paths and env vars. It is applied automatically without approval, because it cannot weaken the sandbox.

3. **No interactive approval during launch.** cplt deliberately does *not* prompt "approve these? [y/N]" when unapproved permissions exist. That prevents approval fatigue, where users reflexively hit `y` to proceed. Approval requires a separate deliberate command (`cplt trust accept`), matching the security model of Deno workspace trust and VS Code Restricted Mode.

4. **Tamper-proof source.** `.cplt.toml` is read from `git HEAD` (committed state) via `git cat-file`, not from the working tree, so the sandboxed agent cannot modify its own config mid-session. Writes to it are kernel-denied on macOS and under bubblewrap; on the Landlock-only path they are not, which is why an uncommitted file may grant nothing anywhere. When the file is not in HEAD it is read from the working tree, but every grant in it is stripped at the loader, on every platform, so no approval path can reach one ([#206](https://github.com/navikt/cplt/issues/206)). What survives is what only ever tightens: `[deny]`, and the two `[propose]` guard keys that turn a guard on. That is where the guard belongs: it used to live in `cplt trust accept`, and three separate routes around it — a gitignored file, a non-git directory, and `--accept-repo-config` — were found one at a time. Write access to `.cplt.toml` is kernel-denied inside the sandbox on macOS, and under bubblewrap for a file that exists at launch; on the Landlock-only path it is not denied at all, because Landlock cannot subtract one file from a writable tree. That deny covers repositories **nested** beneath a writable root too: with `allow.write = ["~/code"]`, `~/code/other-repo/.cplt.toml` was writable, and a later run with `--project-dir ~/code/other-repo` reads it. Repo config can only tighten, so this is not a route to a wider sandbox — it is an agent steering a *later* run in a repository the current one was never pointed at, the same argument that made `.git/hooks` and `.agents/plugins` nested. `.gitmodules` is nested for the same reason: `git submodule update --init` reads it directly. The nested variant is expressed as a regex and is macOS-only; no other backend can match at unknown depth.

5. **Content-pinned approvals.** Trust entries store a SHA-256 hash of each approved key's normalized `[propose]` value ([#1002](https://github.com/navikt/cplt/issues/1002)). A key applies only while its stored hash equals the hash of its current value, so a changed value puts that key, and only that key, back to pending; adding one repository to `repos` re-asks for `repos` and leaves `allow_jvm_attach` approved. A key listed without a matching hash never applies, and a key no longer proposed drops out. Reordering array elements is hash-stable, thanks to a pre-sort. Approving one key never renews another whose value changed: the entry keeps only keys whose value still matches. Entries written before per-key hashes keep the old rule (all keys while the hash of the whole proposal matches, none otherwise) and are rewritten per key on the next accept. The whole-proposal hash is still written, and `keys` holds only keys that matched when written, so an older cplt reading a new entry grants those keys only while nothing has changed, never more than the current version.

6. **Additive-only semantics.** Repo config can enable features (`allow_docker = true`) but cannot disable anything set by the user's CLI flags, per-repo user config or global config. An approved boolean proposal applies only when no explicit layer set that key, so the order is: CLI > per-repo user config (`~/.config/cplt/local/<hash>.toml`) > global config > approved repo permissions > preset baseline and defaults. Approved list proposals (paths, ports, domains, `pass_env`) are appended to what the other layers produced. A proposal that turns a guard on is the exception: it is tighten-only, needs no approval, and applies even over an explicit `false`.

7. **Path traversal rejection.** Paths in `.cplt.toml` containing `..` components are rejected at parse time, which prevents escape attempts like `../../.ssh`.

#### Trust store integrity

- Trust entries live in `~/.config/cplt/trust/`, protected from the sandbox, so the agent cannot self-approve.
- Each entry's **filename** is a SHA-256 fingerprint of the normalized git remote URL, or the canonicalized project path when there is no remote. Remote URLs are normalized (SSH/HTTPS variants, credentials stripped, ports removed) so the same repo accessed via different URLs shares one trust entry.
- **The remote URL is not an authenticity signal.** It is attacker-controllable. A malicious repo can `git remote set-url origin <victim>` and copy the victim's approved `[propose]` block verbatim, so the content hash also matches, then look up the victim's trust entry and inherit its approved permissions. That is a confused-deputy escalation. To defeat it, every approval is **also bound to the repository it was granted in** — the shared git directory behind the checkout, recorded in `repo.git_dir` ([#516](https://github.com/navikt/cplt/issues/516)). Before applying a trust entry, cplt requires the current project directory to resolve to that same git dir. A matching fingerprint presented from a *different* repository is **not** auto-trusted and triggers a re-approval prompt. An attacker's clone is a different repository whatever it names as `origin`, and cannot become the victim's without already controlling it. The same binding is enforced when *writing*: `cplt trust accept` refuses outright when this origin's entry belongs to another repository, since one entry per origin means approving here would both inherit and overwrite that entry. An entry whose recorded repository cannot be resolved on disk is treated as orphaned and can be taken over — note that this covers more than a deleted repository: an unmounted volume, a renamed parent or a permission-denied ancestor all read as orphaned, so a live repository can lose its claim and its owner must re-approve on remount.
- **The binding is to the repository, not to one working tree.** It was the absolute checkout path until [#516](https://github.com/navikt/cplt/issues/516). `git worktree` gives one repository several checkouts, and one entry per origin can record only one path — so the second worktree was refused, and once approved it took the entry from the first. Trust ping-ponged between worktrees for as long as the workflow lasted. Every worktree reports the main checkout's `.git`, so one approval covers them all. A recorded git dir is **authoritative** and never falls back to the recorded path: that path is whichever checkout approved last, and a worktree workflow deletes those routinely, so a fallback would let a different clone dropped where a removed worktree stood inherit the approval. Anything git itself treats as the same repository is the same repository here, including a directory whose `.git` file points at one; that directory also gets the victim's committed `.cplt.toml`, since `[propose]` is read from `HEAD`, so it can only inherit an approval for the exact values the user reviewed. Nothing accumulates: it is still one entry, and the git dir is re-recorded on each approval rather than appended. Entries written before the field resolve the repository from `repo.path` instead, so an existing approval covers its worktrees without a re-approval; one with neither (pre-dating path binding) matches nothing and gets a one-time re-approval. **What still prompts, correctly:** a worktree on a branch that changed `[propose]`, because the content hash is what pins the values and it is untouched; and a repository with no `origin`, whose worktrees are fingerprinted by path and so hold separate entries that never overwrite each other.
- Trust writes are atomic (temp file plus rename) so an interrupted write cannot corrupt the store.

#### Threat scenarios

| Scenario | Mitigation |
|---|---|
| Maintainer adds `allow_docker = true` | No effect until each user explicitly approves |
| Agent modifies `.cplt.toml` at runtime | Read from `git HEAD`, not working tree; an uncommitted file grants nothing (`[deny]` only); writes kernel-denied |
| Maintainer changes proposed values after approval | Per-key hash mismatch invalidates the approval of each changed key |
| `.cplt.toml` blocks critical env vars via `[deny].env` | `[deny]` can only tighten, and removing env vars reduces attack surface |
| Path traversal in deny/allow paths | `..` components rejected at parse time |
| Agent self-approves via trust store | Trust dir (`~/.config/cplt/trust/`) is outside the sandbox |
| Origin-URL spoof to inherit a victim's approval (`git remote set-url origin <victim>` + copy `[propose]`) | Approvals are bound to the repository they were granted in — its shared git dir, which a separate clone cannot present; a match from a different repository is not auto-trusted, and `cplt trust accept` refuses to merge into or overwrite that entry |
| Partial approval used to renew a changed permission | A stale or foreign entry is discarded before merging, so accepting one key never re-pins another at its new value |

### GPG signing risk analysis (`--allow-gpg-signing`)

When `--allow-gpg-signing` is enabled, cplt grants targeted access to the GPG subsystem.

**What is exposed:**
- Read-only access to public data only: `~/.gnupg/pubring.kbx`, `pubring.gpg`, `trustdb.gpg`, `gpg.conf`, `common.conf`
- Unix socket connect to `~/.gnupg/S.gpg-agent`, which is IPC to the GPG agent daemon running outside the sandbox

**Platform note:** on macOS this grant is what makes the socket reachable — without `--allow-gpg-signing` the profile's `(deny default)` blocks the `connect()`. On Linux below kernel 7.1 the grant changes nothing, since Landlock cannot restrict `connect()` to a pathname unix socket before ABI v9, so the gpg-agent socket is reachable whether or not the flag is set. From v9 up the grant is what keeps it reachable, and it covers `/run/user/<uid>/gnupg` as well as `~/.gnupg`, since modern GnuPG keeps the real sockets in the runtime dir. The read denies on `~/.gnupg/private-keys-v1.d/` still hold on both platforms — but on Linux the "signature impersonation and decryption" risk described below is present by default, not opted into.

**What stays denied:**
- `~/.gnupg/private-keys-v1.d/` stays kernel-blocked. That is where the private keys live.
- `~/.gnupg/secring.gpg`, the legacy private keyring, is explicitly denied
- All writes to `~/.gnupg/`, so no modifications are possible
- `~/.ssh/` and `SSH_AUTH_SOCK`, since SSH signing is not enabled by this flag

**Key exfiltration is impossible.** The GPG agent uses the Assuan IPC protocol, which exposes `PKSIGN` (sign), `PKDECRYPT` (decrypt), `READKEY` (public key), and `KEYINFO` (metadata), but has **no command to export private key material**. The agent is a privilege-separation boundary by design. Even if the on-disk key files were not denied, they are encrypted with the user's passphrase.

**The actual risk is signature impersonation and decryption.** A compromised process with agent socket access can:
1. Request signatures via `PKSIGN`, signing arbitrary data including malicious commits
2. Request decryptions via `PKDECRYPT`, so if the user has an encryption subkey, the compromised process can decrypt arbitrary ciphertext

This is **not key theft**. The attacker cannot take the key with them, and operations only work while the sandbox is running and the agent connection is active.

**Risk context:** Copilot already has `git commit` ability and can make commits as the user. GPG signing only adds the "Verified" badge. The incremental risk is that a compromised agent can make commits that appear cryptographically verified by the user, and can decrypt data if an encryption subkey exists. Mitigating factors:
- The agent passphrase cache has a TTL, by default 10 min idle and 2 hr max
- The network proxy, when enabled, can audit or block pushes to unexpected remotes
- Branch protection rules may still require PR review regardless of signature status

**Deny-path override:** if `--deny-path ~/.gnupg` is specified alongside `--allow-gpg-signing`, the deny wins and all GPG allows are suppressed. This matches the project-wide principle that explicit denies always take precedence.

**Known limitations:**
- `GNUPGHOME` is not in `ENV_ALLOWLIST`, but it could be injected via `--pass-env` or `--inherit-env`, redirecting GPG to a directory outside the SBPL policy. The SBPL rules only cover `~/.gnupg/`.
- If `~/.gnupg` is a symlink, the GPG rules are emitted at its resolved target as well (see [Symlink attack protection](#symlink-attack-protection)). Signing through a symlinked `~/.gnupg` has no end-to-end test.

### Network limitations

#### SBPL network filtering limitations

Port filtering works. The host part is what SBPL cannot express.

**Ports are filterable, and cplt relies on it.** `src/sandbox_profile.rs` emits a blanket `(deny network-outbound (remote tcp))`, then `*:443` unless proxy-forced mode drops it, then one `*:PORT` per `--allow-port` — dropped by proxy-forced mode too, for the same reason ([#297](https://github.com/navikt/cplt/issues/297)) — then the localhost deny or allow, then a `localhost:PORT` carve-out per proxy port and per `--allow-localhost` port. SBPL is last-match-wins, so the ordering is the policy.

`real_profile_port_filtering_is_enforced_by_the_kernel` in `tests/integration.rs` runs a generated profile under `sandbox-exec` against two loopback listeners on ephemeral ports, one named in the profile and one not, and asserts the named one connects while the other does not. It is the only test here that proves the filtering filters rather than that the rule parses.

**The host part accepts only `*` or `localhost`.** A literal address such as `127.0.0.1` or `140.82.121.4` is a parse error, `"host must be * or localhost"`. So a rule can say "any host on this port" or "loopback on this port", and nothing narrower.

What follows from that:

- **No domain-based rules.** SBPL operates at the syscall level, not the application level, so it cannot match on hostnames. Domain filtering is the CONNECT proxy's job, see [Layer 2](#layer-2-connect-proxy-logging-and-domain-filtering).
- **No IP allowlisting.** Even if Copilot's API endpoints had stable IPs, which they do not, being CDN-backed, SBPL could not name them.
- **No loopback-only bind.** The `localhost` host matches `INADDR_ANY` (`0.0.0.0`), so `(allow network-bind (local ip "localhost:*"))` also permits binding on all interfaces. Processes inside the sandbox can therefore start listeners reachable on the network. Mitigations: outbound is locked to port 443 so there is no exfiltration via inbound connections, dev machines are typically behind NAT or a firewall, and the proxy intercepts all outbound traffic.

Port scoping is the kernel-level control; domain and host scoping happens one layer up, in the proxy.

#### Current state

Outbound TCP is allowed in the sandbox profile, restricted to port 443 plus `--allow-port`, and filesystem isolation stays the primary security control. See [Layer 2](#layer-2-connect-proxy-logging-and-domain-filtering) for what the proxy enforces, and [Proxy-forced mode](#proxy-forced-mode-53) for why the proxy is advisory by default and how to make it mandatory.

### Self-update security (`cplt update`)

The update mechanism downloads releases from GitHub, verifies SHA256 checksums, and atomically replaces the binary.

**Verified:**
- The SHA256 checksum is mandatory, and the update aborts on mismatch
- `--proto-redir =https` prevents an HTTP downgrade on redirects
- Archive validation requires exactly one regular file named `cplt`, no symlinks and no directories
- The extracted binary is verified via `symlink_metadata`, which rejects symlinks
- Absolute paths are used for system tools on macOS (`/usr/bin/curl`, `/usr/bin/shasum`, `/usr/bin/tar`) and Linux (`/usr/bin/sha256sum`, standard paths only, no bare PATH lookup)
- Replacement is atomic: stage to `.new`, set permissions, rename
- Staging happens in `~/.config/cplt/update/<128 random bits>`, not the system temp directory. Sandboxed agents can write throughout `/tmp` and `/var/folders`; `~/.config/cplt` is a hard deny (`DENIED_DOTFILES`), so a sandboxed process cannot reach the staged files at all
- The staging directory is created with `mkdir(2)` at mode 0700, which fails with `EEXIST` rather than adopting a directory that is already there
- The extracted binary is held open, and its `(dev, ino)` is re-checked before the unsandboxed `--version` probe and again before install. The install copies from that descriptor, so the bytes that are validated are the bytes that land on disk even if the path is repointed
- A package-manager-owned binary is never replaced. `cplt update` resolves its own path and refuses when Homebrew owns it (`/Cellar/`, `/homebrew/`) or, on Linux, when dpkg does — a path under `/usr` outside `/usr/local`, confirmed by `dpkg-query -S`. It prints that manager's upgrade command instead. Overwriting a managed binary leaves the package database describing a version that is no longer on disk, and the manager's next upgrade reverts the update without saying so. The dpkg probe fails open: a missing `dpkg-query`, an error, or a timeout all read as unmanaged, so a hand-installed `/usr/bin/cplt` still self-updates rather than being stranded with no upgrade path

**Not verified:**
- There is no cryptographic signature, neither GPG nor Sigstore. `SHA256SUMS` and the binary come from the same GitHub release, so a compromised release controls both. This matches most Go/Rust CLI tools but is weaker than signed package managers.
- The `--version` probe runs the freshly downloaded binary **unsandboxed**. The inode is pinned across that step, so it is the file cplt validated, but its provenance rests entirely on the SHA256 check above.
- On the sudo install path the binary is handed to `sudo install` by path, not by descriptor. The inode is re-checked immediately before, but the staging directory being private is what closes that window.

The Homebrew install path (`brew install navikt/tap/cplt`) uses Homebrew's own verification and is preferred on macOS.

The apt path ([navikt/apt](https://navikt.github.io/apt/)) is preferred on Debian
and Ubuntu. `apt` verifies the archive's OpenPGP signature on `InRelease` and the
package hashes chained from it, and refuses the archive outright if either fails.
Note what that does and does not buy: the signature covers the archive, and the
`.deb` in it is copied from the same GitHub release the checksums above come
from, so it attests that you got the bytes the archive publisher published, not
that the release itself is independently trustworthy.

`cplt update` recognises a Homebrew- or dpkg-managed binary, refuses to touch
it, and prints that manager's upgrade command. On an apt install, upgrade with
`sudo apt upgrade cplt`; that is the route that keeps dpkg's database honest.
The `.deb` itself carries no signature and no checksum list, so its integrity
rests on the archive signature above, or on the GitHub release it was
downloaded from, not on dpkg.

### Install script security (`install.sh`)

The install script downloads from GitHub Releases and verifies SHA256 checksums.

**Caveat:** if the `SHA256SUMS` file cannot be downloaded, or no hash utility is available, the script prints a warning and **continues without verification**. This is a deliberate trade-off for usability in minimal CI environments.

For high-security environments, verify the binary manually:
```bash
curl -fsSL -o cplt.tar.gz "https://github.com/navikt/cplt/releases/latest/..."
curl -fsSL -o SHA256SUMS "https://github.com/navikt/cplt/releases/latest/.../SHA256SUMS"
sha256sum -c SHA256SUMS --ignore-missing
```

### Discovery and `cplt doctor`

`cplt doctor` probes the environment by running `--version` on all known agent binaries found in PATH (copilot, opencode, antigravity, claude). These commands run **outside the sandbox** with full user privileges.

Trust model: cplt trusts that binaries in your PATH are legitimate, the same trust model as typing `copilot --version` yourself. If you don't trust a binary in your PATH, remove it before running `cplt doctor`.

### Config file trust model

`~/.config/cplt/config.toml` and `~/.config/cplt/trust/*.toml` are trusted inputs read before sandboxing. They are not permission-checked. The trust model assumes `$HOME` is protected by OS-level permissions (0700 or 0755).

On shared systems, give `~/.config/cplt/` restrictive permissions (0700). A user who can write to this directory can weaken the sandbox configuration.

`CPLT_CONFIG` moves that trusted input somewhere else, replacing the whole file — every `[sandbox]` key included. It is read from the ambient environment, so a shell that auto-loads repository-provided environment (direnv's `.envrc`, mise) can set it just by you entering a directory, and the repo-config trust model below (which only ever lets a repository *tighten* the sandbox) never sees it.

Two guards keep that visible rather than silent:

- A `CPLT_CONFIG` outside `~/.config/cplt/` prints a warning naming the resolved file. It is deliberately not suppressed by `--quiet` — a quiet run is when a silent substitution costs the most.
- A `CPLT_CONFIG` that resolves **inside the project directory, or inside any named repository**, is refused and cplt exits non-zero. The second check is separate because the first has to run before the config is loaded, and the named set comes out of the local layer that load produces; a named root is agent-writable and project-grade, so a config file inside one is the same confused deputy one repository over. Falling back to the real user config would be another invisible substitution, so this fails loudly instead. Symlinks and `..` are resolved before the comparison, so a path outside the repo that links back into it is refused too.

Neither guard covers a repository that writes a config *outside* the project and points `CPLT_CONFIG` at that. The warning is what makes that case visible.

### Scratch directory session IDs

Session IDs for per-session scratch directories come from `/dev/urandom` (16 random bytes, hex-encoded), falling back to PID plus nanosecond timestamp if `/dev/urandom` is unavailable, which is not expected on standard macOS or Linux. The fallback is predictable, but the failure mode is denial-of-service (directory creation fails if it already exists), not compromise.

## Test strategy

### Unit tests (cross-platform, run on Linux CI)

These test core logic without invoking `sandbox-exec`, using the real library functions rather than duplicated copies:

| Category | Tests | What's verified |
|---|---|---|
| Unsafe root detection | 11 | Rejects `/`, `/Users`, `/tmp`, `/var`, `/Applications`, `/System`, `$HOME`; allows project subdirs |
| SBPL injection | 5 | Rejects `\n`, `\0`, `"`, `(`; allows normal paths |
| Domain blocking | 7 | Exact match, subdomain match, no partial match, comments, case-insensitive, empty blocklist |
| Private IP detection | 11 | Loopback, RFC 1918, link-local, unspecified, CGNAT, benchmarking, reserved, ULA, link-local v6 |
| Hostname detection | 3 | localhost, .localhost, .local patterns; allows normal hostnames |
| Profile generation | 35 | Uses real `generate_profile()`; verifies deny-default, project access, sensitive dir/file blocks, network rules, deny-after-allow ordering, exec-from-tmp denied, env file deny/allow, copilot caches carve-outs, tool dir permissions, scratch dir rules |
| Home tool dirs | 1 | All runtime entries present in `HOME_TOOL_DIRS` |
| Env allowlist | 3 | Essential vars included, dangerous vars excluded, runtime vars present |
| Env behavior | 17 | Sanitization, hardening injection, pass-env overrides, LANG prefix leak prevention, YARN hardening bypass prevention, scratch dir TMPDIR redirect, JAVA_TOOL_OPTIONS injection/append/override |
| Config parsing | 24 | TOML parsing, CLI/config merge precedence, tilde expansion, SBPL validation, scratch dir, allow-tmp-exec |

### Integration tests (macOS only, 55 tests)

Most of these invoke `sandbox-exec` with real Seatbelt profiles and verify **kernel-level enforcement**. Three do not, and are marked below: they generate profile text and assert on it, which proves a rule is emitted, not that the kernel honours it.

| Category | Tests | What's verified |
|---|---|---|
| File access | 7 | Project read/write, copilot config, temp write, process execution, `git` execution, Copilot package dir write blocked |
| Sensitive dir and file blocks | 8 | `~/.ssh`, `~/.aws`, `~/.docker`, `~/.kube`, `.netrc`, `.npmrc`, credentials planted in a temp `HOME`, and `--deny-path` overriding `--allow-read` |
| Git repository protection | 5 | Writes to `.git/hooks`, `.git/config`, `.gitmodules`, and `.cplt.toml` blocked; local git config and the global ignore file stay readable |
| Temp and scratch exec | 3 | Exec from `/tmp` blocked by default, allowed with `--allow-tmp-exec`, allowed inside the scratch dir |
| Env files | 5 | `.env` read, symlink read, and delete blocked; allowed with `--allow-env-files`; key files by extension (`server.pem`) readable by default and blocked with `sandbox.deny_key_files_by_extension` |
| GPG signing | 4 | Default blocks `~/.gnupg`, flag allows pubring read, private keys stay denied, writes stay denied |
| Network | 10 | Outbound blocked by default, a port named in the profile reachable while an unnamed one is not, localhost blocked by default and allowed with `--allow-localhost-any`, Java localhost with and without `preferIPv4Stack`, localhost TCP bind, and the wildcard-bind SBPL limitation. Two are text-only: that the default profile emits `*:443`, and that proxy-forced emits the `localhost:<port>` pin and drops `*:443` |
| Unix sockets | 6 | JVM Attach sockets in `/tmp` and `/var/folders` allowed, MSBuild worker-node socket allowed and blocked without the flag, SSH agent blocked, arbitrary `/tmp` sockets blocked |
| Clipboard | 3 | The clipboard is denied by default; `pbpaste` and `pbcopy` are blocked, and `--allow-clipboard` drops the rule |
| Binary CLI | 5 | Version, help, root/home dir rejection. The `--print-profile` proxy-forced check is text-only, since `--print-profile` never invokes `sandbox-exec` |

### E2E project tests (macOS only, 49 tests)

End-to-end tests using realistic project scaffolding (Node, Go, Python, Rust, Java/Maven, Kotlin/Ktor, .NET) with fake agent scripts:

| Category | Tests | What's verified |
|---|---|---|
| Per-language file ops | 9 | Read/write files in Node, Go, Python, Rust, Ktor, Maven, Kotlin/Maven, and multi-module Maven layouts |
| Git workflows and persistence | 8 | init/commit/status/diff/log, multi-step edit cycles, `.git/hooks` writes blocked including via a nested or renamed git dir, a granted sibling repo, and a bare repo |
| Post-session audit | 1 | The audit report names the writable roots it did not audit |
| Security matrix | 4 | Secret files blocked (`.env`, `.pem`, `.key`), all `.env` spellings blocked, home secrets (`~/.ssh`, `~/.aws`), env var sanitization |
| Mode combinations | 7 | allow-env-files, scratch-dir exec, deny-path, config file, external allow-read, proxy mode, spawning common tools |
| Proxy behavior | 5 | Proxy env vars injected and absent without the flag, port filtering, allowlist blocking an unlisted domain, audit log written |
| Go toolchain | 4 | `go build`, `go test` with the scratch dir, `GOCACHE` redirect, `go test` blocked without a scratch dir |
| .NET and MSBuild | 3 | `dotnet build` with `--allow-msbuild`, the MSBuild Server env opt-out, the socket blocked without the flag |
| Gradle | 3 | Build over the Gradle daemon unix socket, the daemon socket itself, macOS Gradle sandbox opt-out |
| JVM env and exec | 5 | Maven env passthrough, `JAVA_TOOL_OPTIONS` injection and append, native lib exec from the JVM tmpdir, JVM cache dir permissions |

### Smoke tests (macOS only, 6 tests, `#[ignore]`)

Real Copilot CLI integration tests requiring authentication and network access:

| Test | What's verified |
|---|---|
| `smoke_copilot_version` | Copilot outputs version string inside sandbox |
| `smoke_copilot_list_models` | API call returns model list (JSON) |
| `smoke_copilot_simple_prompt` | Chat completion returns response containing UUID canary |
| `smoke_copilot_file_context` | Copilot reads project file and references its content |
| `smoke_copilot_write_file` | Copilot creates a new file on disk (side-effect assertion) |
| `smoke_env_vars_denied` | `SUPER_SECRET_TOKEN` not visible inside sandbox |

### CI pipeline

The GitHub Actions workflow runs in two stages:

1. **Linux (ubuntu-latest):** formatting check (`cargo fmt`), linting (`cargo clippy -D warnings`), unit tests
2. **macOS (macos-latest):** full test suite including integration tests, release binary build and verification

## Prior art and references

### macOS Seatbelt / sandbox-exec

- [Apple sandbox-exec(1) man page](https://keith.github.io/xcode-man-pages/sandbox-exec.1.html). Official documentation for the command-line sandbox tool.
- [Chromium Seatbelt V2 Design](https://chromium.googlesource.com/chromium/src/sandbox/+show/refs/heads/main/mac/seatbelt_sandbox_design.md). How Chromium designs and maintains Seatbelt profiles for browser process sandboxing; influenced our deny-default plus bsd.sb import approach.
- [HackTricks: macOS Sandbox](https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox/index.html). Security research on Seatbelt internals, bypass techniques, and rule evaluation.
- [A New Era of macOS Sandbox Escapes (POC2024)](https://jhftss.github.io/A-New-Era-of-macOS-Sandbox-Escapes/). Recent CVE research on sandbox escape via XPC/Mach services; informed our understanding of Seatbelt's limitations.
- [michaelneale/agent-seatbelt-sandbox](https://github.com/michaelneale/agent-seatbelt-sandbox). Early proof-of-concept for sandboxing AI coding agents with Seatbelt; validated the basic approach.

### DNS rebinding and SSRF prevention

- [OWASP SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html). Authoritative guidance on validating resolved IPs rather than hostnames, and pinning addresses to prevent TOCTOU attacks.
- [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918). Private IPv4 address ranges (10/8, 172.16/12, 192.168/16).
- [RFC 4193](https://datatracker.ietf.org/doc/html/rfc4193). IPv6 Unique Local Addresses (fc00::/7).
- [RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598). CGNAT shared address space (100.64.0.0/10), important for Tailscale and WireGuard environments.
- [RFC 4291](https://datatracker.ietf.org/doc/html/rfc4291). IPv6 addressing architecture (loopback, link-local, IPv4-mapped addresses).

### Secure temporary files

- [CWE-377: Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html). Why the SBPL profile is never written to a temp file at all, and why the files that do live in the scratch dir use `O_CREAT|O_EXCL` with mode `0600`.
- [CWE-59: Improper Link Resolution Before File Access](https://cwe.mitre.org/data/definitions/59.html). Symlink attacks on predictable temp paths.

### AI agent sandboxing (broader context)

- [GitHub Copilot Workspace sandbox settings](https://docs.github.com/en/copilot/customizing-copilot/customizing-copilot-in-your-ide). VS Code's built-in sandbox options for Copilot (terminal command restrictions).
- [Copilot cloud agent firewall](https://docs.github.com/en/enterprise-cloud@latest/copilot/customizing-copilot/customizing-or-disabling-the-firewall-for-copilot-coding-agent). GitHub's server-side network firewall for the cloud coding agent.
- [Copilot allowlist reference](https://docs.github.com/en/copilot/reference/copilot-allowlist-reference). Default allowed domains for the Copilot cloud agent.
- [OpenAI Codex sandbox](https://platform.openai.com/docs/guides/codex). OpenAI's approach to sandboxing code execution with network and filesystem restrictions.
- [Anthropic Claude Code permissions](https://docs.anthropic.com/en/docs/claude-code/security). Permission-based tool approval model for local agent execution.

### Supply chain attack research

- [Mend.io: Shai-Hulud npm worm analysis (2025)](https://www.mend.io/blog/npm-supply-chain-attack-packages-compromised-by-self-spreading-malware). Self-replicating worm that compromised 700+ npm packages.
- [Wiz: Shai-Hulud 2.0, 25K+ repos exposed](https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack). Second wave and blast radius analysis.
- [Socket: 60 malicious npm packages](https://socket.dev/blog/60-malicious-npm-packages-leak-network-and-host-data). Network recon exfiltration to Discord webhooks.
- [Oligo: npm supply chain risks with AI agents](https://www.oligo.security/blog/the-hidden-risks-of-the-npm-supply-chain-attacks-ai-agents). How AI coding agents amplify supply chain attacks.
- [ReversingLabs: npm reverse shell malware](https://www.reversinglabs.com/blog/malicious-npm-patch-delivers-reverse-shell). Patched legitimate packages delivering reverse shells.
- [Rafter: AI Agent Security Incident Timeline (2025-2026)](https://rafter.so/blog/incidents/ai-agent-security-timeline-2025-2026). Timeline of agent security incidents.
- [CamoLeak: Copilot Chat exfiltration (CVE-2025-59145)](https://rafter.so/blog/incidents/camoleak-invisible-exfiltration-channel). Invisible data exfiltration via GitHub image proxy.
- [LOTS Project, Living Off Trusted Sites](https://lots-project.com/). Catalog of legitimate domains abused for C2 and exfiltration.
- [Veracode: npm C2 via Ethereum smart contracts](https://www.veracode.com/blog/54-new-npm-packages-found-beaconing-to-c2-server-in-ethereum-smart-contract/). Dead-drop C2 rotation technique.

## Reporting security issues

If you discover a vulnerability in cplt, please report it responsibly:

1. **Do not** open a public GitHub issue
2. Contact the team via Nav's internal security channels
3. Include a description of the vulnerability, steps to reproduce, and potential impact

We aim to acknowledge reports within 48 hours and provide a fix within one week for critical issues.