Security and Permissions

thndrs does not treat the TUI as a security boundary. It runs local tools as the current user, inside the selected workspace, with deterministic limits and audit records.

Tool Boundary

The model can act only through the tools exposed by thndrs. File tools reject paths that escape the workspace root. Search, reads, URL fetching, shell output, and transcript rendering are bounded by timeouts, byte caps, result caps, and line truncation.

AGENTS.md files are guidance, not permissions. They can steer behavior, but they cannot grant extra filesystem access, change tools, or disable safety limits.

Shell Commands

run_shell executes an argv array with std::process::Command. It is not a raw shell string tool. The command runs with the permissions of the thndrs process and is not sandboxed by approval prompts or in-process policy.

If a task needs real isolation, run thndrs inside a container, VM, or OS-level sandbox with the filesystem and credentials you are willing to expose.

MCP Servers

MCP servers are external tools configured by the user. Stdio servers run as local child processes with the same user permissions as thndrs.

Streamable HTTP servers receive requests at the configured URL with the configured headers.

thndrs does not infer or enforce a server-specific permission model.

MCP tools cannot replace built-in tool names or change prompt identity. They are namespaced as mcp__{server}__{tool} and use the shared timeout, output cap, redaction, and session audit path. Those limits bound what thndrs records and shows but do not sandbox what the MCP server itself can do.

ACP Agents

ACP agents are external local child processes configured by the user. A configured agent owns its model loop, but thndrs still owns the workspace boundary, TUI permission prompts, cancellation, and local session records.

ACP filesystem callbacks are workspace-contained. ACP terminal callbacks run as local child processes under the same user account as thndrs. Their cwd is kept inside the workspace, output is capped and redacted, and lifecycle metadata is recorded in the session log.

Writes

Write-capable tools are workspace-contained and transcripted. Each create, replace, and patch write builds the complete new content in a temporary file in the target directory, flushes and synchronizes it, closes it, and only then installs it.

A failed write therefore leaves the previous target bytes intact and cleans up its temporary file.

Creates use a no-clobber install: if another writer creates the target after validation, the create fails instead of overwriting it.

Replacements preserve the existing target permissions on platforms that expose them. Replacement installs are atomic on Unix-like platforms. On platforms whose filesystem does not support replacing an existing path with rename (including Windows), the operation fails without replacing the target.

Session records store write metadata such as path, operation, hashes, and byte counts but do not store full file contents.

Secrets

Command output redaction is best effort.

thndrs redacts common token patterns in displayed and recorded shell output, but it cannot guarantee every secret is detected.

Avoid running commands that print credentials.