0.135: default.rules prompt for git push is ignored under danger-full-access / granular rules=true
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:
- https://github.com/openai/codex/issues/15298
- https://github.com/openai/codex/issues/15292
- https://github.com/openai/codex/issues/20713
- https://github.com/openai/codex/issues/10920
- https://github.com/openai/codex/issues/21571
- https://github.com/openai/codex/issues/24201
- https://github.com/openai/codex/issues/14399
The direct rule appears valid; the issue is that the runtime path did not enforce the prompt despite execpolicy check returning prompt.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗