Allow specifying specific commands that don't need permission to run
Resolved 💬 24 comments Opened Sep 3, 2025 by rben01 Closed Jan 14, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What feature would you like to see?
In .claude/settings, users can set explicitly allows commands for Claude to run so that it doesn't need permission. e.g.
{
"permissions": {
"allow": [
"Bash(mkdir:*)",
"Bash(rg:*)",
"Bash(npm run build:*)",
"Bash(grep:*)",
"Bash(npm run format:*)"
// ...
]
}
}
It's great that Claude Code lets me tell it which tools it doesn't need to ask for permission to use. It would be great if Codex CLI has a similar whitelist of user-specific permissions (not necessarily with the above syntax) so that it would stop repeatedly pestering me to ask if it can run my tests.
Are you interested in implementing this feature?
_No response_
Additional information
_No response_
24 Comments
Is this on the roadmap still? Would be very useful
I also need this. Codex keeps asking me to approve each curl call.
Curious about this too.
Is this still not available in Codex? 😩
This would help me a lot because I can't run
xcodebuildinside the sandboxWe all need this one.
This enhancement is probably my #1 request - there are certain commands that I always want to allow, such as running the scripts to build and test my project (similar to the
xcodebuildexample from @SwiftedMind a few weeks ago).The wildcards are an important aspect to this - tools such as 'axe' (https://github.com/cameroncooke/AXe) would commonly be run over and over again, and provide different parameters each time. Needing to approve each individual combination of parameter is a non-starter, but running on yolo mode is _not_ what I want to do.
+1 to have this feature. Its so tedious to use codex otherwise
+1
+1
Why the fuck is there an option to allow a command and then not be asked for permission again, but it simply does not work??
Yeah also got surprised by that, but I think it whitelists even the args - so it will only work if the cmd has exactly the same args.
Came here looking for a way to autoallow gofmt but I am ok reviewing other edits and such. Please consider this feature :)
I got really tired of having to always approve this, so I wrote a custom script that allows you to whitelist certain commands. I've been using it for about a month and it's a game changer with Codex CLI. Keep in mind this is my personal script, so you might have to tweak it to get it working right for you, but here's how to set it up:
Prerequisites:
~/.zshrc):this gives us a string to watch for when codex starts and ends.
codex_coprocess.dart(to be used in next step).You can obviously edit the
approvedCommandslist as needed.<img width="1338" height="684" alt="Image" src="https://github.com/user-attachments/assets/ea4fe1d8-3a21-4547-b589-70f4cf0a519a" />
<img width="1338" height="684" alt="Image" src="https://github.com/user-attachments/assets/7965cab2-6a41-47bc-9a8f-dca8b46fdf83" />
And the full text for the second screenshot, second part is this (you'll need to update this for your system).
Obviously you will need to update the paths to be relative to your machine.
It should now be working and when an
approvedCommandis requested by codex, it should automatically be approved and continue. This has been a game changer for me.+1
+1
Also had this concern, was able to fix it by adding
to
~/.codex/rules/default.rules.Now Codex can run eslint with any arguments without asking me permission.
this works quite well. documentation:
https://developers.openai.com/codex/local-config/#rules-preview
prefix_ruleworks for commands with separate argument tokens (e.g.["eslint"]allowseslint <any args>), but fails when Codex wraps commands as["/bin/zsh", "-lc", "<entire command>"].The third token contains the full heredoc, so there's no way to match just the prefix.
Example that works:
Example that fails:
Request: Please add substring/glob support for within-token matching, e.g.:
This feature is supported through the "rules" mechanism, which is documented here.
@etraut-openai
This does not seem to be possible with the rules mechanism at the moment.
@fschwahn, we're looking at the next round of extensions to the existing Rules feature, and we're interested in ideas and feedback. I'd appreciate it if you'd create a new enhancement request and clarify what changes or additions you'd like to see. This thread is quite long (and old) and covers a lot of things that are already supported.
@Culpable you want to open your comment as a new issue? I think it's very clearly written.
this should be reopened -- @etraut-openai the current method doesn't handle wildcards at all as far as i can see. it's super frustrating.
@aa403, if you'd like to suggest a new capability, please open a new feature request.