mirror of
https://github.com/openai/codex.git
synced 2026-03-05 21:45:28 +03:00
## Why `execpolicy` currently keys `prefix_rule()` matching off the literal first token. That works for rules like `["/usr/bin/git"]`, but it means shared basename rules such as `["git"]` do not help when a caller passes an absolute executable path like `/usr/bin/git`. This PR lays the groundwork for basename-aware matching without changing existing callers yet. It adds typed host-executable metadata and an opt-in resolution path in `codex-execpolicy`, so a follow-up PR can adopt the new behavior in `unix_escalation.rs` and other call sites without having to redesign the policy layer first. ## What Changed - added `host_executable(name = ..., paths = [...])` to the execpolicy parser and validated it with `AbsolutePathBuf` - stored host executable mappings separately from prefix rules inside `Policy` - added `MatchOptions` and opt-in `*_with_options()` APIs that preserve existing behavior by default - implemented exact-first matching with optional basename fallback, gated by `host_executable()` allowlists when present - normalized executable names for cross-platform matching so Windows paths like `git.exe` can satisfy `host_executable(name = "git", ...)` - updated `match` / `not_match` example validation to exercise the host-executable resolution path instead of only raw prefix-rule matching - preserved source locations for deferred example-validation errors so policy load failures still point at the right file and line - surfaced `resolvedProgram` on `RuleMatch` so callers can tell when a basename rule matched an absolute executable path - preserved host executable metadata when requirements policies overlay file-based policies in `core/src/exec_policy.rs` - documented the new rule shape and CLI behavior in `execpolicy/README.md` ## Verification - `cargo test -p codex-execpolicy` - added coverage in `execpolicy/tests/basic.rs` for parsing, precedence, empty allowlists, basename fallback, exact-match precedence, and host-executable-backed `match` / `not_match` examples - added a regression test in `core/src/exec_policy.rs` to verify requirements overlays preserve `host_executable()` metadata - verified `cargo test -p codex-core --lib`, including source-rendering coverage for deferred validation errors
4.1 KiB
4.1 KiB
codex-execpolicy
Overview
- Policy engine and CLI built around
prefix_rule(pattern=[...], decision?, justification?, match?, not_match?)plushost_executable(name=..., paths=[...]). - This release covers the prefix-rule subset of the execpolicy language plus host executable metadata; a richer language will follow.
- Tokens are matched in order; any
patternelement may be a list to denote alternatives.decisiondefaults toallow; valid values:allow,prompt,forbidden. justificationis an optional human-readable rationale for why a rule exists. It can be provided for anydecisionand may be surfaced in different contexts (for example, in approval prompts or rejection messages). Whendecision = "forbidden"is used, include a recommended alternative in thejustification, when appropriate (e.g.,"Use `jj` instead of `git`.").match/not_matchsupply example invocations that are validated at load time (think of them as unit tests); examples can be token arrays or strings (strings are tokenized withshlex).- The CLI always prints the JSON serialization of the evaluation result.
- The legacy rule matcher lives in
codex-execpolicy-legacy.
Policy shapes
- Prefix rules use Starlark syntax:
prefix_rule(
pattern = ["cmd", ["alt1", "alt2"]], # ordered tokens; list entries denote alternatives
decision = "prompt", # allow | prompt | forbidden; defaults to allow
justification = "explain why this rule exists",
match = [["cmd", "alt1"], "cmd alt2"], # examples that must match this rule
not_match = [["cmd", "oops"], "cmd alt3"], # examples that must not match this rule
)
- Host executable metadata can optionally constrain which absolute paths may resolve through basename rules:
host_executable(
name = "git",
paths = [
"/opt/homebrew/bin/git",
"/usr/bin/git",
],
)
- Matching semantics:
- execpolicy always tries exact first-token matches first.
- With host-executable resolution disabled,
/usr/bin/git statusonly matches a rule whose first token is/usr/bin/git. - With host-executable resolution enabled, if no exact rule matches, execpolicy may fall back from
/usr/bin/gitto basename rules forgit. - If
host_executable(name="git", ...)exists, basename fallback is only allowed for listed absolute paths. - If no
host_executable()entry exists for a basename, basename fallback is allowed.
CLI
- From the Codex CLI, run
codex execpolicy checksubcommand with one or more policy files (for examplesrc/default.rules) to check a command:
codex execpolicy check --rules path/to/policy.rules git status
- To opt into basename fallback for absolute program paths, pass
--resolve-host-executables:
codex execpolicy check \
--rules path/to/policy.rules \
--resolve-host-executables \
/usr/bin/git status
- Pass multiple
--rulesflags to merge rules, evaluated in the order provided, and use--prettyfor formatted JSON. - You can also run the standalone dev binary directly during development:
cargo run -p codex-execpolicy -- check --rules path/to/policy.rules git status
- Example outcomes:
- Match:
{"matchedRules":[{...}],"decision":"allow"} - No match:
{"matchedRules":[]}
- Match:
Response shape
{
"matchedRules": [
{
"prefixRuleMatch": {
"matchedPrefix": ["<token>", "..."],
"decision": "allow|prompt|forbidden",
"resolvedProgram": "/absolute/path/to/program",
"justification": "..."
}
}
],
"decision": "allow|prompt|forbidden"
}
- When no rules match,
matchedRulesis an empty array anddecisionis omitted. matchedRuleslists every rule whose prefix matched the command;matchedPrefixis the exact prefix that matched.resolvedProgramis omitted unless an absolute executable path matched via basename fallback.- The effective
decisionis the strictest severity across all matches (forbidden>prompt>allow).
Note: execpolicy commands are still in preview. The API may have breaking changes in the future.