Claude Code vs Codex: permissions and sandboxing compared

In the Claude Code vs Codex comparison for safety, the biggest difference is the default. Codex runs every shell command inside an operating-system sandbox from the start, with network access off, and asks before stepping outside it. Claude Code asks before most commands and file edits, and its sandbox is off until you turn it on. Both have command rules (Claude Code's allow, ask and deny; Codex's allow, prompt and forbidden), blocking PreToolUse hooks and settings an organization can lock.

This covers safety controls only, checked against both vendors' docs on November 2, 2026. Both tools change monthly, so check the linked pages before you rely on a setting name.

Claude Code vs Codex at a glance

How approvals work in each

Claude Code asks before most actions out of the box. Its permissions docs say Bash commands need approval except a built-in set of read-only commands such as ls and grep, and file edits need approval too. Permission modes change that: acceptEdits stops asking about edits in the working directory, plan reads without editing, and bypassPermissions skips prompts. Recent versions start interactive sessions in auto mode, where a classifier reviews actions, so check which mode you're in.

Codex splits the question in two: a sandbox mode decides what a command can touch, and an approval policy decides when Codex stops to ask. OpenAI's agent approvals and security page describes the sandbox modes:

• read-only: for chatting or planning without making changes.
• workspace-write: the default, where Codex can edit files and run commands in the workspace.
• danger-full-access: no sandbox at all.

The approval policy is on-request, where Codex works inside the sandbox and asks when it wants to go beyond it, or never, which never asks. A granular form lets you auto-reject some kinds of prompt while keeping others interactive. Codex no longer supports the older untrusted policy, and on-failure is deprecated, so guides that recommend either are out of date. On the command line, the same choices are --sandbox (-s) and --ask-for-approval (-a).

The practical difference: Claude Code mostly protects you by asking, and Codex mostly protects you by confining. Asking depends on a person reading each prompt; confining keeps working when the person stops reading.

Allow and deny rules in Claude Code and Codex

Claude Code has three rule lists, allow, ask and deny, in settings.json. Rules are checked in the order deny, then ask, then allow, and the first match decides. Deny rules still block in bypassPermissions, and an allow rule can't carve an exception out of a deny rule.

Codex keeps command rules in .rules files in a rules/ folder next to a config layer, for example ~/.codex/rules/default.rules. Each prefix_rule() matches the start of a command and gives one of three decisions:

• allow: run it outside the sandbox without asking.
• prompt: ask before each matching command.
• forbidden: block it without asking.

When several rules match, the most restrictive decision wins, so forbidden beats prompt and prompt beats allow. You can test a rule file with codex execpolicy check. OpenAI marks rules as experimental, so the format may change.

A Codex rule file looks like this:

prefix_rule(
    pattern = ["terraform", "destroy"],
    decision = "forbidden",
    justification = "Destroy plans are run by a person, not the agent.",
)

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
)

Note that an allow rule in Codex does more than skip the prompt: the command runs outside the sandbox. Keep allow for commands you would happily run unconfined.

Both kinds of rule match command text, so neither stops the same program reached another way. Claude Code's docs say a Bash rule "isn't a security boundary around the program," which is why both tools pair rules with a sandbox.

Sandboxing in Claude Code and Codex

Both sandboxes work at the operating-system level, so they catch what text matching misses.

Codex's sandbox is on from the start. Per its approvals and security page, it uses Seatbelt on macOS and bubblewrap with seccomp on Linux, and Windows has a sandbox of its own. "By default, the agent runs with network access turned off," and in workspace-write it stays off unless you turn it on:

# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Some paths stay read-only even inside a writable folder: .git, and .codex, .agents and .aws when they exist as folders. So a sandboxed command can't rewrite Codex's own config or your git hooks.

Claude Code's sandbox uses Seatbelt on macOS and bubblewrap on Linux and WSL2; native Windows has none. It is off by default; turn it on with /sandbox. Writes are limited to the working directory, and network traffic goes through a proxy whose allowed domains start empty. Two limits: reads are allowed across most of the machine, including ~/.ssh and ~/.aws/credentials, and it covers shell commands only, not Claude's file tools or MCP servers.

The YOLO flags: bypassPermissions vs --yolo

Claude Code's bypassPermissions (the --dangerously-skip-permissions flag) skips prompts, but deny rules and hooks still apply. Anthropic says to use it only in isolated containers or VMs, and a team can switch it off with permissions.disableBypassPermissionsMode in managed settings.

Codex's --dangerously-bypass-approvals-and-sandbox, aliased --yolo, removes approvals and the sandbox together. OpenAI's command reference says: "Only use inside an externally hardened environment." --sandbox danger-full-access with --ask-for-approval never gets you to roughly the same place.

Either way, the agent is left with whatever credentials the shell can reach. Several of the cases in our roundup of AI coding agent incidents involved a skip-everything or trust-all flag.

Hooks: a code-level gate in both

Claude Code's hooks reference lists over 30 events. A PreToolUse hook blocks by exiting with code 2 or printing JSON with "permissionDecision": "deny". Our guide to stopping Claude Code from running destructive commands has a tested script.

Codex's hooks use many of the same event names and the same two ways to deny: exit code 2 with the reason on stderr, or "permissionDecision": "deny". Its PreToolUse covers shell commands, apply_patch file edits, MCP tools and other local tools, but not hosted tools such as web search. Three differences matter:

• Codex skips a new or changed hook until you review and trust it, with /hooks in the CLI. Managed hooks are exempt.
• A Codex hook can't answer ask. Only deny blocks.
• Hooks live in ~/.codex/hooks.json, and a project can add its own in its .codex/ folder, which Codex skips for a project marked untrusted.

The catch is the same in both: a hook that crashes or times out doesn't block by default. OpenAI says to "treat tool hooks as a useful guardrail, not a complete enforcement boundary." Test your hooks.

Team policy and managed settings

Claude Code uses managed settings, from a system file, MDM or the Claude admin console, which override every other level. Keys worth knowing: permissions.disableBypassPermissionsMode, allowManagedPermissionRulesOnly, allowManagedHooksOnly and disableAutoMode.

Codex reads administrator requirements from MDM, its Agent Security admin controls and a requirements file on the device, in that order of precedence; the admin format is requirements.toml. Admins can limit the allowed approval policies, push managed hooks, and set allow_managed_hooks_only = true so other hooks are ignored. Separately, a developer can mark a folder trust_level = "untrusted" under [projects] in ~/.codex/config.toml. Commands there then need approval unless a rule allows them, and the project's own config is ignored: worth doing for any repo you didn't write.

Which is safer, Claude Code or Codex?

Neither, on its own. Configured carefully, both give you approvals, an OS sandbox, command rules, blocking hooks and an organization-level lock. The differences that matter in practice:

• Out of the box, Codex confines and Claude Code asks. If you use Claude Code, turn the sandbox on; if you use Codex, don't loosen workspace-write without a reason.
• Claude Code's deny rules survive bypassPermissions. Codex's --yolo removes the sandbox as well as the prompts.
• A Codex allow rule runs the command outside the sandbox. A Claude Code allow rule only skips the prompt.
• Codex hooks must be trusted before they run and can't ask. Claude Code hooks run once configured and can ask.
• Neither sandbox stops a command from using a credential it can reach. If the shell has a production DATABASE_URL, so does the agent. Give it a read-only database role when it needs real data.

None of these controls know what a command would break in your systems. That's the gap VineScale is built for: a free beta gate for Claude Code, with beta support for Codex, that works out what an action would touch in production and lets it through, asks or blocks it. Codex can't stop to ask from a hook, so where the gate would ask, it blocks the step and hands it to you. For Cursor, see Claude Code vs Cursor.

Frequently asked questions

Does Codex have deny rules like Claude Code?

Yes. A Codex prefix_rule() with decision = "forbidden" in a .rules file such as ~/.codex/rules/default.rules blocks matching commands without asking, and the most restrictive matching rule wins. Like Claude Code's deny rules, they match command text, so pair them with the sandbox.

Is Codex sandboxed by default?

Yes. Codex runs commands in an operating-system sandbox (Seatbelt on macOS, bubblewrap and seccomp on Linux, its own sandbox on Windows), and in the default workspace-write mode network access is off unless you enable it. Claude Code also has a sandbox, but it is off until you turn it on with /sandbox.

What is the Codex equivalent of --dangerously-skip-permissions?

--dangerously-bypass-approvals-and-sandbox, also called --yolo. It goes further than Claude Code's flag: it removes the sandbox as well as the approval prompts, and OpenAI says to use it only in an externally hardened environment, such as a throwaway container or VM.