Skip to main content

​
Limitations and threat model

Termyte reduces accidental damage from recognized risky commands. It is not a sandbox and does not make coding agents or untrusted code safe.

​
Strongest use cases

Termyte is useful for:
  • checking known dangerous command text before execution;
  • consistently applying local policy;
  • blocking or warning on recognized high-impact actions;
  • recording local decisions and runtime outcomes;
  • remembering exact commands explicitly marked unsafe;
  • adding review boundaries around coding-agent workflows.

​
Outside the boundary

Termyte does not protect against:
  • malicious root-level attackers;
  • kernel or operating-system compromise;
  • arbitrary malware;
  • all shell obfuscation;
  • commands that bypass Termyte;
  • every direct API or system call;
  • every subprocess created by a limited-mode agent;
  • complete process-tree containment.

​
Recognition limits

Termyte uses deterministic patterns. Unknown or unsupported command forms can fall back to a generic shell action and may be allowed. Detailed target and blast-radius analysis is strongest for recognized filesystem deletes. Other actions may use simpler semantic classification.

​
Interception limits

The experimental governed shell relies on generated shims and supported shell hooks. Absolute executable paths, unshimmed tools, unsupported shells, and processes that do not inherit the governed environment can bypass it.

​
Policy and state split

Stable checks use YAML policy plus JSONL logs and memory. Experimental execution uses separate SQLite runtime policy, ledger, and semantic memory. Configure and review the surface you actually use.

​
Safe operating guidance

  • Test policy with termyte policy test.
  • Use termyte check before risky manual or agent actions.
  • Run termyte doctor before evaluating experimental interception.
  • Keep normal repository, credential, backup, and least-privilege controls.
  • Do not use Termyte as the only boundary for untrusted code.