Approval option 2 still prompts for every git add and git commit with different arguments

[andr1972]

Codex CLI version: 0.157.1
OS: Ubuntu

When Codex asks for approval to run git add or git commit, I choose option 2 to avoid approving the same kind of command repeatedly. However, the approval appears to apply to the entire command, including its arguments.

For example:

1. Codex requests approval for git add file1.cpp. I choose option 2.
2. Later, Codex runs git add file2.cpp and asks for approval again.
3. The same happens with git commit -m "..." when the commit message changes.

Option 2 therefore provides little benefit for these commands in a normal workflow, because the file paths and commit messages change each time.

Expected behavior: I would like a way to approve an appropriate command pattern, such as git add and git commit within the current repository, without approving every new set of arguments. If this is already supported, please let me know how to configure it.

[ooocooc]

There are two separate parts here: matching different arguments is supported; enforcing “only this repository” is not something a command-prefix rule provides.

First inspect the saved rule in your active CODEX_HOME (normally ~/.codex/rules/default.rules). The Rules documentation says the TUI saves approvals there and matching uses an exact argument-list prefix. If the saved pattern includes file1.cpp or the commit message, a different argument will not match; that is worth checking before attributing this to a persistence bug.

If you deliberately want these subcommands, with arbitrary following arguments, to run outside the sandbox without another prompt, the narrow subcommand prefixes are:

prefix_rule(pattern=["git", "add"], decision="allow")
prefix_rule(pattern=["git", "commit"], decision="allow")

Test a draft file before activating it:

codex execpolicy check --pretty --rules ./git-draft.rules -- git add file1.cpp
codex execpolicy check --pretty --rules ./git-draft.rules -- git add file2.cpp
codex execpolicy check --pretty --rules ./git-draft.rules -- git commit -m "different message"

In 0.157.1, this checker reads the named rules and outputs matches/decision; it does not execute those Git commands. You can repeat --rules to check other relevant files too. A matching prompt or forbidden rule still wins over allow.

For configuration locality, the docs describe <repo>/.codex/rules/*.rules loading when that project's .codex layer is trusted, followed by restarting Codex. But that is a loading scope, not a per-command working-directory fence: 0.157.1's prefix_rule fields have no cwd constraint. The commit prefix also covers flags such as --amend, not just a changed message. If a hard repository boundary is required, keep the approval prompts rather than treating these rules as that guarantee. Do not broaden this to allowing all git or a shell wrapper.

If the shorter patterns still prompt, the useful next evidence is the redacted saved rule and exact requested command/argv: for example, git -C ... add is not prefixed by git add.