'Yes, and don't ask again for commands that start with' too narrow #8778

Activity

1. AprilGrimoire

   added

   bugSomething isn't workingSomething isn't working

   on Jan 6, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Jan 6, 2026
3. Gumbraise commented on Jan 6, 2026

   

   Gumbraise

   on Jan 6, 2026

   More actions

   still on 0.78.0
4. fury0928 commented on Jan 8, 2026

   

   fury0928

   on Jan 8, 2026

   More actions

   @etraut-openai may I work on this bug?

   My approach is like this way - Modify both functions to use only the first token (base command) instead of the full command
   Change will be affected try_derive_execpolicy_amendment_for_prompt_rules() and try_derive_execpolicy_amendment_for_allow_rules() function, let me know if I can put with this suggestion.

   Thank you
5. etraut-openai commented on Jan 13, 2026

   

   etraut-openai

   on Jan 13, 2026

   Contributor

   More actions

   The parameters for a command can greatly impact what it does. For example, rm foo and rm -rf . have very different effects, so we can't use just the first token.

   If you want finer-grained control over commands that you allow, you can check out our recently-added support for execution policy rules.
6. etraut-openai

   closed this as not plannedon Jan 13, 2026
7. AprilGrimoire commented on Jan 16, 2026

   

   AprilGrimoire

   on Jan 16, 2026

   Author

   More actions

   The parameters for a command can greatly impact what it does. For example, rm foo and rm -rf . have very different effects, so we can't use just the first token.

   If you want finer-grained control over commands that you allow, you can check out our recently-added support for execution policy rules.

   Why don't let the model decide what generality of no prompt to suggest?

   👍React with 👍2Reacted by MNeMoNiCuZ and AprilGrimoire
8. MNeMoNiCuZ commented on Feb 5, 2026

   

   MNeMoNiCuZ

   on Feb 5, 2026

   More actions

   Every other CLI editing tool handles this gracefully. If it requests too broad a command, the user will just reject and explain why.
   As it is, it's a useless option as it uses the entire command as "...commands that start with..."

     Would you like to run the following command?
   
     $ Select-String -Path js\app.js -Pattern "searchUrl" -Context 1,1
   
     1. Yes, proceed (y)
   › 2. Yes, and don't ask again for commands that start with `Select-String -Path js\app.js -Pattern "searchUrl"
        -Context 1,1` (p)
     3. No, and tell Codex what to do differently (esc)
   

   Like, this is baffling, how is this not solved? It makes the CLI completely useless as I need to approve EVERY SINGLE COMMAND it tries to execute, unless it's doing EXACTLY the same operation again.

   And it's the same every time it tries to save a file:

     Would you like to make the following edits?
   
     js/app.js (+6 -2)
   
   ...
   
   › 1. Yes, proceed (y)
     2. Yes, and don't ask again for these files (a)
     3. No, and tell Codex what to do differently (esc)
   

   Should I really have to approve every file to be written to? Why don't you let me approve writing to files for the session, and for all files inside the working directory? Is this not the entire point of the tool?!

   What am I missing?

   👍React with 👍2Reacted by AprilGrimoire and Simon Heimler
9. jamesxsc commented on Feb 27, 2026

   

   jamesxsc

   on Feb 27, 2026

   More actions

   Also happy to work on this

   👍React with 👍1Reacted by Simon Heimler
10. MNeMoNiCuZ commented on Feb 27, 2026

    

    MNeMoNiCuZ

    on Feb 27, 2026

    More actions

    Please @jamesxsc, be the hero we need!