Skip to main content

Core concepts

Decisions

Termyte uses four decisions:
block > ask > warn > allow
The strongest matching risk or policy result wins.

Semantic actions

Termyte converts recognized command text into stable semantic IDs such as:
  • secret.access;
  • git.push.force;
  • package.npm.publish;
  • filesystem.delete.wildcard;
  • sql.drop-table.
Policies match these IDs instead of relying only on literal command text.

Risk and blast radius

Risk is the built-in baseline. For filesystem deletes, Termyte also resolves targets, checks whether they are inside the repository, classifies sensitive paths, and estimates recoverability.

Policy

YAML policy adds built-in, global, and repository rules to the stable check path. Experimental runtime policy uses repository-local SQLite block and warn lists. Policy can strengthen a decision. It cannot weaken a stronger built-in risk or policy result.

User memory

You can mark exact commands safe or unsafe. An exact unsafe match can upgrade an otherwise allowed check to a warning. Memory never weakens a block.

Check events and runtime ledger

Stable checks write redacted JSONL events. Experimental command and shell execution write a separate SQLite ledger with planned and finalized outcomes.

Agent launch and governed shell

termyte run <agent> launches supported agents in limited mode with Termyte context. termyte shell is the lower-level experimental interception surface. It uses command shims and supported shell hooks, but it is not a sandbox.