Codex Desktop Full Access + project prompt rules hard-reject commands because approval_policy=never

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

Codex Desktop 26.820.60940 (build 7119), bundled CLI codex-cli 0.150.0-alpha.8

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS 26.5.1, build 25F80)

What issue are you seeing?

Selecting Full Access in Codex Desktop creates an approval configuration that cannot satisfy project-level execution rules with decision = "prompt".

The affected turn explicitly recorded:

approval_policy=never
sandbox_policy={"type":"danger-full-access"}
permission_profile={"type":"disabled"}
active_permission_profile=:danger-full-access

The project contains a .codex/rules/default.rules fallback rule equivalent to:

prefix_rule(
    pattern = ["git"],
    decision = "prompt",
    justification = "Any Git command requested outside the sandbox requires explicit user approval."
)

With that combination, even a read-only Git command is rejected before the Git process starts:

exec_command failed for `/bin/zsh -lc 'git status --short --branch'`:
CreateProcess { message: "Rejected(\"approval required by policy, but AskForApproval is set to Never\")" }

Calling the executable by absolute path produces the same result:

exec_command failed for `/bin/zsh -lc '/usr/bin/git status --short --branch'`:
CreateProcess { message: "Rejected(\"approval required by policy, but AskForApproval is set to Never\")" }

Ordinary shell commands such as command -v git, ls -l /usr/bin/git, and pwd succeed in the same turn. This rules out a missing Git executable or a generally broken shell.

The Desktop UI does not warn that Full Access (approval_policy=never) conflicts with an active project rule requiring a prompt. The command is neither executed nor presented for approval, and the error does not identify the matched project rule or offer an actionable way to resolve the conflict.

After the permission profile changed to workspace-write + on-request, git status succeeded immediately and Git operations requiring broader access could surface an approval and complete normally.

What steps can reproduce the bug?

1. Create or open a Git repository with .codex/rules/default.rules containing:

``python
prefix_rule(
pattern = ["git"],
decision = "prompt",
justification = "Git commands require explicit approval."
)
``

1. Open the repository in Codex Desktop.
2. Select Full Access.
3. Start a normal user turn (this reproduction does not require /goal or an automatic continuation).
4. Ask Codex to run:

``bash
git status --short --branch
``

1. Observe the hard rejection:

``text
approval required by policy, but AskForApproval is set to Never
``

1. Switch to a permission mode using approval_policy=on-request and retry. The command succeeds or the required approval can be surfaced.

Observed timeline from one affected session (UTC):

2026-08-27T06:13:57Z  turn starts with approval_policy=never, danger-full-access
2026-08-27T06:14:09Z  git status rejected before process start
2026-08-27T06:14:19Z  command -v git / ls / pwd succeed
2026-08-27T06:14:23Z  /usr/bin/git status rejected before process start
2026-08-27T06:23:27Z  new turn starts with approval_policy=on-request, workspace-write
2026-08-27T06:23:38Z  git status succeeds

Session/thread ID (for OpenAI internal lookup): 019fb19d-2085-7a82-82b2-4b758223b787

What is the expected behavior?

Codex Desktop should not silently allow a permission preset and project rules to create an unusable approval state.

Any of the following would be reasonable:

1. Keep project prompt rules actionable under Full Access, for example by using a granular approval configuration that permits rule-based approvals while filesystem/network access remains unrestricted.
2. Warn when selecting Full Access that active project prompt rules cannot be satisfied under approval_policy=never, and offer a compatible permission mode.
3. If the hard rejection is intentional, identify the matched rule and provide actionable guidance instead of only reporting an internal policy conflict.

This report is not asking Codex to silently bypass project safety rules. The desired behavior is for the project rule to remain enforceable without putting the user into a dead end.

Additional information

The exact error is defined in codex-rs/core/src/exec_policy.rs as PROMPT_CONFLICT_REASON, and prompt_is_rejected_by_policy() returns it for AskForApproval::Never:

https://github.com/openai/codex/blob/main/codex-rs/core/src/exec_policy.rs#L2568-L2593

Related but distinct issues:

• #24300 concerns /goal automatic continuations being downgraded from Full Access. This reproduction occurs in a normal user turn whose recorded context remains danger-full-access + never.
• #25312 reports the opposite behavior: a prompt rule being ignored under unrestricted access with granular rule approvals enabled.
• #26575 asks why rules are still loaded under danger-full-access, but does not cover the unrecoverable prompt + never conflict in the Desktop permission preset.

No full rollout log is attached because it contains unrelated conversation and local project data. The timestamps, permission fields, commands, error text, and session ID above are copied from the local rollout with private repository paths and remote URLs omitted.