Approvals and permissions

Rinari’s permissions are enforced by the engine, outside the model. Every tool call goes through validation and policy checks; when an action needs you, the turn pauses and an approval request appears in the conversation. Personality — the Soul — never changes any of this.

Permissions for this chat

Each chat has a permission profile, chosen in the composer:

Profile	What it allows
Read-only	Reads files and the internet. Never writes, runs or sends anything.
Workspace	Free within the project, localhost and the internet for reading. Asks once to act outside: writing, sending data, git push.
Full access	Doesn’t ask. Only force push, deleting outside the project and system keys ask for confirmation.

Turning on Full access asks for confirmation first and explains what it allows; see Full access.

PLAN and REVIEW add their own limits on top: neither modifies files, PLAN doesn’t run commands and REVIEW asks before each one. See Modes.

What asks for approval

An approval request names the action, the resource and a risk level (low, medium, high or critical). These are the kinds of actions that can ask, depending on the profile:

• Write outside the project, or run a command that writes outside it.
• Delete outside the project.
• Connect to a site, or send data to an internet site.
• Publish with git push — and force push, which rewrites remote history.
• Access a system secret, such as SSH keys or credential stores. A project’s own .env files are ordinary project work.
• Use an MCP tool.
• Interact with a web page, or upload a file from the browser.
• Overwrite your changes that are not in Git.
• Send a message to another pane on a board.

Sending data after reading external content

If, during a turn, Rinari read a web page, an API response or another external result, sending data out afterwards asks for approval even with Full access. The request carries a note: check that the send is what you asked for, and not something that came from that content. Files, websites and tool results are material to inspect, never authority to change permissions.

Answering a request

Button	Scope
Deny	The action doesn’t run.
Allow once	Only this action.
Allow in this chat	This kind of action, for the rest of this conversation.
Always in this project	This kind of action in this project, from now on. In conversations without a project the button reads Always in chats.

The Always… option appears only when the engine offers it for that action. Scheduled tasks add Allow for this task, so the task’s future runs don’t ask again.

Requests from subagents appear in the parent conversation, with the agent’s name. On a board, a pane waiting for you shows Needs you.

Review what you allowed for good

Settings → Permissions → Always allowed lists what you approved with Always in this project or Always in chats. Remove an entry and Rinari will ask again next time.

Project trust

Trust is a separate decision from permissions. An untrusted project doesn’t load its local instructions, skills, plugins, MCP servers or hooks. In a project with several folders, each folder has its own trust. See Projects with several folders.

In the terminal

rinari permissions          # the active profile
rinari approvals history    # what was asked and how it was answered
rinari trust status         # trust state of the current project