Permissions

Control what the Mind agent can do with capability-based permissions across IDE and CLI

Mind uses a capability-based permissions system that gives you fine-grained, declarative control over what the agent can do. You define rules per capability with match patterns and explicit effects, replacing older binary trust models.

Capability	IDE	CLI	Web
Permissions YAML configuration	✓	✓	N/A
Interactive approval prompts	✓	✓	N/A
Global + workspace scopes	✓	✓	N/A
Sandbox execution without per-action prompts	—	—	✓

On Web, the permissions.yaml model and interactive approvals do not apply: the agent runs inside an isolated cloud sandbox instead of prompting per action, so those rows are marked N/A rather than unsupported.

How it works

The permissions system is built around three core concepts:

Concept	Description
Capabilities	`fs_read`, `fs_write`, `shell`, `web_fetch`, `web_search`, `mcp`, `subagent`, `skill`, `plugin`, `context`, `diagnostics`, `sandbox_network`. Meta-capabilities expand: `all` (everything), `builtin` (all built-in tools), `filesystem` (`fs_read` + `fs_write`)
Effects	`deny` (block always), `ask` (prompt you), `allow` (proceed silently)
Priority	deny > ask > allow — a deny rule always wins regardless of scope

Additional rule properties:

Property	Description
Match patterns	Glob patterns scoping the rule (file paths for fs, command prefixes for shell, server/tool names for MCP)
Exclude	Optional glob patterns that must NOT match — enables "allow everything except X"

Shell command parsing

Shell commands are parsed before pattern matching. Compound commands (using ;, &&, ||, |) are split and each sub-command is evaluated independently. This prevents a rule for npm test * from accidentally matching npm test ; curl attacker.com.

Scopes

Permissions are evaluated across multiple scopes:

Scope	Location	Allowed effects
Mind	Hardcoded security invariants	deny, ask
administration	Enterprise policies in managed-settings.json	deny, ask
user	~/.mind/settings/permissions.yaml	deny, ask, allow
workspace	~/.mind/workspace-roots/<hash>/permissions.yaml	deny, ask, allow
agent	Embedded in agent profile (`permissions` field)	deny, ask, allow
session	In-memory rules from consent decisions	deny, ask, allow

Rules are evaluated using a deny-overrides algorithm: deny > ask > allow. There is no precedence between scopes — the most restrictive effect wins regardless of which scope it came from.

Default behaviour

Without any permissions.yaml configured, the default agent policy allows:

fs_read on ./** — read any workspace file silently
shell for common git read-only commands — git status, git log, git diff
shell for system info commands — pwd, whoami, uname

The Mind scope (hardcoded security invariant) enforces:

Always denied: writes to ~/.mind/settings/, .mind/settings/, and ~/.mind/workspace-roots/
Always asks: writes to .git/**, .mind/agents/**, .mind/hooks/**, .mindignore

Managing permissions by surface

In addition to permissions.yaml rules, the IDE's agent autonomy is controlled via Settings → Agent → Agent Autonomy:

Autopilot — the agent proceeds with allowed operations without prompting
Supervised — the agent prompts before any action

When a tool requires approval, an interactive prompt appears in chat with Allow, Always allow, Deny, and Always deny options.

Defining rules

Permissions are defined in YAML files at two levels:

User-scoped (~/.mind/settings/permissions.yaml) — applies across all projects. Use to pre-approve trusted operations:

rules:
  - capability: shell
    match: ["git *", "npm *", "npx *"]
    effect: allow

  - capability: fs_write
    match: ["src/**", "tests/**"]
    effect: allow

  - capability: fs_read
    effect: allow

  - capability: mcp
    match: ["my-server/*"]
    effect: allow

Workspace-scoped (~/.mind/workspace-roots/<hash>/permissions.yaml) — applies only to a specific project. Use to scope rules to one codebase:

rules:
  - capability: fs_write
    match: ["*.env", "*.pem", "*.key"]
    effect: deny

  - capability: shell
    match: ["rm -rf *", "sudo *"]
    effect: deny

Workspace permissions are stored per-user outside the repository at ~/.mind/workspace-roots/<hash(workspaceRoot)>/. A cloned repo cannot inject permission rules — trust is something you configure on your own machine.

Exclude syntax

Rules support an exclude field for "allow everything except" patterns:

rules:
  - capability: mcp
    match: ["my-server/*"]
    exclude: ["my-server/dangerous-tool"]
    effect: allow

Pattern matching

Rules use glob patterns. The syntax differs by capability type:

Filesystem patterns (fs_read, fs_write):

* matches within a single path component
** matches across path separators
brace expansion and character classes are supported
Patterns without wildcards implicitly match children: ~/temp matches ~/temp/child

Shell, web, and MCP patterns:

* matches any sequence of characters
**, ?, and character classes are not supported

rules:
  # Allow npm commands except npm publish
  - capability: shell
    effect: allow
    match:
      - "npm *"
    exclude:
      - "npm publish*"

  # Deny reads to secrets at any depth
  - capability: fs_read
    effect: deny
    match:
      - "**/.env"
      - "**/.env.*"
      - "secrets/**"
      - "**/*.pem"