Inconsistent Session Authorization Due to Literal String Matching

What version of Codex is running?

codex-cli 0.92.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.2-codex

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

I would like to offer some feedback regarding the "Proceed always" option in the CLI, as I have noticed a small friction point that impacts my user experience during development sessions.

Currently, the "Proceed always" functionality seems to operate on a literal string match basis. When I select this option, it appears to whitelist the exact, full command string provided at that moment. However, in a real-world workflow, many terminal commands are unique by nature. For instance, if I am committing code, the command includes a specific commit message. If I authorize a command like git commit -m "Initial update," I am prompted for permission again the next time I run git commit -m "Fixing bug" because the message has changed. The same occurs when creating various directories ("mkdir ABC/" VS. "mkdir XYZ/") or installing different packages where paths and names vary.

In practice, this makes the "always allow" option feel very similar to "allow once," leading to frequent interruptions that break the flow of work. To make this feature more effective and intuitive, I suggest moving toward a pattern-based or template-based authorization. It would be incredibly helpful if the system could recognize the base command, such as git commit or mkdir, and allow the user to authorize that specific action for the duration of the session, regardless of the unique arguments or messages that follow.

I believe this change would better align the feature with its intended purpose and significantly smooth out the interactive experience for users. Thank you.

What steps can reproduce the bug?

Uploaded thread: 019c16de-710f-7562-9b86-4e184195fc1f

Steps to Reproduce

1. Initialize Codex: I initialize Codex within a standard GitHub repository to begin an interactive development session.
2. Modify the Repository: I make an initial change to the project, such as creating a new README.md file or adding a basic script.
3. Request Commit/Push: I ask Codex to commit these changes and push them to the remote repository.
4. Authorize Always: When the terminal prompt appears asking for permission to run the git command, I select Option 2 (Proceed always for this session).
5. Perform a Second Modification: I make another distinct change in the same repository, such as editing a line of code or adding a second file.
6. Request Second Commit/Push: I ask Codex to commit this new change with a relevant, updated commit message.
7. Observe Redundant Prompt: I check to see if Codex prompts me for permission again. Despite having selected "Always allow" previously, the system asks for confirmation because the commit message string is not an exact match to the first one.

What is the expected behavior?

When I select the option to always proceed with a command for the current session, I expect the system to recognize the intent of the command rather than just the literal text. My expectation is that the CLI would identify the core utility I am using, such as git commit or mkdir and grant it session-wide permission.

Instead of requiring an exact, character-for-character match, the tool should understand that if I have authorized a specific action once, I trust it to handle varying parameters like different commit messages or file paths for the remainder of that session. Essentially, choosing "Always allow" should establish a temporary trust bond for that type of action, allowing me to stay in the flow of my work without being interrupted by a confirmation prompt every time a minor detail in the command changes.

Additional information

_No response_