Permissions & Trust

Posit Assistant asks for confirmation before performing potentially risky actions like editing files or running shell commands. You can customize this behavior with approval modes, per-tool permissions, and workspace trust.

Approval Modes

Four modes control how tool confirmations behave:

Mode	Behavior	Activate with
Normal	Default. Safe operations run automatically; risky actions prompt for confirmation.	Default behavior
Auto	A classifier model reviews risky tool calls and allows or blocks them.	/auto command or --auto CLI flag
YOLO	Auto-approve all tool calls except explicitly dangerous operations.	/yolo command
Restricted	Require confirmation for everything. Applied automatically to untrusted workspaces.	/restricted command, or open an untrusted workspace

Toggle between modes with the /auto, /yolo, and /restricted slash commands.

In a managed deployment, an administrator can cap how permissive a mode may be — see Administrator Policy.

Auto Mode

Auto mode sits between normal and YOLO — instead of asking you to confirm every risky tool call, it sends each one to a classifier model that decides whether the action is safe. If the classifier approves, the tool runs without interruption. If it blocks, the tool call is declined and the assistant is told why.

The classifier allows actions that stay within the working directory: reading and editing files, running tests and builds, committing to the current branch, and making read-only HTTP requests. It blocks actions like piping remote scripts to an interpreter, sending credentials to external endpoints, force-pushing, or modifying production infrastructure. Constraints you state in the conversation (e.g., “don’t push”) are treated as additional block signals.

If the classifier blocks three consecutive tool calls, auto mode pauses and drops back to normal approval mode. Approving the next prompted action resumes it. If the classifier is unavailable or times out, auto mode falls back to the normal confirmation dialog. In headless mode (--auto with a prompt), classifier failures and repeated blocks abort the session instead of prompting.

Approval Scopes

When the assistant asks for confirmation, you can approve at different scopes:

• Once — Approve this single action.
• For this session — Allow this type of action for the rest of the session.
• For this project — Allow this type of action permanently for this project (saved to .posit/assistant/settings.json).

Not every scope is always offered: restricted mode allows Once only, and a prompt that comes from an administrator rule does not offer For this project, because a project file cannot override administrator policy.

Per-Tool Permissions

Configure permissions in your settings file using the permission key:

{
	"permission": {
		"bash": {
			"git *": "allow",
			"rm *": "deny"
		},
		"read": "allow",
		"edit": "ask"
	}
}

Each tool can be set to "allow", "ask", or "deny". For tools like bash, you can use pattern matching to set different permissions for different commands.

Subagent permissions use the task key and match the requested subtype. For example, to deny read-only exploration subagents while continuing to prompt for general-purpose subagents:

{
	"permission": {
		"task": {
			"explore": "deny",
			"general": "ask"
		}
	}
}

The former permission.explore key is no longer supported. Move its "allow", "ask", or "deny" value to permission.task.explore.

Built-in Defaults

Some security defaults are always enforced:

• .env files and .Renviron are blocked from reading (prevents accidental secret exposure)
• Plan files (.posit/assistant/plans/*) are always readable; writing one prompts for confirmation
• deny rules are always enforced, even in auto and YOLO modes

Administrator Policy

If Posit Assistant was started by Posit Workbench, Posit Connect, or another managed launcher, your administrator may have supplied settings that you cannot change. These arrive in the session’s environment rather than in a file you can edit; the delivery mechanism is documented in Administrator-Managed Settings.

Two things administrators most often set affect what you see day to day.

A cap on the approval mode

An enforced approval mode is a maximum, not a fixed value. The order is restricted → normal → auto → YOLO, and you can always choose something stricter than the cap. Above it:

• The mode picker shows the capped modes disabled, labelled Managed by your administrator.
• /auto and /yolo disappear from the command list, and are refused if you type them anyway.
• A headless run started with --yolo or --auto above the cap exits with an error instead of running with prompts nobody can answer.

Your own saved preference is untouched. If your administrator raises the cap later, the mode you had chosen comes back on its own.

Permission rules you cannot override

Administrator permission rules sit above your global and project settings files:

• An enforced deny is absolute. No approval, mode, or setting gets past it.
• An enforced ask always requires a person to answer. YOLO mode won’t auto-approve it, auto mode’s classifier is not consulted for it, a PreToolUse hook cannot allow it on your behalf, and the For this project scope is not offered. Approving Once or For this session works normally. In headless runs these calls are declined, since there is nobody to ask.
• An enforced allow overrides a deny you wrote yourself — but it still becomes a prompt in restricted mode, and it cannot bypass Ask mode’s read-only guarantee.

Administrators can also set defaults rather than enforced values. Those behave like ordinary settings: they sit below your own configuration, and you can override them.

Other things an administrator can manage this way include MCP servers (an administrator-supplied server starts even in an untrusted workspace) and plugins (managed marketplaces cannot be removed, and a plugin an administrator disabled cannot be re-enabled). Workspace trust itself is never administrator-configurable.

Workspace Trust

When you open a project for the first time, Posit Assistant checks for files that could influence its behavior:

• AGENTS.md — Memory file
• .posit/assistant/settings.json — Project-level settings

If any of these exist, you’ll be asked to trust the workspace or open in restricted mode. This prevents untrusted projects from injecting prompts or auto-approving dangerous operations.

Trusting a Workspace

• Click Trust this workspace when prompted, or use the /trust command.
• Trust is persistent — once trusted, the workspace stays trusted across sessions.
• In restricted mode, project memory files are not loaded and certain tools (like subagent spawning) are blocked. Your user-level memory file (~/.posit/assistant/AGENTS.md) is your own configuration and still loads.

Sandbox Mode

Sandbox mode constrains how the shell tools (Bash and PowerShell) run. How it does so depends on your platform, and the two approaches differ in kind: macOS and Linux confine what a command can do, while Windows limits which commands may run at all.

On macOS and Linux, commands run inside an OS-level sandbox. macOS uses Seatbelt (SBPL) to deny by default: writes are allowed only to the workspace and $TMPDIR, all network access is blocked, and sensitive paths (~/.ssh, ~/.gnupg, ~/.aws, etc.) can’t be read. Linux uses bubblewrap to the same end. Any command may run, but commands are isolated at the OS level.

On Windows, no OS-level sandbox is available, so the safeguard is different: rather than confining a command, sandbox mode restricts which commands are allowed to run. A command executes only if every part of it is on a built-in allowlist of known-safe, read-only commands; anything else is refused with Operation not permitted. There is no filesystem or network isolation — an allowlisted command runs with full access to your machine.

In Sandbox mode, other tools (including web fetch, web search, and R/Python code execution) work as normal.

Toggle sandbox mode with the /sandbox command, or persist it via sandbox.enabled in your config file.

Permission Resolution Order

When multiple sources define permissions, they’re resolved in this order (highest priority first):

1. Administrator deny rules (absolute — nothing below can approve past them)
2. Conversation-scoped approvals (from “Allow for conversation”)
3. Project-scoped approvals (from “Allow for project”)
4. Administrator ask / allow rules
5. Project config (.posit/assistant/settings.json)
6. Global config (~/.posit/assistant/settings.json)
7. Administrator default rules
8. Built-in security defaults
9. Tool’s default permission
10. Fallback: "ask"

Layers 1, 4, and 7 are empty unless your deployment sets them. Approving in the current conversation sits above administrator ask rules on purpose: an ask is a request for your decision, and giving it is exactly what satisfies the rule.

In older versions, the configuration directories were .positai/ and ~/.positai/ instead of .posit/assistant/ and ~/.posit/assistant/.