zeekay
def087ac12
hanzo-dev was a 53-day-frozen diverged fork that release.yml shipped only because codex-rs's v8 dep was believed to block musl. It doesn't — the prebuilt rusty_v8 musl artifacts already exist (rust-release.yml uses them). So collapse to the single canonical tree. - Delete hanzo-dev/ (1416 paths). codex-rs has zero deps on it; its 'unique' crates (zap/sse/backoff) aren't needed (codex-rs has its own upstream impls); zt/zap zero-trust was feature-gated OFF in release builds so it never shipped (external ~/work/hanzozt SDKs + docs unaffected; design notes kept in LLM.md). - Repoint every remaining hanzo-dev build/path ref to codex-rs: workflows (preview-build, issue-code, issue-comment), scripts (ci-tests.sh, generate-homebrew-formula.sh, pre-release.sh, build-fast.sh, hanzo.sh, hanzo-cli), code-sign actions, dependabot.yaml, merge-policy.json, docs. - Port the dev-fast cargo profile into codex-rs/Cargo.toml (build-fast.sh / pre-release.sh / release.yml preflight all use it). - Delete obsolete hanzo-dev-only tooling (check-codex-path-deps.sh, upstream-merge/diff-crates.sh) + repoint their callers. - package.json/build-fast.sh build only --bin dev (codex-rs has no dev-tui/dev-exec split bins). Verified locally: codex-rs builds `dev` (Hanzo Dev header, CODE_VERSION-aware); zero dangling source refs (only npm package names + Homebrew formula name kept).
2.9 KiB
Execution policy
Every Code can enforce your own rules-based execution policy before it runs shell commands. Policies live in Starlark .codexpolicy files under ~/.code/policy (Code still reads ~/.codex/policy for backward compatibility).
How to create and edit rules
TUI interactions
Codex CLI will present the option to whitelist commands when a command causes a prompt.
Whitelisted commands will no longer require your permission to run in current and subsequent sessions.
Under the hood, when you approve and whitelist a command, codex will edit ~/.codex/rules/default.rules.
Editing .rules files
- Create a policy directory:
mkdir -p ~/.code/policy. - Add one or more
.codexpolicyfiles in that folder. Code automatically loads every.codexpolicyfile in there on startup. - Write
prefix_ruleentries to describe the commands you want to allow, prompt, or block:
prefix_rule(
pattern = ["git", ["push", "fetch"]],
decision = "prompt", # allow | prompt | forbidden
match = [["git", "push", "origin", "main"]], # examples that must match
not_match = [["git", "status"]], # examples that must not match
)
patternis a list of shell tokens, evaluated from left to right; wrap tokens in a nested list to express alternatives (for example, match bothpushandfetch).decisionsets the severity; Code picks the strictest decision when multiple rules match (forbidden > prompt > allow).matchandnot_matchact as optional unit tests. Code validates them when it loads your policy, so you get feedback if an example has unexpected behavior.
In this example rule, if Code wants to run commands with the prefix git push or git fetch, it will first ask for user approval.
Preview decisions
Use the code execpolicy check subcommand to preview decisions before you save a rule (see the codex-execpolicy README for syntax details):
code execpolicy check --policy ~/.code/policy/default.codexpolicy git push origin main
Pass multiple --policy flags to test how several files combine, and use --pretty for formatted JSON output. See the codex-rs/execpolicy README for a more detailed walkthrough of the available syntax.
Example output when a rule matches:
{
"matchedRules": [
{
"prefixRuleMatch": {
"matchedPrefix": ["git", "push"],
"decision": "prompt"
}
}
],
"decision": "prompt"
}
When no rules match, matchedRules is an empty array and decision is omitted.
{
"matchedRules": []
}
Status
execpolicy commands are still in preview. The API may have breaking changes in the future.