Codex CLI always uses sandbox

Resolved 💬 4 comments Opened Apr 16, 2026 by bogosmer Closed Apr 23, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.121

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

macOS Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Terminal.app

What issue are you seeing?

codex exec ignores explicit sandbox override flags.

I run:
env -i HOME="$HOME" USER="$USER" SHELL=/bin/zsh PATH="/opt/homebrew/bin:/usr/bin:/bin" \
/opt/homebrew/bin/codex -p unsandboxed --sandbox danger-full-access -m gpt-5.4 exec "echo ok"

The command returns ok, but session logs show the resolved sandbox policy is still read-only.

What steps can reproduce the bug?

  1. Run the command above in a normal terminal.
  2. Inspect the session log generated for that run.
  3. In my case:

~/.codex/sessions/2026/04/16/rollout-2026-04-16T11-01-34-019d9586-36be-7d22-90cd-94cb0289e8c3.jsonl

  1. turn_context shows:

"sandbox_policy":{"type":"read-only"}

What is the expected behavior?

With -p unsandboxed --sandbox danger-full-access, resolved sandbox policy should be danger-full-access (or at minimum not read-only).

Additional information

This blocks workflows that require git writes/xcodebuild/network during automated loops, because the process behaves as sandboxed even when launched with unsandboxed/danger-full-access settings.

Project is marked as trusted and I have this in config.toml for unsandboxed profile: ```
[profiles.unsandboxed]
sandbox_mode = "danger-full-access"
approval_policy = "never"

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15696

Powered by Codex Action

bogosmer · 4 months ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. * codex exec with danger-full-access still hits EPERM/loopback restrictions while interactive Codex in same shell succeeds #15696 _Powered by Codex Action_

Not a duplicate although the underlying causes might be the same.

etraut-openai contributor · 4 months ago

Thanks for the bug report. This will be addressed in the next release.

viyatb-oai contributor · 4 months ago

fixed in 0.123.0