Codex Fine-Grained Permissions

Open 💬 7 comments Opened Mar 11, 2026 by thebriancurtis
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App

What feature would you like to see?

Right now, we have the choice of "Default permissions" and "Full access". The default is so restrictive that you have to approve every command, while the "Full access" is way to permissive. I'd like to see a more fine-grain approach where commands can be allowed by class and severity level, access can be limited to certain folders and/or git repos, Git commands can be individually blocked for explicit approval, etc.

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #13062
  • #13914
  • #14393

Powered by Codex Action

thebriancurtis · 4 months ago

Reviewed potential duplicates and did not find them to be duplicative.

Azreal42 · 4 months ago

Why can't you use the config.toml for such things ? (+ rules, +writable_roots)

thebriancurtis · 4 months ago

Maybe I can, maybe I can’t. I honestly have no idea. But, I’m using a GUI, so I want to be able to do it in the GUI that does offer a setting already.On Mar 19, 2026, at 8:56 AM, Az42 @.***> wrote:Azreal42 left a comment (openai/codex#14399)
Why can't you use the config.toml for such things ? (+ rules, +writable_roots)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Azreal42 · 4 months ago

I get your point but the toml is already accessible through the UI :
<img width="1552" height="813" alt="Image" src="https://github.com/user-attachments/assets/bc917cfc-b9df-4c8b-b87d-eb08c3df2ea2" />
And if you want to be able to edit the config.toml, the issue shouldn't be "Codex Fine-Grained Permissions", it should be "Add a new screen so that we can edit the config flags in UI".
And having that kind of UI would be a bad idea, since the toml can have parts quite dynamic, just read the doc and open a text editor !

thebriancurtis · 4 months ago

Hence, the request for fine-grained permissions. We want different things.On Mar 20, 2026, at 3:58 AM, Az42 @.***> wrote:Azreal42 left a comment (openai/codex#14399)
I get your point but the toml is already accessible through the UI :
image.png (view on web)
And if you want to be able to edit the config.toml, the issue shouldn't be "Codex Fine-Grained Permissions", it should be "Add a new screen so that we can edit the config flags in UI".
My two cents, that would be a bad idea, the toml can have parts quite dynamic, just read the doc and open a text editor !

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Fengzdadi · 2 months ago

I’m interested in working on this area and potentially opening a series of PRs.

I built a small proof-of-concept tool called CodexGo around the existing PermissionRequest hook. The main idea is a layered permission policy system for Codex actions:

  • global/user policy
  • project policy
  • possibly session-scoped overrides
  • named permission profiles, such as manual/strict/go
  • explain/audit/suggest tooling so users can understand why a command was allowed, prompted, or denied

The motivation is similar to this issue: the current gap between “default permissions” and “full access” is too large. Users often want a middle ground: allow common low-risk development commands, prompt for sensitive commands like git push, and deny obviously dangerous commands.

I think this could be implemented natively in smaller steps rather than as one large change:

  1. Add or extend a codex permissions explain / execpolicy check command that shows the resolved decision and which user/project/session rule matched.
  2. Add profile-specific permission rules so codex -p <profile> can select a permission profile, not only general config.
  3. Add session-scoped permission overrides for one-off runs.
  4. Later, add audit/suggest tooling based on repeated approvals.

I’m happy to start with a small PR around explainability or profile-specific rules if maintainers think this direction fits the existing rules/config model.