AI Coding Agent Permissions: What Is Safe to Auto-Approve?

Permission prompts become work of their own when an AI coding agent runs tests, edits files, and repeats the same commands throughout a task. After enough interruptions, approving everything can feel like the only practical option.

It is not. Auto-approval and full permission bypass are different choices. A useful default is to allow edits and checks inside the workspace while keeping explicit boundaries around network access, secrets, remote Git operations, and deployment.

Three questions are more useful than asking whether a command looks safe:

Does its effect stay inside the current workspace?
Can Git or a disposable worktree restore the previous state?
Does it immediately affect an external system or another person?

If all three answers are favorable, the action is a candidate for auto-approval. If any answer is unclear, prompt for approval or block it.

Codex and Claude Code use different configuration names, but both let you constrain autonomous work with sandbox and permission rules. Product modes can change. The underlying decision—scope the action and make recovery explicit—remains useful.

A sandbox and an approval policy solve different problems

Codex separates two security controls:

The sandbox defines what files and network destinations a generated command can technically reach.
The approval policy decides when the agent must stop and ask before crossing a boundary.

With the workspace-write sandbox, Codex can work inside the active workspace while command network access stays off by default. Disabling prompts does not remove that sandbox. The agent can continue autonomously only within the remaining boundary.

Claude Code offers allow, ask, and deny rules for tools and commands. Deny rules take precedence, followed by ask and allow. That makes it possible to approve known local checks while blocking secret files or remote operations.

Control	What it decides	Typical failure
Sandbox	Reachable files and network	One approval grants access to a wider area than expected
Approval policy	When the user must confirm	Prompt fatigue or excessive autonomy
Allow and deny rules	Exceptions for a tool or command	A broad pattern includes dangerous subcommands

Start by making the sandbox small. A narrow technical boundary with useful autonomy is easier to reason about than broad host access guarded only by command-name rules.

Classify actions by reversibility

The same program can perform very different operations. git can read a diff or push to a shared branch. npm can print its version or run lifecycle scripts from a downloaded package. Granting permission to the entire program collapses those risks into one rule.

Action	Default policy	Reason
Search and read ordinary project files	Allow	Does not change local state
`git status`, `git diff`, `git log`	Allow	Reads repository state
Edit code inside the workspace	Allow with conditions	Reversible with Git, but existing user changes need protection
Unit tests, type checks, lint	Allow after inspection	Usually local, but project scripts can have side effects
Install dependencies	Ask	Uses the network, changes lockfiles, and may run install scripts
`git commit`	Only when requested	Reversible locally, but creates project history
`git push` or merge a PR	Ask	Changes remote state and affects collaborators
Read secrets	Deny by default	Disclosure cannot be reverted with Git
Deploy or change data	Ask	Direct effect on users or operational data
Delete files or rewrite history	Ask or deny	High recovery cost and easy scope mistakes

Workspace edits are safe to automate only when the repository is version-controlled and the agent can distinguish its changes from work that already existed. If user edits and agent edits are mixed, rollback can destroy the wrong work.

Local checks are safe only after you inspect the script

Search, file reads, and git diff happen repeatedly during normal agent work. Prompting for each one adds friction without adding much protection. Local tests and lint checks are also good candidates for auto-approval—but only after their implementation is understood.

A script named test may start Docker containers, reset a database, update snapshots, or call a remote service. Before approving it, confirm that:

production credentials are not present in the shell environment;
test and production databases are separate;
snapshot updates and code generation are explicit steps;
failure cannot affect anything outside the working copy.

The name pnpm test does not make a command harmless. Its actual script does.

Do not allow an entire package manager

Approving npm, pnpm, yarn, or pip as a whole removes many prompts, but it can also include installation, global changes, and publishing.

Dependency installation usually does three things at once:

contacts a registry;
changes a lockfile and dependency directory;
may execute package-provided lifecycle scripts.

Allow reviewed project commands such as pnpm test, pnpm lint, and pnpm build. Keep pnpm add, npm install, and pip install interactive. A broad pattern such as npm * may also cover npm publish, which is far more authority than a local test needs.

If dependency installation must run repeatedly, isolate the environment instead of widening host permissions. A dev container or disposable worker limits the effect of downloaded code and reduces credential exposure.

Split Git into reads, local history, and remote effects

These commands are usually safe to allow:

git status
git diff
git log
git show

Staging and committing should happen only when the user requested a commit. Avoid broad staging such as git add .: it can include unrelated edits or a file that should never enter the commit.

Do not auto-approve operations such as:

git push
git reset --hard
git clean -fd
git rebase

push changes a remote repository. reset --hard and clean can destroy local work. A rebase is legitimate in the right workflow, but its safety depends on whether the history is shared and how conflicts are handled.

Scope network access by destination

Network access has a different risk profile from a local edit. A bad file change can be inspected and reverted. Data sent to an external destination cannot be pulled back in the same way.

Codex network policy keeps command network access off in workspace-write by default and can restrict destinations when access is enabled. Granting network access and choosing allowed destinations are separate decisions.

A conservative policy looks like this:

allow a specific package registry or documentation host for a task that needs it;
allow an exact development API host, not an entire private network;
inspect the local process before allowing localhost access;
prompt for production APIs and cloud-management endpoints;
deny arbitrary public destinations by default.

A global * rule removes network prompts, but it also gives a prompt-injected command a much larger exfiltration surface.

Treat secret reads as side effects

An .env file, SSH key, cloud credential, or registry token is not safe merely because the agent does not edit it. Reading the value is enough to create risk.

Prefer restricted development credentials over production secrets:

remove production tokens from the agent’s shell environment;
use test accounts and least-privilege keys;
deny reads from secret paths;
make sure logs cannot print credential values;
expose cloud secrets only to the setup step that needs them.

Telling the model not to print a secret after it has read the file is not access control. Preventing the read is.

A conservative Claude Code permission file

Claude Code project settings can allow reviewed commands while asking about or denying operations with external effects.

{
  "permissions": {
    "allow": [
      "Bash(pnpm test)",
      "Bash(pnpm lint)",
      "Bash(pnpm build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git log)"
    ],
    "ask": ["Bash(pnpm add *)", "Bash(npm install *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)", "Read(./.env*)", "Read(~/.ssh/**)"]
  }
}

Start with exact commands. Add wildcards only after you know which arguments are repeatedly required. Claude Code wildcards can match spaces and multiple arguments, so a pattern that looks narrow may cover more than intended. Use /permissions to inspect the active rule and its source.

bypassPermissions and --dangerously-skip-permissions do more than reduce prompts. They skip permission checks, including protected-path writes. Claude Code’s permission-mode guide recommends using this only in an isolated container or VM.

A conservative Codex sandbox

For local Codex work, start with workspace writes, on-request approval, and command network access disabled:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Prefix rules can allow git status and git diff while continuing to prompt for git push. When several rules match, the more restrictive decision wins.

approval_policy = "never" can still be combined with a sandbox. In that mode Codex works without prompts but cannot complete actions outside the sandbox. danger-full-access and --dangerously-bypass-approvals-and-sandbox are different: they remove both approval and sandbox protection.

When full bypass is defensible

Some automation cannot pause for interactive approval: large migrations, long benchmarks, or repeated test-fix loops. Full bypass still belongs in an environment designed to be discarded.

Use it only when:

the container or VM can be destroyed after the task;
the host home directory and unrelated repositories are not mounted;
no production SSH keys, cloud credentials, or browser sessions are present;
network access is off or limited to required destinations;
the repository uses a separate branch or worktree with no push credential;
a person will review the diff and test results.

Without that isolation, a non-interactive deny-by-default mode is safer. It is cheaper for automation to stop than to modify a host or production system unexpectedly.

The useful default

Set AI coding permissions by blast radius and recovery cost, not by how familiar a command looks.

Allow file search, ordinary project reads, local diffs, and verified checks inside a narrow sandbox. Treat dependency installation as a separate network and code-execution decision. Keep secrets, remote Git, deployment, and production data behind explicit boundaries.

The best way to reduce permission fatigue is not to remove every guard. It is to create a small area where the agent can work freely without putting unrelated systems at risk.