# Claude Code vs Codex: permissions and sandboxing compared

> How Claude Code and OpenAI Codex handle approvals, allow and deny rules, sandboxing, hooks and team policy, side by side and checked against both vendors' docs.

Web page: https://vinescale.com/blog/claude-code-vs-codex-safety/
By Gary Mathis, founder of VineScale (https://vinescale.com/about/). Published 2026-11-02.

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

| Control | Claude Code | Codex |
|---|---|---|
| Default posture | Asks before most commands and edits | Sandboxed by default, asks to leave the sandbox |
| Approval settings | Modes: `default`, `acceptEdits`, `plan`, `auto`, `dontAsk`, `bypassPermissions` | `approval_policy`: `on-request`, `never` or `granular` |
| Shell sandbox | Seatbelt on macOS, bubblewrap on Linux and WSL2; off by default | Seatbelt on macOS, bubblewrap and seccomp on Linux, its own sandbox on Windows; on by default |
| Network in the sandbox | Proxy with an allowed-domains list that starts empty | Off by default in `workspace-write` |
| Command rules | `allow`, `ask`, `deny` in `settings.json`; deny wins | `allow`, `prompt`, `forbidden` in `.rules` files; most restrictive wins |
| Skip everything | `bypassPermissions` (deny rules still apply) | `--yolo`, which removes approvals and the sandbox |
| Pre-action hooks | `PreToolUse` and more; block with exit code 2 or a `deny` decision | `PreToolUse` and more; block with exit code 2 or a `deny` decision; new hooks must be trusted first |
| Organization lock | Managed settings files, MDM or the admin console | `requirements.toml`, MDM and admin controls |

## How approvals work in each

**Claude Code** asks before most actions out of the box. Its [permissions docs](https://code.claude.com/docs/en/permissions) 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](https://code.claude.com/docs/en/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](https://learn.chatgpt.com/docs/agent-approvals-security) 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](https://learn.chatgpt.com/docs/config-file/config-reference) 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](https://learn.chatgpt.com/codex/agent-configuration/rules) 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:

```python
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](https://learn.chatgpt.com/docs/agent-approvals-security), 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:

```toml
# ~/.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](https://code.claude.com/docs/en/sandboxing) 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](https://learn.chatgpt.com/docs/developer-commands) 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](https://vinescale.com/blog/ai-coding-agent-incidents/) involved a skip-everything or trust-all flag.

## Hooks: a code-level gate in both

Claude Code's [hooks reference](https://code.claude.com/docs/en/hooks) 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](https://vinescale.com/blog/stop-claude-code-destructive-commands/) has a tested script.

Codex's [hooks](https://learn.chatgpt.com/docs/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](https://code.claude.com/docs/en/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](https://vinescale.com/blog/ai-agent-read-only-database-access/) when it needs real data.

None of these controls know what a command would break in your systems. That's the gap [VineScale](https://vinescale.com/beta/) 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](https://vinescale.com/blog/claude-code-vs-cursor-safety/).

## 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.

VineScale is a safety gate for AI coding agents. The gate for Claude Code is in free beta, with beta support for Codex, Cursor, Antigravity and Grok Build: https://vinescale.com/beta/