Tools and permissions
Autolith's tools are typed operations with visible results. Permissions decide which ones run sandboxed, which run with full access, and which are denied outright.
The registry
Tools live in namespaces, and each namespace documents its operations. The everyday set covers the filesystem, workspace search, shell execution, durable resources, the agenda, and plans. Others load Lisp workers, Skills, MCP servers, child tasks, jobs, and the active image itself. Results come back as bounded observations, and the model sees what you see.
Approvals
Shell commands and mutating operations ask before acting. A choice holds for one call or is remembered:
- Once
- Approve this one call, unsandboxed.
- Always
- Approve this command pattern without asking again.
- Sandboxed
- Approve with filesystem and network isolation (Bubblewrap on Linux).
- Deny
- Refuse the call; Autolith works around it.
Automatic permission mode goes further: the model classifies each
command itself, and the outcome is always sandboxed, full access, or
denied. It fails closed, so a decision that would have needed your
approval becomes a denial, never a silent pass. Launch with
--permissions auto (or sandbox,
full) to set the mode for a session, and use
/permissions to change it mid-session.
Guard rails
- Repeated identical mutating tool calls are capped, so a stuck loop cannot chew through your workspace.
- Durable resources are revision-gated: an edit applies only against the exact observation it was written from, so a stale edit fails instead of overwriting.
- Sandboxed commands get filesystem and network isolation on Linux. Without platform sandbox support the sandbox choice is unavailable, and explicit approvals run with your privileges.
Autolith executes model-generated code with your user privileges. Its process boundaries protect reliability, not against hostile code.