Skip to main content

​
Configure policies

Termyte has two policy surfaces:
  1. YAML policy for the dependable check, policy, and limited agent preparation workflows.
  2. Runtime policy stored in SQLite for run --, allow-once, inspect, and the experimental governed shell.
They share semantic action IDs, but they are configured separately.

​
YAML policy layers

YAML rules are additive across three levels:
LevelLocationUse
Built-inincluded with TermyteSafe defaults available everywhere
Global~/.termyte/policy.yamlYour rules across repositories
Repository<repo>/termyte.policy.yamlRules committed or applied to one repository
If TERMYTE_HOME is set, global policy is stored at $TERMYTE_HOME/policy.yaml. Review the active layers: 
termyte policy presets
termyte policy show
termyte policy show --json
Rules from all layers are evaluated together. A repository or global rule cannot weaken a stronger built-in decision.

​
Decisions

Policy actions are ordered by strength: 
block > ask > warn > allow
  • allow: no policy review is required.
  • warn: flag the action as risky.
  • ask: require explicit human review in a workflow that supports approval.
  • block: do not permit the recognized action.
check never executes commands, so ask appears as a decision rather than an interactive prompt. Experimental direct runtime approval currently prompts for warn; its SQLite policy surface supports block and warn lists.

​
Create policy with supported plain English

Preview before saving: 
termyte policy local add "Ask before touching auth or payments" --dry-run
Save repository policy: 
termyte policy local add "Ask before touching auth or payments" --yes
Save global policy: 
termyte policy global add "Never allow agents to read .env files" --yes
This compiler is deterministic and local. It supports a fixed set of policy families and shows generated YAML before saving. Unsupported or ambiguous text fails without changing a file. Supported families:
  • secret access;
  • force push;
  • auth and payment paths;
  • test deletion;
  • package publishing;
  • infrastructure and deployment paths;
  • destructive database commands.

​
Write YAML policy directly

version: 1
presets:
  - "git-safe"
rules:
  - name: "ask-auth-payment-changes"
    description: "Review changes to sensitive application paths"
    action: ask
    match:
      paths:
        - "src/auth/**"
        - "src/payments/**"
Available matcher groups:
  • semantic_ids
  • commands
  • paths
When one rule contains multiple matcher groups, every group must match. Test the result: 
termyte policy show
termyte policy test "<command>"

​
Configure experimental runtime policy

The runtime policy is a repository-local SQLite block/warn list: 
termyte policies
termyte policies defaults
termyte policies status
Add or remove semantic patterns: 
termyte policies add block git.reset.*
termyte policies add warn package.*.publish
termyte policies remove warn package.*.publish
Replace lists: 
termyte policies set --block filesystem.delete.wildcard sql.drop-table --warn package.*.publish
Export, validate, and import: 
termyte policies export --file termyte-runtime-policy.json
termyte policies validate termyte-runtime-policy.json
termyte policies import termyte-runtime-policy.json
Reset explicitly to the current defaults: 
termyte policies reset
policies reset replaces customized runtime policy. policies status reports drift without overwriting your changes.

​
Recommended setup

  1. Keep built-in defaults enabled.
  2. Put personal cross-repository rules in global YAML policy.
  3. Put repository-specific paths and decisions in termyte.policy.yaml.
  4. Test with termyte policy test.
  5. Configure SQLite runtime policy only if you use run -- or shell.