Docs and behavior disagree: default_permissions overrides sandbox_mode

Open 💬 0 comments Opened Aug 1, 2026 by okdt

Summary

The documentation states that sandbox_mode takes precedence when both it and
default_permissions are present. On 0.146.0 the opposite happens:
default_permissions wins in both directions I tested.

I am not sure whether the code or the documentation reflects the intent, so I am
reporting the discrepancy rather than filing this as a straight bug.

Environment

  • codex-cli 0.146.0 (Homebrew)
  • macOS 15 (arm64)

What the documentation says

From https://developers.openai.com/codex/permissions

If sandbox_mode appears in any loaded config file, you pass --sandbox, or the selected config profile sets sandbox_mode, Codex uses those older sandbox settings instead of default_permissions.

What I observed

Both cases use a throwaway CODEX_HOME so nothing touches a real configuration.

Case A — sandbox_mode is the permissive one

# $CODEX_HOME/config.toml
sandbox_mode = "workspace-write"
default_permissions = ":read-only"
$ cd /tmp/probe-a
$ CODEX_HOME=/tmp/home-a codex sandbox -- /usr/bin/touch probe.txt
touch: probe.txt: Operation not permitted

The write is refused, i.e. :read-only applied.

Case B — sandbox_mode is the restrictive one

# $CODEX_HOME/config.toml
sandbox_mode = "read-only"
default_permissions = ":workspace"
$ cd /tmp/probe-b
$ CODEX_HOME=/tmp/home-b codex sandbox -- /usr/bin/touch probe.txt
$ ls probe.txt
probe.txt

The write succeeds, i.e. :workspace applied.

In both cases default_permissions decided the outcome, which is the reverse of
the documented precedence.

Why this matters

Case B is the concerning direction. Someone who sets sandbox_mode = "read-only"
deliberately — and who has read the documentation quoted above — gets
workspace-write instead, with no warning, if a default_permissions line is
still present anywhere in the loaded configuration. That is an easy state to end
up in after trying the beta permission profiles and reverting only part way.

Question

Which behavior is intended?

  • If the code is correct, the permissions page needs the precedence reversed, and

it would help to warn that a leftover default_permissions silently overrides
sandbox_mode.

  • If the documentation is correct, the resolution order looks like a bug.

Either way, a startup warning when both are present would make the situation much
harder to miss.

View original on GitHub ↗