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

Three modes control how tool confirmations behave:

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

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 YOLO mode

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 isolates bash tool execution by restricting filesystem and network access. When enabled, shell commands run inside a platform-specific sandbox:

• 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

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"