Skip to main content
Status: planned, phase 1 in progress. This section documents an approved architecture; the roadmap tracks what exists today.
Stop asking the agent for permission. Put it somewhere it can’t hurt anything, then let it run.
Today’s safety model is fine-grained permission lists — roughly 640 allow/ask/deny entries rendered into Claude Code, Codex CLI, and Gemini CLI — running on a trusted Mac with the user’s full credentials a keychain prompt away. That model assumes a human is watching. Autonomous agents invert it: safety becomes the container boundary, and tool permissions inside it become maximally lenient. The agent gets --dangerously-skip-permissions precisely because there is nothing dangerous left to skip into.

The vendors all converged on this

All three CLI vendors publish the same guidance: bypass flags belong only inside an isolated environment, and the real controls are credentials, network egress, and git.
VendorBypass mechanismIsolation guidance
Anthropic--dangerously-skip-permissionsOnly inside a devcontainer or sandbox; hard-rejected when running as root. Agent SDK secure deployment: never mount host secrets, inject credentials from outside, credential-injecting proxy as the end-state.
OpenAI Codexapproval_policy + sandbox_mode axes--yolo (danger-full-access + never) only inside a container; network is off by default even in workspace-write.
Google Gemini--approval-mode yoloSandbox is opt-in and not coupled to yolo — the weakest pairing of the three, so this architecture enforces the coupling structurally: yolo configs exist only inside the image.
The convergent model: the container is the boundary; bypass flags only inside it; default-deny egress; short-lived scoped credentials injected from outside; git as the safety net.

Three profiles

Profiles are defined once in nix-ai and rendered to all three tools by the existing formatter layer. See nix-ai for the rendering pipeline.
ProfileWhereClaudeCodexGemini
interactiveMac host (unchanged)current allow/ask/deny + auto modeworkspace-write + approvalsauto_edit
autonomousinside containers ONLYbypassPermissions + ~10-entry residual deny; claude -p --bare --dangerously-skip-permissionsapproval_policy="never", sandbox_mode="danger-full-access" (the container IS the sandbox; bwrap can’t nest)--approval-mode yolo, Gemini’s own sandbox off
ciActions runnersautonomous + JSON output overlaysamesame

What happens to the 640 entries

They survive only in interactive. The autonomous profile keeps a residual deny of roughly ten entries — gh repo delete, gh secret, force-push, registry publish — as a tripwire, not a wall. In autonomous, the real protection is:
  • Credential scoping — the agent holds only short-lived, narrowly scoped tokens. See Secrets.
  • Network boundary — an allowlisting egress proxy is the only way out. See Runtime.
A permission list cannot protect an unattended agent anyway: anything the config allows, a confused or compromised agent will do, and anything it asks about blocks forever with no human present. Boundaries that hold without a human are the ones made of credentials and packets.

Structural guarantees

Two invariants are enforced in code, not convention:
  1. Autonomous configs are only ever baked into the container image. No code path renders a bypass-mode settings file onto a host filesystem. You cannot accidentally run yolo on the Mac because the config to do so does not exist there.
  2. The entrypoint refuses to start unless AGENT_SANDBOX=1 is set and the uid is not 0. Claude Code independently hard-rejects bypass as root; the image runs as agent (uid 1000) with no sudo.
The container boundary is only as strong as what crosses it. Never mount host secrets, the Docker socket, or writable host paths into an agent container. The runtime page defines exactly what an agent container may see.

In this section

Runtime

One Nix-built OCI image, two platforms, the egress proxy, and the run lifecycle.

Secrets

Dual backbone — OpenBao for dynamic credentials, Infisical for static app secrets — and the credential security ladder.

GitHub access

GitHub App + broker replaces the 5-tier PAT system.

Roadmap

Phases 1–7 and the repo ownership map.