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.

The model asks to run git status --short; the approval picker offers auto, once, always for this directory, sandbox, full, and deny — autolith · command approval

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.