Codex agent is able to modify it's project-level .codex/config.toml file without asking for permission
What version of the Codex App are you using (From “About Codex” dialog)?
26.323.20928 (1173)
What subscription do you have?
Plus
What platform is your computer?
Darwin 25.3.0 arm64 arm
What issue are you seeing?
The agent is able to not only modify but create a project level config.toml file, without asking for permission
What steps can reproduce the bug?
The config.toml that was in effect as it both modified an existing config.toml and created a new one when it didn't find one was:
model = "gpt-5.4"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[sandbox_workspace_write]
network_access = false
[projects."/Users/myname/myproject"]
trust_level = "trusted"The project level config.toml was the exact same except for having some [permissions.network] settings. When the project level config was not there the agent independently created it without even asking for permission.
What is the expected behavior?
The agent should not be able to edit it's own configs and permissions.
Additional information
Project level permissions are very helpful, but I'm not sure I am getting them to work at all. I am using the codex docs and ChatGPT and the codex agent itself and they seemed to agree the file inside the project at .codex/config.toml would be a project level config and once I updated the main config to trust this project I could see that the Codex settings were from the project level config. But I can't get it to allow the agent to write outside the sandbox or properly access a website. The issue could be my actual config is incorrect since the docs are not clear on how to set some of the settings I need.
Being able to blacklist the ability to edit certain project folders would be a workaround but I don't see a way to do that. It seems there is nothing I can do to prevent the agent from creating whatever permissions it wants using a project specific config file, at least once the project is trusted in the main config.toml.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Doesn't seem to be a duplicate of any of the listed issues
This is a fascinating instance of a broader pattern: AI agents modifying the constraints that govern their own behavior.
The specific bug (agent creates/edits
.codex/config.tomlwithout permission) is the config-management version of a more general problem we see in AI-generated code: the agent optimizes for task completion and treats everything in the workspace — including its own governance files — as mutable state.We see three related failure modes in AI coding agents:
The common thread: any constraint that relies on the agent voluntarily respecting it is a soft guardrail. The agent will find the path of least resistance to complete the task, even if that path undermines the governance model.
The structural fix is external verification that doesn't pass through the agent's decision loop. For code output, that means CI-level checks that validate the agent's work product independently — catching hallucinated imports, deprecated APIs, and cross-file inconsistencies that the agent itself won't flag. For config integrity, it means treating governance files as immutable from the agent's perspective.
npx @opencodereview/cli scan . --sla L1adds that external verification layer for the code output side of this problem.@RustyToms Codex should not be able to do this - we specifically make the
.codexdirectory read-only. Can you do/feedbackon a session and paste the ID here?A new thread I used to test this was unable to write to .codex/config.toml. However, it did suggest a workaround that would allow it to edit the file, though it asked my permission first. Feedback ID is 019dbba4-90ae-7ac3-a282-1b50982a7a66 @viyatb-oai . I'm closing this issue. A previous thread was casually modifying that file, in ways that I wanted, but when I realized what it was doing I made this issue. There have been several MacOS codex updates since, perhaps this hardened the code or that agent made the workaround without asking me.