Permissions and safety
Project permissions, background boundaries, credential storage, and what Rna cannot guarantee yet.
Project permissions
The permission menu under the composer saves the project permission directly:
| Level | Meaning |
|---|---|
| Read-only checks | Can view project files |
| Read and write project files | Can read and write files in the project folder |
| Read, write and run commands | Can read and write project files and run commands as the current user. Not an OS sandbox; the terminal panel needs this level |
Background permissions are set separately from foreground ones, with the choices “Read-only checks” and “Use project permissions”. External MCP still needs its own authorization.
Existing projects never gain write or run permissions implicitly. File writes are hash-checked and atomically replaced; commands have cancel, timeout, output truncation and a full log.
Capability assignment
Skills, tools and MCP are installed to a catalog first, then assigned to projects. Installed, enabled and assigned are three different states, and capabilities are never handed to other projects automatically. An MCP server’s allowTools list is the complete permission boundary; tools the server adds later get nothing. See Skills and MCP.
Change isolation and rollback
In a Git repository, subagents and background work change files in their own worktrees; merging back never overwrites your uncommitted edits or touches your index, HEAD and branches. Every turn keeps a checkpoint, so what it wrote into the project can be rolled back as a whole. Discarding in the Workspace changes panel takes two steps and is never available to agents. See Isolation and rollback.
Background work
- Read-only by default. Only after you choose “use project permissions” does the background inherit permissions within assigned capabilities.
- Background
project_execruns under macOS seatbelt, with no writes outside the project, temp folders and package caches. - Every file background work changes is snapshotted and can be reverted in one click.
- A write that clearly breaks a constraint you stated is refused with the reason (at most twice per file).
Credentials
- Keys for models, search and memory live in a local credentials file (
0600) or are read from an environment variable you name in settings; the JEV key is saved under “Judgment” in settings, or taken from theTYPESAFE_API_KEYenvironment variable. - Settings APIs only report whether a key is configured; keys are never returned.
- The credentials file is a plain local file, not yet in the system keychain.
Not guaranteed yet
Use Rna within these limits
- Foreground commands and MCP are limited by app-level path checks, not an OS sandbox.
- The daemon is for one trusted local user, listens on
127.0.0.1by default, and must not be exposed to the internet. - Process-tree cleanup for MCP children is guaranteed on POSIX; on Windows only direct children are terminated.
- Writes with uncertain results are never replayed automatically, but Rna cannot prove what happened inside an external system.
Memory
Two ways to remember, pick one: the built-in local memory or OpenViking semantic memory. When a service is unavailable it says so, and the two never stand in for each other.
Desktop workbench
What the sidebar, conversation, tasks and evolution are each for; the workspace on the right has its own guide.