Windows PowerShell: approval rules miss gh --json arguments with bare commas

[escape0707]

What version of the Codex App are you using (From "About Codex" dialog)?

26.513.4821.0

Codex CLI bundled with the app: codex-cli 0.131.0-alpha.9

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

PowerShell: 7.6.1

GitHub CLI: authenticated with Windows keyring

What issue are you seeing?

On Windows PowerShell, Codex approval rules do not match otherwise safe commands when an argument contains an unquoted comma-separated value.

Example configured rule:

prefix_rule(pattern=["gh", "issue", ["list", "view", "status"]], decision="allow")

This command still asks for approval:

gh issue view 18861 --repo openai/codex --json number,title,state

This equivalent command auto-approves as expected:

gh issue view 18861 --repo openai/codex --json "number,title,state"

The practical effect is that common gh --json field1,field2,field3 commands unexpectedly stop for approval in native Windows Codex sessions even though the command prefix is already allowed.

This matters because authenticated gh on Windows uses the real user's Windows credential store. A sandboxed Codex command runs under a different restricted identity and cannot access that token, so safe read-only gh commands need to be escalated and matched by allow rules. The bare-comma parsing mismatch breaks that workflow.

What steps can reproduce the bug?

1. In native Windows Codex App on Windows, add:

prefix_rule(pattern=["gh", "issue", ["list", "view", "status"]], decision="allow")

2. Run:

gh issue view 18861 --repo openai/codex --json number,title,state

3. Compare with:

gh issue view 18861 --repo openai/codex --json "number,title,state"

What is the expected behavior?

Codex should classify the unquoted and quoted forms equivalently for approval-rule matching, because both are normal ways to pass a comma-separated --json field list to gh from PowerShell.

At minimum, the approval prompt should explain that the command was not matched because the PowerShell command parser treated the bare comma syntax as unsupported or non-simple.

Additional information

The relevant code path appears to be:

• codex-rs/core/src/shell.rs: PowerShell commands are wrapped as pwsh -Command <script>.
• codex-rs/core/src/exec_policy.rs: commands_for_exec_policy delegates PowerShell command extraction to parse_powershell_command_into_plain_commands.
• codex-rs/shell-command/src/command_safety/powershell_parser.ps1: Convert-CommandElement accepts only literal-ish command elements and returns unsupported for other AST shapes.

The user workaround is to quote comma-separated gh --json field lists, but the unquoted form is easy for agents to produce and is accepted by gh/PowerShell.