Codex rules control which commands can run outside the sandbox. Each rule matches a command prefix and sets a decision: allow, prompt or forbidden. When several rules match, the strictest decision wins, in the order forbidden, then prompt, then allow. The docs mark rules as experimental, so check them against your version.
Where rules go
Per OpenAI's rules documentation, create a .rules file in a rules/ folder next to an active config layer, such as ~/.codex/rules/default.rules. Codex scans every active layer at startup, including team config locations. Project rules in the repository's .codex/rules/ folder load only when the project .codex/ layer is trusted. Restart Codex after adding rules. When you approve a command in the terminal interface, Codex writes the rule to ~/.codex/rules/default.rules.
That last behavior is worth knowing: approving a command can add a standing rule, so review that file now and then.
The rule format
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "Viewing PRs is allowed with approval",
match = ["gh pr view 7888"],
not_match = ["gh pr --repo openai/codex view 7888"],
)
Fields:
pattern: a non-empty list of literals, or unions of literals for alternatives at one position.decision: allow, prompt or forbidden, with allow as the default.justification: a reason Codex may show in prompts or rejection messages.matchandnot_match: examples Codex validates when it loads the rules.
The example shows why the pattern must be an exact prefix: the second command puts a flag before the subcommand, so it does not match.
Decisions
- allow: runs outside the sandbox without prompting.
- prompt: asks before each matching call.
- forbidden: blocks the request without prompting.
Compound commands
For bash -lc style calls, Codex splits simple chains joined by &&, ||, a semicolon or a pipe and evaluates each part. Scripts with redirection, substitutions, variables, wildcards or control flow are evaluated as one whole call. So a rule that forbids one tool is weaker against a script that wraps it.
Test before you rely on it
The docs provide a check command that prints the strictest decision and the matching rules, and you can pass several rule files at once:
codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- gh pr view 7888 --json title,body,comments
Admins
Admins can enforce restrictive prefix_rule entries through the requirements file. For local computer access with Work Cloud, managed command rules go in the rules field in Agent Security, and local .rules files do not apply there.
Rules versus the sandbox
Rules widen or narrow what escapes the sandbox. They are not a substitute for it, and a short, strict list beats a long clever one.
Quick check
Two rules match a command, one allow and one forbidden. What happens?
The strictest decision applies, so it is forbidden.
Do project rules always load?
No. They load only when the project .codex layer is trusted.
Sources
Last reviewed: 19 October 2026.
