Coding Agent Auto-Approve: A Risk Model for Unattended Runs

Coding agent auto-approve is defensible only when three things hold at once: the agent reads trusted input, it runs inside a real sandbox with restricted egress, and no long-lived credentials are reachable from inside it. If any one of the three fails, skip-permission mode turns whoever controls the repo, the issue tracker, the dependency tree or the MCP server into the operator of your shell.

What auto-approve actually does across Claude Code, Codex CLI, Cursor and friends

Auto-approve removes the human confirmation between the model choosing an action and that action running. Every tool uses roughly the same label, but each removes a different step, and some drop the sandbox along with the prompt. Most agents ship a mix of five permission models:

• Per-action prompt: every shell command or edit waits for a click.
• Rule matching: allow, deny and ask rules keyed on tool name and argument prefix.
• Edit-only auto-accept: file writes go through, commands still need approval.
• Full auto-approve: nothing is confirmed, and the sandbox may or may not still apply.
• Headless: no UI at all, common in CI and cloud agents.

Vendor surfaces as of this writing are below. Flag names change between releases, so check the version you have installed.

Agent	Auto-approve surface	Sandbox story
Claude Code	--dangerously-skip-permissions; defaultMode values such as acceptEdits and bypassPermissions; allow/deny/ask rules; PreToolUse hooks	Docs say to use the flag only in an isolated container; vendor ships a reference devcontainer
Codex CLI	--full-auto versus a separate flag that bypasses both approvals and sandbox	Seatbelt on macOS, Landlock plus seccomp on Linux, only while the sandbox stays enabled
Gemini CLI	--yolo, --approval-mode	--sandbox wraps execution in Docker, Podman or Seatbelt
Cursor	Auto-Run with allowlist, denylist and protected files	Host by default
Cline / Roo Code	Per-category toggles (read, edit, execute, MCP, browser) plus a request cap	Host by default
Aider	--yes-always, auto-commit, auto-lint, auto-test	Host; the lint and test hooks are a second execution surface

The comparison that matters most is skip-permissions on the host versus sandboxed full-auto. The model has identical autonomy in both, and the blast radius is entirely different. Codex’s --full-auto keeps the sandbox on; its full bypass mode does not. In Cline, the dangerous toggle is command execution, not file editing.

When is coding agent auto-approve defensible?

It is defensible when input trust, sandbox strength and credential exposure together form a closed system. Each axis has tiers:

• Input trust: trusted (your own code, pinned and vetted dependencies), mixed (a normal repo with third-party packages, docs fetches, first-party MCP servers), adversarial (external PRs, public issues, arbitrary web content, community MCP servers).
• Sandbox strength: host, process sandbox (Seatbelt, Landlock, seccomp, bubblewrap), container with egress allowlist, ephemeral CI runner, microVM (Firecracker, gVisor).
• Credential exposure: none, short-lived and scoped to the task, ambient and long-lived.

“Trusted input” is a smaller category than most teams assume. A repo you wrote still has a lockfile that resolves to someone else’s code, test fixtures, READMEs copied from upstream, and agent config files that load from the checkout. Treat a normal product repo as mixed unless you control every resolved dependency.

A fourth axis, reversibility, does not prevent compromise but sets its price. Branch protection, throwaway clones, read-only remotes and time-boxed sessions decide whether a bad run costs an hour or a release.

The decision matrix

Classify each repo and runtime before anyone enables auto-approve. Every amber row needs its compensating control in place first. Third-party MCP servers get their own row because they move both input trust and credentials at once.

Input	Runtime	Credentials	Verdict	Condition / compensating control
Trusted	Ephemeral container, no network	None	Green	Destroy the container after each task
Trusted	Process sandbox, workspace-write only	None	Green	Confirm the bypass flag did not also disable the sandbox
Mixed	Container, egress allowlisted to registry proxy	None	Amber	Pinned lockfile, install scripts disabled or vetted, proxy logs retained
Mixed	Ephemeral CI runner	Short-lived, own-branch push only	Amber	Branch protection, no publish tokens in the job, required human merge
Adversarial	MicroVM, egress allowlist	None	Amber	Output is a diff for review; nothing else leaves the VM
Adversarial	Container, open egress	None	Red for private code	The repo itself is the secret; open egress exfiltrates it
Mixed	Devcontainer with SSH agent forwarded	Ambient	Red	The forwarded socket signs pushes to every repo the key can reach
Any	Container with /var/run/docker.sock mounted	Any	Red	The Docker socket is root on the host
Trusted	Host	Ambient cloud, SCM or npm tokens	Red	One poisoned dependency makes “trusted” false
Adversarial (third-party MCP tool output and descriptions)	Any	SaaS tokens held by the MCP server	Red	Amber only if the server is pinned, reviewed and its token is read-only

Model quality never appears as a variable. Every verdict depends on the environment.

Is –dangerously-skip-permissions safe inside Docker?

It can be, but only if the container is actually isolated, and a default docker run is not. A container shares the host kernel and usually has unrestricted egress. Developers also tend to mount ~/.aws, a kubeconfig, a .env file or the Docker socket so the agent can “do its job.” Any one of those mounts turns the sandbox into packaging.

To count as the boundary in the matrix, a container needs:

• No Docker socket, no home-directory bind mounts, no forwarded SSH agent.
• Egress denied by default and allowlisted to the package registry or an internal proxy.
• No cloud metadata access. On EC2, enforce IMDSv2 with a hop limit of 1 so containers cannot reach 169.254.169.254.
• A rootless runtime or user namespaces, and destruction after the task.

Anthropic’s guidance agrees: use --dangerously-skip-permissions only inside an isolated container, ideally with no network access. Its reference devcontainer exists because the vendor treats isolation, not the prompt, as the control.

Sandbox versus approval prompt

A sandbox enforces a limit in the kernel. An approval prompt asks a tired human to enforce it. Seatbelt profiles, Landlock rulesets and seccomp filters deny the syscall no matter what the model was persuaded to try. One caveat on Landlock: unprivileged processes can use it since Linux 5.13, but it is self-imposed, so it only binds if the launcher applies it before the agent starts. A bypass flag can simply skip that step.

Approval fatigue is a documented failure mode. Once an agent asks forty times an hour, users click through by reflex and the human in the loop becomes a rubber stamp. Diff review fails the same way: it catches the visible code change and misses a new postinstall script deep in the lockfile, invisible Unicode in a rules file, or a secret that already left through a DNS lookup.

The prompt is a human-factors control; the sandbox is the security control. Write policy for the unattended 2 a.m. run, not the supervised demo.

How do you allowlist commands without a trivial bypass?

Assume every allowlist rule authorizes the full argument space of the command it names, and grant only commands whose full argument space you can live with. Prefix rules such as Bash(git:*) or Bash(npm run:*) approve syntax, not intent:

• git covers push, config changes, hook installation, and pager or editor settings that run arbitrary programs.
• npm run runs whatever script the repo, or the agent, defines.
• find -exec, xargs, python -c, bash -c and decode-then-execute chains collapse any distinction you thought you drew.

Denylists are weaker than allowlists: block rm -rf and curl and the attacker moves to an interpreter one-liner. Allowlists, in turn, are weaker than a sandbox. Practical hygiene:

• Allow exact commands (npm test, git status, git diff), not tool families.
• Deny reads on credential paths: .env*, ~/.ssh, ~/.aws, ~/.npmrc, kubeconfig. Read access is the first half of exfiltration.
• Enforce policy in a PreToolUse hook or a runtime layer that resolves symlinks and parses the full command, so the decision is deterministic code rather than a string prefix. Our open-source runtime firewall for AI coding agents takes this approach.

Does auto-approve increase prompt-injection risk?

Auto-approve does not make injection more likely to land, but it removes the last thing that stopped a successful injection from executing. Prompt injection, listed as LLM01:2025 in the OWASP Top 10 for LLM Applications 2025, is architectural: untrusted text reaches a system that follows instructions and holds tool authority. Better models lower the hit rate without eliminating the class.

Simon Willison’s lethal trifecta names the exploitable condition: access to private data, exposure to untrusted content, and a way to communicate externally. A coding agent has the first two by design. Before auto-approve, a human had to approve the outbound step: the curl, the git push, the web fetch carrying a query string. Without that check, your remaining controls are the egress allowlist and the absence of credentials worth stealing.

Repo-local config is the injection path most teams overlook. CLAUDE.md, .claude/settings.json, .mcp.json, .cursor/rules, AGENTS.md, GEMINI.md and .github/copilot-instructions.md load from the checkout, so whoever controls the repo controls them. We walked through one variant in the AGENTS.md downloads hijack.

Third-party MCP servers

A third-party MCP server should not get auto-approval for anything that writes, sends or queries data with your tokens. Auto-approving MCP calls is a separate grant from auto-approving shell commands, and it widens the blast radius with no shell involved. A tool that reads a private repo plus a tool that opens a public PR is enough for data theft.

• Locally written servers: auto-approve read tools after review; keep writes gated.
• First-party vendor servers (GitHub, Supabase and similar): the code is trustworthy, the data it returns is not. Scope tokens to read-only and one project.
• Community servers: pin by hash, review tool descriptions (they are prompt text), never auto-approve.

Watch the config file too. A server definition written into .cursor/mcp.json or .mcp.json persists across sessions. Our MCP server and tool-chain security testing covers tool-description poisoning, token scope and config persistence.

What the 2025 incidents show

The public record from 2025 maps cleanly onto the matrix. None of these incidents needed a jailbreak; each exploited authority the agent already had.

• s1ngularity (Nx, August 2025): malicious postinstall code in compromised Nx packages invoked locally installed AI CLIs in their permission-skipping modes and told them to hunt the filesystem for secrets, which were then published through GitHub. Matrix row: trusted, host, ambient tokens. Red.
• GitHub MCP injection (Invariant Labs, May 2025): text in a public issue steered an agent into reading private repos and leaking their contents into a public PR. No CVE, no exploit code, only untrusted input plus tool authority. Matrix row: third-party input with SaaS tokens.
• Supabase MCP (mid-2025): instructions planted in support-ticket data led an agent holding a privileged token to run SQL that exposed sensitive tables. Failed axes: input trust and credential scope.
• CVE-2025-54135 “CurXecute” and CVE-2025-54136 “MCPoison” (Cursor, disclosed August 2025; Check Point Research published MCPoison): Cursor’s MCP configuration became a path to command execution and, after one approval, to persistence. Failed axis: repo config treated as trusted.
• Amazon Q Developer extension (July 2025): a tampered marketplace build shipped instructions telling an agent with shell access to wipe data. Failed axis: the supply chain of the agent itself.
• CVE-2025-49596 (MCP Inspector, 2025): an unauthenticated developer tool reachable on the network allowed remote code execution. The lesson: local-only agent tooling is still attack surface.

Counts and affected versions vary between reports, so check the vendor advisories for indicators and exact versions.

Is full-auto acceptable in CI/CD, and how do you audit it?

Yes, and CI is often the best place for it, because a runner can deliver what a laptop cannot: an ephemeral environment, egress controls and per-job tokens. GitHub’s Copilot coding agent is the vendor reference design. It runs in an ephemeral Actions environment behind an egress firewall and can push only to its own branch. The allowlist is configurable, so audit what your org has added to it.

CI becomes the worst place for full-auto when the job inherits org secrets: an npm publish token in the environment, a cloud deploy role on the runner, or a workflow triggered by external PRs with write permissions. Apply the matrix per job, not per pipeline. Agent jobs hold no publish or deploy secrets, use a minimal GITHUB_TOKEN or a short-lived app token scoped to one repo, and never run with secrets on fork-triggered events.

Audit and compliance

Keep your own record rather than relying on the vendor’s telemetry for incident response. Under your own retention policy, you need:

• Full session transcripts, including content the agent read, since that is where an injection lives.
• Structured tool-call logs from PostToolUse hooks: command, arguments, exit code, files touched.
• Egress proxy logs from the sandbox.
• Git provenance: agent commits signed by a dedicated identity, separable from human commits.

SOC 2 and ISO 27001 auditors will ask about access control, change management and logging for any automated actor that modifies code. A least-privilege non-human identity plus retained logs answers all three. The EU AI Act mainly governs AI providers and high-risk uses, not internal dev tooling, but its emphasis on logging and human oversight is a sound baseline. NIST AI RMF and MITRE ATLAS supply shared vocabulary for the risk register.

The checklist for this week

1. Token inventory per repo and job: SSH agent sockets, ~/.aws, gh auth, npm and PyPI tokens, kubeconfig, .env files, the Docker socket, IMDS reachability, the agent’s own API key. Remove all of it wherever auto-approve is on.
2. Sandbox spec: egress denied by default, registry proxy allowlisted, no socket or home mounts, destroyed after each task.
3. Input-trust audit: tag every repo trusted, mixed or adversarial, list its MCP servers by origin, and enable auto-approve only in green and amber cells with their controls in place.
4. Flag test: confirm on your installed version that the bypass flag did not also turn off the sandbox.
5. Logging: transcripts, tool-call logs, proxy logs and signed agent commits, retained under your policy.

FAQ

Is Claude Code's –dangerously-skip-permissions safe?

Only inside an isolated container or VM with restricted egress and no credentials mounted, which matches Anthropic's own guidance. On a developer host with SSH keys, cloud credentials or tokens, it lets any injected instruction run as you.

What is YOLO mode in a coding agent?

It is the informal name for full auto-approve, exposed as –yolo in Gemini CLI and under other names elsewhere. The agent runs shell commands, edits and tool calls without asking. Whether it stays sandboxed depends on the tool and on separate flags.

Is Codex CLI –full-auto the same as bypassing the sandbox?

No. –full-auto keeps the sandbox (Seatbelt on macOS, Landlock plus seccomp on Linux) and automates approvals inside it. A separate mode disables both approvals and the sandbox. Check the flag names on your installed version.

Should MCP tools be auto-approved?

Only read tools on servers you wrote and reviewed. First-party vendor servers should get read-only, single-project tokens. Community servers should be pinned, have their tool descriptions reviewed, and never be auto-approved.

Can an unattended coding agent exfiltrate secrets?

Yes, if it can read them and reach the network. The s1ngularity attack in August 2025 used AI CLIs in permission-skipping modes to search hosts for secrets. Remove ambient credentials and deny egress by default.

If you want to know what your coding agents can be made to do with the access they already have, our AI agent penetration testing tests each axis of this matrix against your real repos, runners and MCP servers.