Experimental governed runtime
Termyte provides two experimental execution surfaces:
termyte run -- <command> for one governed command;
termyte shell for an intercepted shell session.
Use termyte doctor before relying on either surface.
Run one command
termyte run -- npm test
termyte run -- npm publish
Before execution, Termyte parses the command, resolves visible targets, checks
risk and runtime policy, consults semantic memory, and writes a pending ledger
record.
allow executes.
warn asks for interactive approval.
block does not execute.
Preview the decision without execution:
termyte run --dry-run -- npm publish
Use a one-time override
termyte allow-once -- <command>
This can override a non-allow runtime decision except for hard-critical
resolved targets such as repository metadata, a home directory, or a
filesystem root.
An override is not a policy change. It applies only to that invocation.
Start a governed shell
Or launch one command through a governed session:
termyte shell -- node --version
The governed shell creates local command shims and shell hooks, then routes
supported commands through a local guard before execution. If a shim or hook
cannot contact the guard, it blocks rather than executing unreviewed.
Review runtime activity
termyte replay
termyte inspect -- npm publish
termyte policies
replay shows the SQLite runtime timeline. This is separate from the stable
JSONL check events shown by termyte logs.
What interception covers
The shell runtime can govern commands that route through generated shims or
supported shell hooks. Common shimmed tools include Git, npm, pnpm, Yarn, npx,
Node, Python, pip, Docker, and common shell hosts.
It does not provide OS-level containment. Absolute executable paths, unshimmed
tools, direct system calls, unsupported shells, and processes that do not
inherit the governed environment can bypass interception.
Termyte is a guardrail, not a sandbox. Do not use it as the only security
boundary for untrusted code.