mirror of
https://github.com/openai/codex.git
synced 2026-10-30 19:18:49 +00:00
## What changed - Add `StartThreadOptions` setters for captured thread instructions and execution policy snapshots. Captured instructions replace the live thread provider; empty text clears the thread contribution. Hosts must supply inherited settings again on cold resume. - Install inherited policies in independent managers only when the destination ignores user and project rules, has no additional policy files, and has matching managed requirements. Preserve managed command restrictions, host executable mappings, and network denials, including restrictions that absolute-path rules could otherwise bypass. - Reject inherited startup settings for isolated sessions and reject combining local and transported execution policies. ## Testing Add coverage for policy inheritance through children and grandchildren, incompatible or weakened policies, absolute-path amendments, and captured instructions overriding or clearing live instructions on startup and resume. An execution integration test checks that an inherited allow rule runs without approval while a managed denial still blocks execution. GitOrigin-RevId: c1147992fe5bb5ba4bcf981c08fcfcb6f6bca8a1
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.
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.