0.135: default.rules prompt for git push is ignored under danger-full-access / granular rules=true

Open 💬 1 comment Opened May 30, 2026 by kjendrzyca

What version of Codex are you using?

codex-cli 0.135.0

What platform are you using?

macOS arm64

What happened?

A default.rules prompt rule for git push was matched by codex execpolicy check, but the runtime allowed an agent-initiated git push origin main to run without an approval prompt.

This happened in a trusted project while using unrestricted filesystem/network access plus granular approval configuration with rules = true.

Relevant config

# ~/.codex/config.toml
sandbox_mode = "danger-full-access"
approval_policy = { granular = { sandbox_approval = false, rules = true, mcp_elicitations = false, request_permissions = false, skill_approval = false } }
approvals_reviewer = "user"
// ~/.codex/rules/default.rules
prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    justification = "Publishing changes requires approval"
)

Expected behavior

When the agent attempts to run:

git push origin main

Codex should show an approval prompt because default.rules says decision = "prompt" for git push and granular rules = true is enabled.

Actual behavior

The agent ran git push origin main and pushed successfully without an approval prompt.

The /permissions UI only showed coarse profiles: Default, Auto, and Full. It did not show whether ~/.codex/rules/default.rules was active, nor any custom/granular rules state.

Diagnostics

codex execpolicy check correctly reports prompt:

codex execpolicy check --pretty --rules ~/.codex/rules/default.rules -- git push origin main
{
  "matchedRules": [
    {
      "prefixRuleMatch": {
        "matchedPrefix": ["git", "push"],
        "decision": "prompt",
        "justification": "Publishing changes requires approval"
      }
    }
  ],
  "decision": "prompt"
}

codex doctor --summary --ascii reports:

Codex Doctor v0.135.0 · macos-aarch64
sandbox: filesystem unrestricted · network enabled
Configuration: sandbox unrestricted fs + enabled network · approval Granular(GranularApprovalConfig { sandbox_approval: false, rules: true, skill_approval: false, request_permissions: false, mcp_elicitations: false })

Notes

This looks related to the broader class of issues where execpolicy check, runtime command normalization, and the permissions UI do not fully agree, but I did not find an exact duplicate for the under-prompting case on macOS 0.135:

The direct rule appears valid; the issue is that the runtime path did not enforce the prompt despite execpolicy check returning prompt.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗