Repo-local .codex/config.toml sandbox_mode is ignored in Codex App

Open 💬 2 comments Opened Jun 25, 2026 by dummydata

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.10790.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex App appears to ignore repo-local .codex/config.toml sandbox settings after a recent update.

In my repository, .codex/config.toml contains:

approval_policy = "on-request"
sandbox_mode = "danger-full-access"

However, new Codex sessions were initialized with an effective filesystem sandbox of workspace-write instead of danger-full-access.

This caused Codex-run commands to fail or warn when accessing normal user-level files outside the workspace. For example, running this inside Codex:

git status --short

produced:

warning: unable to access 'C:\Users\username/.config/git/ignore': Permission denied

The same command run directly in my PowerShell did not produce the warning.
After I changed my global Codex config to use danger-full-access, the effective session sandbox changed to unrestricted and the same Codex-run git status --short command returned cleanly with no warning.

This suggests that global config is being honored, but repo-local .codex/config.toml is not taking precedence or is not being applied by the Codex App.

What steps can reproduce the bug?

On Windows, create or open a repo with a repo-local .codex/config.toml.
Set:

approval_policy = "on-request"
sandbox_mode = "danger-full-access"

Start a new Codex App session in that repo.
Ask Codex what sandbox is effective, or run a command that needs to read a normal user-level file outside the workspace.
Example command:

git status --short

Observe that the session is effectively workspace-write, and Git cannot read the default/global ignore path:

warning: unable to access 'C:\Users\username/.config/git/ignore': Permission denied

Run the same command directly in the user’s PowerShell. It succeeds without the warning.
Change the global Codex config to sandbox_mode = "danger-full-access".
Start/continue a Codex session and rerun:

git status --short

The command now succeeds without the warning, indicating the global config affected the effective sandbox while the repo-local config did not.

What is the expected behavior?

Repo-local .codex/config.toml should be applied for Codex App sessions opened in that repository.

If both global and repo-local config specify sandbox_mode, the documented/intended precedence should be respected. In particular, a repo-local setting of:

sandbox_mode = "danger-full-access"

should result in an effective unrestricted filesystem permission profile for that repo session, unless the App intentionally overrides it and clearly reports that override to the user.

Additional information

This reproduced in two separate Codex App sessions after the last update Model/Reasoning for each session was:
gpt-5.5 medium
gpt-5.5 high

Installed package observed from PowerShell:

OpenAI.Codex 26.616.10790.0
OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0

The workaround is to set sandbox_mode = "danger-full-access" in the global Codex config. A command-local workaround for the Git warning is:

git -c core.excludesFile= status --short

But that only avoids this specific Git warning; it does not fix the underlying config precedence issue.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

#29915
#29503

Powered by Codex Action

taka-hue · 17 days ago

I ran into the same issue on Windows with the Codex Desktop App
(not just the VS Code extension).

What version of the Codex App are you using (From "About Codex" dialog)?
26.803.41515

What platform is your computer?
Windows

What issue are you seeing?
I set up a project-local .codex/config.toml with:

sandbox_mode = "read-only"
approval_policy = "on-request"

In the Desktop App's Settings > Configuration screen, opening
"config.toml" for this project correctly showed the file content
(sandbox_mode = "read-only", approval_policy = "on-request").
The Settings UI itself also displayed "Sandbox setting: Read-only"
and "Approval policy: On request" for this project profile.

However, when I asked the agent to write a new file
(e.g. "summarize the folder contents and save it as report.md"),
it wrote the file directly with no confirmation prompt at all,
as if sandbox_mode were "workspace-write" or higher.

I confirmed the same config.toml worked correctly (blocked the
write and asked for confirmation) when running codex from a
terminal in the same folder. So the discrepancy is specifically
between the Desktop App and the CLI, even though the Desktop App's
own Settings screen shows the correct project config.

This seems related to #30001, but I wanted to add that even the
Settings UI display (which reads the correct config.toml) does not
match the actual enforced behavior in a session — so this isn't
just a precedence issue, but also a UI-vs-runtime consistency issue.

Steps to reproduce:

Create a project folder with .codex/config.toml containing

sandbox_mode = "read-only" and approval_policy = "on-request".

Open the folder in Codex Desktop App (Windows).
Confirm in Settings > Configuration that the correct config.toml

is being read and shows "Read-only" / "On request".

Ask the agent to create/write a new file in that folder.
Observe the file is written with no confirmation prompt.

Expected: the write should be blocked / require confirmation,
matching both the config.toml content and the Settings UI display.

Observed: the write succeeds silently, contradicting the Settings
UI.