Hi Codex CLI team,
Thanks for running such a useful tool. One pain point with the
approval system is that there’s no way to configure per-command
behavior. I often have to approve dozens of repetitive, low-risk
commands (e.g., git status, ls, cat file) and it becomes tedious to
babysit the session. On the flip side, if I select “allow everything,”
I lose any ability to keep an extra guardrail around sensitive
commands like rm -rf or git reset --hard.
A Configurable Allow/Deny List Could Help:
- Let me whitelist specific commands or patterns so they execute
automatically even when the approval policy is otherwise strict.
- Let me blacklist commands or patterns so that, even in “allow
everything” mode, they still prompt for approval (or are blocked
entirely).
A simple configuration file (e.g., JSON/YAML) or CLI flags would
let users tailor the flow to their risk tolerance. Optional logging
when a rule is hit would make auditing easy. This keeps the default
behavior intact while improving UX for power users who need both speed
and safeguards.
Appreciate your consideration!
Hi Codex CLI team,
Thanks for running such a useful tool. One pain point with the
approval system is that there’s no way to configure per-command
behavior. I often have to approve dozens of repetitive, low-risk
commands (e.g., git status, ls, cat file) and it becomes tedious to
babysit the session. On the flip side, if I select “allow everything,”
I lose any ability to keep an extra guardrail around sensitive
commands like rm -rf or git reset --hard.
A Configurable Allow/Deny List Could Help:
automatically even when the approval policy is otherwise strict.
everything” mode, they still prompt for approval (or are blocked
entirely).
A simple configuration file (e.g., JSON/YAML) or CLI flags would
let users tailor the flow to their risk tolerance. Optional logging
when a rule is hit would make auditing easy. This keeps the default
behavior intact while improving UX for power users who need both speed
and safeguards.
Appreciate your consideration!