Permissions

Swarmie uses rule-based permission evaluation with trust presets.

Source of truth:

• Presets: crates/permissions/src/preset.rs
• Rule syntax: crates/permissions/src/rule.rs
• Evaluation precedence: crates/permissions/src/evaluator.rs

Trust Presets

safe

Read-only workflow with sandboxed web tools.

• Allow: Read, Glob, Grep, FileSearch
• Sandbox: WebFetch, WebSearch
• Deny: Bash, Write, Edit, NotebookEdit, Patch

standard (default)

Recommended default for day-to-day coding.

• Allow: file tools + Undo + safe bash patterns
  • Bash(cargo *)
  • Bash(npm run *)
  • Bash(git status)
  • Bash(git diff *)
  • Bash(git log *)
  • Bash(git branch *)
• Sandbox: WebFetch, WebSearch
• Ask: risky git operations (git push, git commit, git checkout, git rebase, git merge, git reset)
• Deny: Bash(rm -rf *)

full

All core tools allowed natively, no sandbox/ask/deny rules.

Rule Syntax

Rules are strings in one of these forms:

• ToolName
• ToolName(specifier)

Examples:

• Bash(npm run *)
• Read(./src/**)
• WebFetch(domain:*.example.com)

Matching behavior:

• Tool name is case-insensitive.
• No specifier means "all calls to this tool".
• Specifiers use glob/prefix matching.
• domain: specifiers match URL hostnames for WebFetch.

Evaluation Precedence

PermissionEvaluator::evaluate() applies rules in this order:

1. Bypass mode (bypass=true) -> allow.
2. Read-only mode + mutating tool -> reject.
3. Deny rules (agent overrides, then global) -> reject.
4. Session allows -> allow.
5. Agent non-deny rules (ask > sandbox > allow).
6. Global non-deny rules (ask > sandbox > allow).
7. Default -> escalate (ask user).

Interactive Permission Responses

When a permission prompt appears in TUI (pending_permission):

• y -> allow once
• n -> deny
• a -> always allow this session rule
• ! -> bypass all checks for the session
• Ctrl+C -> deny

These are handled in crates/tui/src/app/update/keys.rs.