Files
dev/docs/execpolicy.md
T
zeekay 806a7c93e7 feat: comprehensive upstream sync and hanzo branding updates
- Merged latest from OpenAI Codex upstream (reasoning effort tracking, apply-patch stability)
- Updated branding from 'Codex' to 'Hanzo Dev' throughout codebase
- Fixed compilation issues in TUI and core modules
- Enhanced build system with hanzo-crypto integration
- Preserved Hanzo identity while maintaining upstream compatibility
- Updated CLI tooling and MCP protocol implementations
- Added comprehensive GitHub Actions integration
2026-01-14 14:54:24 -08:00

3.0 KiB

Execution policy

Hanzo Dev can enforce your own rules-based execution policy before it runs shell commands. Policies live in Starlark .codexpolicy files under ~/.hanzo/policy (Hanzo Dev still reads legacy ~/.code/policy or ~/.codex/policy for backward compatibility).

How to create and edit rules

TUI interactions

Hanzo Dev CLI will present the option to whitelist commands when a command causes a prompt.

Screenshot 2025-12-04 at 9 23 54 AM

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, Hanzo Dev will edit ~/.hanzo/rules/default.rules (legacy: ~/.code/rules/default.rules or ~/.codex/rules/default.rules).

Editing .rules files

  1. Create a policy directory: mkdir -p ~/.hanzo/policy.
  2. Add one or more .codexpolicy files in that folder. Hanzo Dev automatically loads every .codexpolicy file in there on startup.
  3. Write prefix_rule entries 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
)
  • pattern is a list of shell tokens, evaluated from left to right; wrap tokens in a nested list to express alternatives (for example, match both push and fetch).
  • decision sets the severity; Hanzo Dev picks the strictest decision when multiple rules match (forbidden > prompt > allow).
  • match and not_match act as optional unit tests. Hanzo Dev validates them when it loads your policy, so you get feedback if an example has unexpected behavior.

In this example rule, if Hanzo Dev wants to run commands with the prefix git push or git fetch, it will first ask for user approval.

Preview decisions

Use the dev execpolicy check subcommand to preview decisions before you save a rule (see the dev-execpolicy README for syntax details):

dev execpolicy check --policy ~/.hanzo/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 code-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.