Windows Codex Desktop approval rules match "powershell.exe -Command" instead of inner command

Open 💬 6 comments Opened Apr 26, 2026 by JDoucette

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows Codex Desktop, agent tool commands are executed through PowerShell even when the integrated terminal shell is set to Git Bash. Persisted approval prefix rules therefore match the outer PowerShell invocation instead of the user-meaningful inner command, making it impractical or unsafe to blanket-approve common commands such as git add and git commit -m.

Environment

Product: Codex Desktop app
OS: Windows 11
Shell setting: Integrated terminal shell set to Git Bash
Observed after full Codex app restart

Reproduction

In Codex Desktop on Windows, set Settings -> General -> Integrated terminal shell to Git Bash.
Restart Codex Desktop.
Open a new chat in a repo.
Ask Codex to run a git add or git commit command.
It will ask to blanket accept all commands starting with powershell.

Expected

It should already be running in a shell
I should be able to dictate that shell
the commands running should be "git add" not "powershell.exe -Command "git add ...""

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

#19629

Powered by Codex Action

JDoucette · 2 months ago

It is not a duplicate, but it is related.
If you fixed https://github.com/openai/codex/issues/19629 or allow a terminal to be set, so that commands can just be the commands themselves and not prefixed with a shell, then this issue goes away.
But if you only allow another shell via fixing https://github.com/openai/codex/issues/19629 and continue to force the shell to also launch with each command, then this will not be fixed.

little-wheat · 2 months ago

This issue also exists in the Cli. The actual command being run is pwsh, which causes the Rules to not match.

ufthygygh · 2 months ago

I think this is the same issue as #20713, with a slightly different reproduction.

Additional evidence from my environment:

OS: Microsoft Windows NT 10.0.26200.0
Shell: PowerShell 7.6.1
Codex version: codex-cli 0.128.0

Rules such as these validate successfully with codex execpolicy check:

prefix_rule(pattern=["npm", "test"], decision="allow")
prefix_rule(pattern=["npm", "run", "build"], decision="allow")
prefix_rule(pattern=["node", "--test"], decision="allow")
prefix_rule(pattern=["git", "config", "--list"], decision="allow")

But runtime shell execution can still ask for approval for commands covered by those rules, including:

npm test
npm run build
node --test --version
git config --list

When I select the persistent approval option from the runtime prompt, Codex writes the rule using the PowerShell wrapper. For example, after approving npm test, the persisted line in default.rules is:

prefix_rule(pattern=["C:\\Program Files\\PowerShell\\7\\pwsh.exe", "-NoProfile", "-Command", "npm test"], decision="allow")

So codex execpolicy check reports the inner-command rule as allowed, but the runtime approval path persists the outer PowerShell command instead.

I closed #20713 as a duplicate of this issue.

ufthygygh · 2 months ago

One extra detail that may help make the bug clearer: when I select the persistent approval option from the runtime prompt, Codex writes the rule using the PowerShell wrapper, not the inner command.

For example, after approving npm test, the persisted line in default.rules is:

prefix_rule(pattern=["C:\\Program Files\\PowerShell\\7\\pwsh.exe", "-NoProfile", "-Command", "npm test"], decision="allow")

So the persisted rule is tied to C:\Program Files\PowerShell\7\pwsh.exe -NoProfile -Command ... instead of the documented inner-command form:

prefix_rule(pattern=["npm", "test"], decision="allow")

kraybit · 2 months ago

Seems this was fixed in PR https://github.com/openai/codex/pull/20336
Seems 0.129.0-alpha.2 contains the fix.
Co-Authored-By: GPT-5 : )