CLI: prefix_rule matching fails for shell wrappers and env-prefix commands

What version of Codex CLI is running?

codex-cli 0.106.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex high

What platform is your computer?

MacOS Darwin 24.x arm64

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

Terminal.app (also reproducible in iTerm2)

What issue are you seeing?

Approval rules (prefix_rule) do not consistently apply when command execution is shell-wrapped (/bin/zsh -lc or /bin/bash -lc) or when a command uses leading environment assignments.

Two related failure modes:

1. Existing prefix rules for the underlying command do not match if the executed command is seen as a shell wrapper script instead of normalized inner commands.
2. Commands with env-prefix style invocation (for example GH_TOKEN=... gh ...) are treated as starting with the assignment token, so rules for gh do not match.

Result: Codex repeatedly asks for approval and proposes/stores overly specific rules like full /bin/zsh -lc '...' scripts, which are brittle and do not generalize.

What steps can reproduce the bug?

1. Add this rule:

prefix_rule(pattern=["gh", "api"], decision="allow")

1. Model executes a shell-wrapped command with redirection/connector (representative form):

/bin/zsh -lc 'gh api repos/openai/codex/issues/1 > /tmp/issue.json && jq ".number" /tmp/issue.json'

1. Observe approval is requested even though gh api is allow-listed.
2. Choose “Yes, and don't ask again…”.
3. Observe saved rule is often wrapper/script specific (for example full /bin/zsh -lc '...') rather than a stable command prefix.
4. Repeat with a small command variation (different output path/flags) and observe approval prompts again.
5. Env-prefix variant: run GH_TOKEN=dummy gh api user with the same ["gh", "api"] allow rule; observe prompt instead of a match.

What is the expected behavior?

Policy evaluation and suggested amendments should use a normalized command representation:

1. Shell wrappers should be unwrapped to the actionable inner command(s) when safely parseable.
2. Leading env assignments (KEY=VALUE) prefixes should not prevent matching command-prefix rules.
3. Approval rule suggestions should prefer stable/minimal prefixes (for example ["gh", "api"]) instead of full shell wrapper scripts.
4. When parsing is ambiguous/unsafe, fallback should remain conservative (prompt) and avoid incorrect broad approvals.

Additional information

Potential implementation plan (codebase points):

• Normalize command tokens for exec-policy matching and amendment derivation in codex-rs/core/src/exec_policy.rs:571.
• Reuse wrapper extraction robustness similar to codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs:544 (which scans argv for -c/-lc triples instead of requiring strict argv shape).
• Extend shell command extraction/parsing beyond strict 3-token shell forms in codex-rs/shell-command/src/bash.rs:97.
• Handle env-prefix forms (KEY=VALUE cmd ...) before policy lookup.
• Keep approval-cache canonicalization and policy normalization aligned (codex-rs/core/src/command_canonicalization.rs:14, codex-rs/core/src/tools/runtimes/shell.rs:127, codex-rs/core/src/tools/runtimes/unified_exec.rs:87).

Relevant current behavior in code:

• commands_for_exec_policy(...) falls back to raw argv when shell script parsing fails (codex-rs/core/src/exec_policy.rs:571).
• Shell extraction currently assumes exact [shell, -c/-lc, script] form (codex-rs/shell-command/src/bash.rs:97).
• Tests explicitly reject variable assignment prefixes in the shell parser (codex-rs/shell-command/src/bash.rs:425), which likely contributes to env-prefix mismatch behavior.

Potentially related reports:

• #10920
• #12095
• #10321
• #8980