default.rules is not honored for sandbox-escaping commands even when execpolicy returns allow

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

26.313.41514

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro)

What issue are you seeing?

default.rules is not being treated as sufficient authorization for commands that need sandbox escape.

I reproduced this in both the Codex desktop app and the Codex CLI on Windows with:

• trusted project
• windows.sandbox = "elevated"
• default.rules containing an allow rule for the command

Example rules tested:

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

Then I verified both forms with codex execpolicy check in PowerShell:

codex execpolicy check --pretty --rules $HOME\.codex\rules\default.rules -- git add -A

Result:

{
  "matchedRules": [
    {
      "prefixRuleMatch": {
        "matchedPrefix": ["git", "add"],
        "decision": "allow"
      }
    }
  ],
  "decision": "allow"
}

And also:

codex execpolicy check --pretty --rules $HOME\.codex\rules\default.rules -- "C:\Program Files\PowerShell\7\pwsh.exe" -Command git add -A

Result:

{
  "matchedRules": [
    {
      "prefixRuleMatch": {
        "matchedPrefix": [
          "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
          "-Command",
          "git",
          "add"
        ],
        "decision": "allow"
      }
    }
  ],
  "decision": "allow"
}

Despite that, asking Codex to run git add -A still produces a manual approval prompt when the command needs to escape the sandbox to write under .git.

Inside the sandbox, the failure is expected:

fatal: Unable to create '.../.git/index.lock': Permission denied

What seems wrong is that a command already allowed by default.rules still requires manual confirmation instead of being treated as authorized.

What steps can reproduce the bug?

1. On Windows, set windows.sandbox = "elevated".
2. Mark the repo as trusted.
3. Add an allow rule to ~/.codex/rules/default.rules for git add, for example:

prefix_rule(pattern=["git", "add"], decision="allow")

1. Restart Codex.
2. Confirm the rule matches:

codex execpolicy check --pretty --rules $HOME\.codex\rules\default.rules -- git add -A

1. Ask Codex in the desktop app or CLI to run:

git add -A

1. Observe that Codex still prompts for manual approval when the command needs sandbox escape to write under .git, even though execpolicy check already says the command is allowed.

I also tested the wrapped PowerShell form and got the same result:

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

codex execpolicy check returns allow for that form too, but the actual command still prompts.

What is the expected behavior?

If default.rules allows a command, and codex execpolicy check returns allow for that same command, Codex should be able to run it without a second manual approval prompt.

At minimum, default.rules should be sufficient authorization for the required sandbox escape for that allowed command.

If that is not the intended model, the docs should say clearly that default.rules only affects execpolicy matching and does not suppress sandbox-approval prompts for those same commands.

Additional information

Important detail: this is not just a desktop-app issue. I reproduced the same behavior in Codex CLI.

So the problem seems broader than one UI surface.

I also tested multiple rule shapes to rule out argv-shape confusion:

• plain command form: pattern=["git", "add"]
• wrapped PowerShell form: pattern=["C:\Program Files\PowerShell\7\pwsh.exe", "-Command", "git", "add"]

Both shapes return allow from codex execpolicy check.

Another important detail: if I approve the prompt using "Yes, and don't ask again...", Codex auto-saves this exact rule into default.rules:

prefix_rule(pattern=["C:\Program Files\PowerShell\7\pwsh.exe", "-Command", "git add -A"], decision="allow")

That exact auto-saved rule works.

So the surprising behavior is more specific than "rules never work": user-authored general prefix rules that codex execpolicy check says are allowed still do not suppress the approval prompt, but the exact command rule auto-saved by the prompt does suppress it.

This makes it look like the real execution path is honoring a narrower, different rule shape than the one accepted by codex execpolicy check and documented in default.rules.