Permission Systems: Who Decides What Runs

Permission spectrum overview

How coding agents decide whether a command runs, a file gets modified, or a tool is invoked is a fundamental architecture question. The 18 agents analyzed here span an enormous range — from simple mode enums to ML-powered classifiers to rule DSLs with pattern matching. Below is a comprehensive comparison across four dimensions: the model type, available modes, auto-approval strategy, and granularity of control.

Claude Code: The most sophisticated permission system

Claude Code implements the most nuanced permission model in this set: four approval modes, wildcard rules, an ML classifier, and persistent rule storage. It's the only agent that attempts to learn what's safe rather than relying purely on static rules or user judgment.

Four permission modes

Wildcard rules

Claude Code supports pattern-based permission rules that auto-approve or deny entire families of operations. The two main rule types:

• Bash(git *) — auto-approves all git commands. This is safe because git operations are inherently scoped to the repository and don't affect system state outside the workspace.
• FileEdit(/src/*) — auto-approves edits under /src/. Useful when you trust the agent to modify source files but want prompts for config files or dotfiles.

PermissionRule type and architecture

The core permission abstraction is the PermissionRule type, which combines:

• Tool name pattern — which tool the rule applies to
• Path/command pattern — glob or prefix matching on the operation target
• Behavior — allow, deny, or ask

Rules are evaluated against a ToolPermissionContext, an in-memory cache of permission decisions that avoids re-prompting for the same operation within a session. Rules persist across sessions via settings.json, so your Bash(git *) rule survives restarts.

ML classifier integration

In auto mode, the ML classifier runs in parallel with the permission prompt. If the classifier deems an operation safe, it can upgrade the decision to auto-approve before the user even responds. This is the key UX improvement: the user sees fewer prompts because safe operations are pre-approved by the model, not because they were silenced.

Permission UI components

The BashPermissionRequest component displays to the user:

• The full command to be executed
• Its classification (safe, risky, destructive)
• Sandbox status (running in sandbox or on host)
• A destructive warning via getDestructiveCommandWarning() for high-risk patterns like rm -rf, dd, or mkfs

Programmatic rule changes flow through PermissionUpdate and PermissionUpdateDestination, allowing other parts of the system to modify permission rules at runtime — for instance, the plan mode temporarily upgrades all planned operations to allow.

Codex: The execpolicy rule engine

Codex takes a different philosophy: rather than modes and classifiers, it provides a programmable rule DSL through its execpolicy crate. This gives fine-grained, code-as-policy control over what commands run.

Fast-path allowlist

Before hitting the policy engine, Codex checks is_known_safe_command() — a hardcoded allowlist of read-only operations that skip all policy evaluation:

ls, cat, find, git status, head, tail, wc, grep, echo, pwd, date, whoami

This is a critical performance optimization: most agent turns involve many read-only commands, and skipping the full policy engine for them reduces latency and eliminates unnecessary prompts.

Permission profiles

Runtime approval flow

The request_permissions tool is Codex's runtime approval mechanism: the agent explicitly requests permission from the user for an operation, the user approves or denies, and the decision is cached for the session. This is different from Claude Code's parallel classifier — Codex always waits for the user unless the operation matches an allowlist rule.

execpolicy rule DSL

The execpolicy crate supports:

• Prefix patterns — "git *" matches any git subcommand
• Network rules — allow/deny commands that make network requests
• Command whitelists/blacklists — explicit allow or deny lists
• MCP tool overrides — per-tool permission overrides in config.toml

Thread-level sandbox isolation

Each thread can have its own sandbox_mode and approval policy. This means you can run a high-trust thread with full-auto inside a sandbox, while a lower-trust thread runs with suggest on the host. The separation of approval policy from sandbox enforcement is Codex's key architectural insight: they are orthogonal concerns and should be configured independently.

OpenCode: Pattern-matching permission bus

OpenCode implements a permission system built around a permission bus — an event-driven architecture where permission requests and decisions flow through a central dispatch. This is fundamentally different from the mode-based approaches: every operation publishes a permission request, rules are evaluated in sequence, and a reply is generated.

Rule/Request/Reply architecture

Three core types define the system:

• Rule — a pattern with an associated behavior (allow, deny, ask)
• Request — a permission query from an operation (tool, path, command)
• Reply — the decision: once (approve this time), always (approve and remember), or reject (deny)

Last-match-wins evaluation

Rules are evaluated sequentially with last-match-wins semantics. This means you can set a broad allow rule and then add specific deny rules that override it. The order matters: later rules take precedence. This is a deliberate design choice — it allows users to start permissive and then carve out exceptions, rather than starting restrictive and carving out allowances.

Permission bus and ACP integration

The permission bus publishes events to all subscribers. This enables:

• Distributed permission handling — multiple components can observe and react to permission decisions
• ACP client integration — the Agent Communication Protocol client can surface permission prompts to external UIs
• Audit logging — every permission decision is an event that can be logged

Configuration and rule composition

The fromConfig() function builds rule sets from configuration, and merge() combines multiple rule sets. The disabled() function creates a fully permissive rule set — useful for testing or trusted environments. Rules can be backed by a database for persistence across sessions, and per-agent overrides allow different agents to have different permission rules within the same system.

Neovate: Banned-list approach

Neovate takes the most opinionated stance: define what's not allowed, and everything else is fine. This inverted approach is simpler to reason about but requires maintaining a comprehensive ban list.

Three approval modes

The 22-item banned command list

In default mode, the following commands are always blocked:

alias, aria2c, axel, bash, chrome, curl, curlie, eval,
firefox, fish, http-prompt, httpie, links, lynx, nc,
rm, safari, sh, source, telnet, w3m, wget, xh, zsh

This list is carefully curated: it bans shells (bash, sh, fish, zsh) to prevent escape to an unrestricted shell, network tools (curl, wget, lynx, etc.) to prevent data exfiltration, and destructive commands (rm, eval, source).

High-risk pattern detection

Beyond static bans, Neovate detects dangerous patterns even in allowed commands:

rm -rf       # recursive force delete
sudo         # privilege escalation
dd if=       # raw disk access
mkfs         # filesystem creation
curl | sh    # remote code execution

Each pipeline segment is checked individually, so ls | rm -rf / is caught on the rm -rf segment even though ls is safe.

Quote-aware pipeline parser

The critical security feature is a character-level state machine that tracks quoting context before any security check:

• inSingleQuote — inside single quotes
• inDoubleQuote — inside double quotes
• escaping — after a backslash

splitPipelineSegments() uses this state machine so that 'echo "a|b"' is correctly identified as ONE segment — the pipe inside the quotes is not a pipeline separator. Similarly, hasCommandSubstitution() detects $() and backticks within quoted contexts, preventing command injection via nested substitution.

Per-tool category permissions

Beyond bash, Neovate categorizes all tools into: read, write, command, network, and ask. Each category can have independent permission rules, allowing fine-grained control like "auto-approve reads but prompt for writes."

Other notable permission approaches

The YOLO mode problem

Every agent with a YOLO/bypass/auto-approve mode faces the same fundamental tension: developers want zero-friction for trusted work, but any auto-approve mode is a security hole if the model is compromised.

Different agents approach this tension differently:

Claude Code's ML classifier is the most nuanced attempt at balancing safety versus speed: instead of a binary "prompt everything" or "approve everything," it uses a model to make per-operation decisions. Codex's approach of separating approval policy from sandbox enforcement is also noteworthy — you can be in full-auto mode but still sandboxed, meaning the agent runs freely but within an isolated environment.

Permission architecture patterns

Across all 18 agents, five distinct architectural patterns emerge for handling permissions:

What you should build

If you're designing a permission system for a new coding agent, here are the key recommendations distilled from analyzing all 18 agents:

Minimum viable permission system

1. At least 3 modes: prompt-all (safest), auto-approve-sandboxed (frictionless in isolation), and auto-approve-all (YOLO, for trusted environments). This covers the full spectrum of trust levels.
2. Add wildcard rules early: Bash(git *) and Read(*) are safe defaults that eliminate prompt fatigue. Git operations are scoped to the repository, and reads can't modify state. These two rules alone eliminate a majority of permission prompts.
3. Consider ML classification for auto mode: Even a simple classifier that detects read-only commands is better than all-or-nothing. You don't need Claude Code's full ML infrastructure — a pattern matcher that recognizes cat, ls, grep, and find as safe is a meaningful improvement.
4. Never strip permissions from sub-agents without sandboxing them: If you remove tools from a child agent, also run it in a sandbox. Tool stripping alone is insufficient — the child might still access the filesystem or network through remaining tools.
5. Make permissions persistent across sessions: Store rules in settings.json or a similar persistent format, not just in-memory. Users should not have to re-approve git * every time they restart the agent.
6. Show users what's happening: Permission prompts should display the command, its risk level, and sandbox status. Transparency builds trust — users who understand why they're being prompted are more likely to set appropriate rules.

Bottom line

Permission systems are the most visible security feature of any coding agent — they're what the user interacts with on every turn. A well-designed permission system balances safety and developer experience; a poorly designed one is either a security hole or a productivity black hole.

Claude Code's four-mode system with ML classifier represents the most sophisticated attempt at this balance. Codex's separation of approval policy from sandbox enforcement is the most architecturally sound. Neovate's quote-aware pipeline parser is the most defensive bash implementation. And OpenCode's permission bus is the most extensible — it can scale to distributed systems and multi-agent architectures.

The pattern that emerges from all of this: the best permission system is layered. Start with coarse modes, add wildcard rules for common operations, classify operations by risk, sandbox when possible, and persist decisions so users don't face prompt fatigue. No single pattern is sufficient on its own — production readiness requires all of them working together.