›_ Codex Issues
Codex Issues / #38328

"Yes, and don't ask again" remembers exact command instead of command/executable

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

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

plus

Which model were you using?

gpt-5.6-terra

What platform is your computer?

Linux 6.8.0-136-generic x86_64 x86_64

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

Tabby

Codex doctor report

What issue are you seeing?

When Codex CLI asks for approval to run a shell command, selecting “Yes, and don’t ask again” appears to whitelist the entire exact command string rather than the underlying command/tool being used.

This makes the option much less useful for commands containing dynamic arguments, file names, paths, search terms, IDs, etc.

For example, if Codex asks to run:

grep "foo" /some/path/file1.log

and I select “Yes, and don’t ask again”, I would expect future uses of grep (or at least similar grep commands) to no longer require approval.

Instead, Codex seems to remember only that exact command. If it later runs:

grep "bar" /some/path/file2.log

I am prompted for approval again.

What steps can reproduce the bug?

Have Codex execute a command with arguments, such as: grep "foo" file1.txt

When prompted for permission, select “Yes, and don’t ask again.”

Have Codex execute another command using the same executable but different arguments: grep "bar" file2.txt

Codex asks for permission again.

What is the expected behavior?

Selecting “Yes, and don’t ask again” should create a reusable permission rule based on the underlying executable or a sensible command prefix.

For example, approving: grep "foo" file1.txt

could allow future commands matching:

grep *

rather than only allowing the exact original command string.

Alternatively, Codex could make the scope explicit when approving a command, such as:

Allow this exact command
Allow commands starting with grep
Allow grep for this session
Allow grep permanently

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 15 days ago

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

  • #37603

Powered by Codex Action

jdcodes1 · 10 days ago

Explains cleanly from main @ 1f41cc5d92: there are two "don't ask again" flavors, and you're only being offered the weak one.

  • "Yes, and don't ask again for this command in this session" — exact command string, session-scoped. That's what you selected.
  • "Yes, and don't ask again for commands that start with <prefix>" — a real prefix rule (e.g. ["grep"]), persistable. This option only appears when a prefix amendment is derivable: either the model's escalation request proposed a prefix_rule, or a heuristics rule matched — and it must survive a banned-prefix list and a would-this-prefix-actually-cover-the-command check (core/src/exec_policy.rs#L894-L975). For an organic approval on a plain grep … with no model-suggested prefix, none of those fire, so the prefix option never renders (tui/.../approval_overlay.rs#L855-L870) and the exact-command option is all you get.

Improvement shape: when no prefix is proposed, derive a client-side default (the executable, or executable + subcommand) so the prefix option is always present — with the caveat from #39085 that prefixes for workspace-interpreting commands (npm run, cargo test, …) deserve a warning, since those aren't real boundaries. Read-only tools like grep are exactly where a derived prefix is both safe and what users expect.

naipi11 · 9 days ago

The dialog's "Yes, and don't ask again" is often the exact-command session rule. A later grep bar file2 is a different string, so it prompts again.

Method:

  1. When the prompt offers a prefix rule ("commands that start with ..."), choose that instead of the exact-command option.
  2. If you only got the exact-command option, add a reusable prefix yourself in ~/.codex/rules/default.rules, for example prefix_rule(pattern=["grep"], decision="allow").
  3. On native Windows, prefix-match the PowerShell-wrapped vector you actually see in the approval, not just grep.
  4. Restart the CLI session after editing rules.

Evidence: there are two "don't ask again" flavors. The weak one stores the exact command string. prefix_rule is the documented reusable form.

Independent community workaround; not an official OpenAI fix.