Project trust
Control ambient repository inputs before Tau loads them.
Tau asks before loading protected inputs discovered because of the active working directory. The decision is keyed to the canonical, existing cwd—not a guessed repository root. Symlink aliases therefore share a decision, and the nearest saved parent decision is inherited.
Protected inputs
Tau gates project .tau and .agents skills and prompts, .tau themes,
SYSTEM.md and APPEND_SYSTEM.md, plain and scoped AGENTS.md, project
extension candidates, and project settings.json reserved for future support.
Built-in local backends are trusted package code. They load independently of project trust and do not make an ambient endpoint, model snapshot, or credential into project input. Their provider/backend registrations remain owned by the active runtime generation; project extensions cannot reset them without the normal source and trust rules. Detection checks names and metadata only; Tau does not read, parse, or import a candidate before deciding.
User resources under ~/.tau and ~/.agents, built-ins, and paths explicitly
passed on the CLI remain eligible. Trusted built-in extensions are installed Tau
package code rather than cwd discovery: they load before the decision, even with
--no-extensions, and their presence alone never creates a trust prompt. Trusted
project extensions still require the additional --project-extensions opt-in.
Decisions
Interactive startup offers:
- trust this exact folder and save it;
- trust the displayed immediate parent and save it;
- trust for this run only;
- decline this exact folder and save it;
- decline for this run only.
Escape/cancel exits Tau during startup without loading the project. During
/reload or cross-project session replacement, cancellation preserves the
current session snapshot and keeps Tau open.
Saved decisions live in ~/.tau/trust.json, version 1. Tau validates the whole
file and updates it under a lock with restrictive permissions and atomic
replacement. A malformed, unreadable, locked, or unwritable store never grants
saved trust. Run-only approval remains available with --approve.
A child decision overrides an inherited parent decision. Parent trust is broad: Tau displays the exact parent before selection. There is no automatic cleanup when a project moves.
Headless and automation
--approve (-a) and --no-approve (-na) are mutually exclusive, apply only
to the invocation, and never edit the store. Print, JSON, transcript, and other
headless paths never prompt. Their unresolved behavior follows the user-global
defaultProjectTrust setting:
| Value | Headless result |
|---|---|
ask (default) | decline |
always | approve |
never | decline |
Trust diagnostics use stderr in structured modes, so stdout remains machine readable. They report bounded category/count and decision-source information, not protected contents.
Reload and sessions
/reload detects again. An initially empty project that gains protected inputs
requires a new decision; Tau never infers durable trust from the earlier empty
state. Resource preparation is coherent: decline builds a global/explicit-only
snapshot. Resume and replacement resolve the destination record’s canonical cwd
instead of reusing the source project’s outcome.
Built-in local-backend security
The bundled llama.cpp backend is trusted Tau package code. It loads before the
project-trust decision, including with --no-extensions, and never creates a
trust prompt. After backend confirmation, /local probes only its entered,
saved, LLAMA_BASE_URL, or default endpoint; it does not scan ports, processes,
or the local network. Tau never starts/stops the external server or deletes
model files. Explicit downloads are performed by the independent llama.cpp
router, not Tau’s filesystem code.
The safe integration snapshot at ~/.tau/state/extensions/llama.cpp.json
contains only the normalized endpoint, exact model IDs, allowlisted metadata,
and a timestamp. API keys are kept separately in ~/.tau/credentials.json or
read from LLAMA_API_KEY; no key means no Authorization header. Secrets do
not enter snapshots, sessions, exports, or diagnostics. Resetting settings and
deleting a stored credential are separate confirmations. See the local
inference guide for troubleshooting.
The built-in integration does not import or rewrite an existing llama-cpp
catalog entry. Configure llama.cpp separately through /local; Ollama and
other local servers remain on the manual custom-provider path.
Security boundary
Project trust is an input-loading guard, not a sandbox. It does not restrict filesystem reads/writes, processes, shell commands, tools, network access, credentials, providers, models, package installation, prompt injection, or data exfiltration. A trusted project may still be malicious. Use an OS sandbox, container, VM, remote environment, and restricted credentials/network when you need isolation.