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.

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 .positai/settings.json).

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.

Built-in Defaults

Some security defaults are always enforced:

• .env files and .Renviron are blocked from reading (prevents accidental secret exposure)
• Plan files (.positai/plans/*) are always writable
• deny rules are always enforced, even in auto and YOLO modes

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
• .positai/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, memory files are not loaded and certain tools (like subagent spawning) are blocked.

Sandbox Mode

Sandbox mode changes how shell tool execution is constrained. The exact enforcement depends on your platform:

• macOS — Uses Seatbelt (SBPL) to deny-by-default, allowing writes only to the workspace and $TMPDIR, blocking all network access, and preventing reads of sensitive paths (~/.ssh, ~/.gnupg, ~/.aws, etc.)
• Linux — Uses bubblewrap for similar isolation with a read-only filesystem overlay and workspace-scoped writes
• Windows — Uses gated mode for the active shell: commands must match a built-in allowlist before they run. This is not an OS-level sandbox and does not provide filesystem or network isolation.

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. Conversation-scoped approvals (from “Allow for conversation”)
2. Project-scoped approvals (from “Allow for project”)
3. Project config (.positai/settings.json)
4. Global config (~/.positai/settings.json)
5. Built-in security defaults
6. Tool’s default permission
7. Fallback: "ask"