Policy Rules

Policy rules control what tools Codex can use. Rules are evaluated before intent plans - a denied tool stays denied even if it appears in the plan. Applying a policy change is human-only: Codex can read policy and stage a proposal, but only you can confirm it.

How Rules Work

1. Rules evaluate top-to-bottom in the order they appear
2. First matching rule wins (allow, deny, or hold)
3. If no rule matches, the default decision applies (allow unless you change it)
4. New rules are added at the top, giving them the highest priority

Rule Effects

Adding Rules

Use armor policy add to stage a rule change. All changes go through a stage then confirm workflow:

armor policy add deny bash

ArmorCodex responds with a diff and risk warnings showing what will change. Then confirm:

armor yes

Multiple Rules at Once

Comma-separate different effects:

armor policy add allow bash and apply_patch, deny apply_patch

This stages all the rules in one proposal. Confirm with armor yes.

Tool Names

Use Codex tool names directly. Codex's shell tool has several internal names, all normalized to bash:

Setting the Default Decision

The default decision applies when no rule matches. By default tools with no matching rule are allowed. To fail closed, set the default to deny (this appends a catch-all rule) and confirm:

armor policy default deny
armor yes

Options: allow, deny, hold.

Removing Rules

Remove by rule ID (shown in armor policy list), then confirm:

armor policy remove policy1
armor yes

Clear all rules:

armor policy reset
armor yes

Both go through the stage then confirm workflow.

Policy Templates

Apply a pre-built policy in one command, then confirm:

armor policy template lockdown
armor yes

Data Classification

ArmorCodex auto-detects sensitive data in tool arguments:

Example: Block Payment Data

armor policy add deny * for payment data
armor yes

If Codex tries to write a credit card number to a file, ArmorCodex detects PCI data, matches the payment rule, and blocks the tool call.

The Stage then Confirm Workflow

Every policy mutation goes through staging. This prevents accidental changes:

1. You type a command (e.g., armor policy add deny bash)
2. ArmorCodex stages the proposal and shows a diff plus risk warnings. Nothing is enforced yet
3. You review and either confirm or cancel:

Staged proposals are written to policy-pending.json with an id, hashes, the base version, and a 30 minute expiry.

Human-Only Apply

Applying a policy change is human-only. The policy_command MCP tool (callable by Codex) can read policy and stage proposals, but it cannot confirm. Only a terminal armor yes applies a staged change, and confirm echoes the applied diff and notes who staged it.

Viewing Policy

Policy Schema

ArmorCodex stores policy as a simple rule list:

{
  "rules": [
    { "id": "policy1", "action": "deny", "tool": "bash" },
    { "id": "policy2", "action": "deny", "tool": "*" }
  ]
}

Rules are evaluated in order; the first match wins. Each rule matches by tool name (with an optional trailing * glob, e.g. mcp__github__*) and can add matchers for finer control:

Matcher Operators

Plain string sugar is supported: anyParam: "curl" is the same as anyParam: { "$contains": "curl" }.

Natural Language (Back-Compat)

The older natural-language form still works and applies immediately (no staging):

Policy list
Policy new: deny bash containing curl
Policy delete policy1
Policy reset

Prefer the structured armor policy commands for the stage then confirm safety.

Where Policies are Stored

Policies persist across sessions in the ArmorCodex data directory:

cat ~/.codex/armorcodex/policy.json

They survive restarts, plugin updates, and re-installs. Override the location with ARMORCODEX_POLICY_FILE.