Desktop shell tool still prompts for sandbox approval even when default.rules allows the command

Summary

In the Windows desktop app, an allowed command in ~/.codex/rules/default.rules is still prompting for manual approval when the command needs to leave the sandbox.

The local rules engine says the command is allowed, but the actual shell execution path still asks for sandbox approval.

Environment

• Codex desktop app on Windows
• Trusted project
• windows.sandbox = "elevated"
• default.rules contains prefixes such as:
• prefix_rule(pattern=["git", "add"], decision="allow")
• prefix_rule(pattern=["git", "commit"], decision="allow")
• prefix_rule(pattern=["bun"], decision="allow")

Reproduction

1. Configure ~/.codex/rules/default.rules with:

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

1. Restart Codex.
2. Verify the rule matches with:

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

Result:

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

1. In the desktop app, ask the agent to run git add -A in a repo on Windows with windows.sandbox = "elevated".

Expected behavior

Because default.rules explicitly allows git add, Codex should run the command without prompting for manual approval.

Actual behavior

The desktop shell path still asks for manual approval because the command needs sandbox escape to write under .git.

In our case, .git writes are blocked inside the Windows elevated sandbox, so git add -A needs to create .git/index.lock. That part is expected. The unexpected part is that the already-allowed command still triggers a second manual approval step.

Extra evidence

• Inside the sandbox, git add -A fails with:

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

• Direct write test showed normal repo-root writes succeed, but writes under .git are denied inside the sandbox.
• codex execpolicy check still reports allow for git add -A.

Why this seems like a bug

There appears to be a mismatch between:

1. the local execpolicy/rules engine, which correctly allows the command, and
2. the desktop shell execution path, which still requires manual sandbox approval.

From a user perspective, default.rules is not being fully respected for commands that require sandbox escape.

What would help

Either:

1. an allowed default.rules command should be sufficient authorization for the required sandbox escape, or
2. the docs should clearly explain that default.rules only governs execpolicy matching and does not suppress sandbox-approval prompts for those same commands.