/desktop-security-tauri

name: desktop-security-tauri
description: Tauri 2.x deny-by-default security model, capabilities, permissions, scopes, ACL

Tauri Capabilities & ACL

> **Quick Guide:** Tauri 2 uses a deny-by-default security model. Nothing is accessible unless explicitly granted in a capability file (`src-tauri/capabilities/*.json`). Capabilities bind permissions to specific windows. Permissions follow the `plugin:command` identifier pattern. Scopes restrict operations to specific paths or URLs with allow/deny lists (deny always wins). Every plugin and custom command needs a permission grant -- missing permissions cause runtime errors, not compile errors. > > **Current version:** Tauri 2.x (stable). Tauri 1.x used a boolean allowlist which is completely removed in v2.

---

<critical_requirements>

CRITICAL: Before Using This Skill

> **All code must follow project conventions in CLAUDE.md** (kebab-case, named exports, import ordering, `import type`, named constants)

**(You MUST create at least one capability file in `src-tauri/capabilities/` -- without it, ALL plugin and core API calls fail at runtime)**

**(You MUST include `core:default` in every capability -- without it, basic app lifecycle commands fail)**

**(You MUST scope permissions to specific windows using the `windows` array -- a window not listed in any capability has zero IPC access)**

**(You MUST use deny scopes to restrict sensitive paths -- deny ALWAYS takes precedence over allow)**

**(You MUST use `plugin:permission-name` format for plugin permissions and plain `permission-name` for app commands)**

</critical_requirements>

---

**Auto-detection:** Tauri capabilities, src-tauri/capabilities, capability file, permissions, ACL, allow-scope, deny-scope, core:default, fs:allow, shell:allow, http:allow, permission set, remote domain, CapabilityRemote, desktop-schema.json, mobile-schema.json, scope allow deny, Tauri security, tauri permission denied, capability identifier

**When to use:**

• Creating or modifying capability files for a Tauri 2 app
• Granting permissions to specific windows or webviews
• Restricting filesystem, HTTP, or shell access with scoped permissions
• Writing custom permissions for your own Tauri commands
• Grouping permissions into permission sets
• Enabling remote domain access to Tauri APIs
• Debugging "permission denied" or "not allowed" runtime errors
• Migrating from the Tauri v1 allowlist to v2 capabilities

**When NOT to use:**

• Writing Tauri commands or IPC bridge logic (use desktop-framework-tauri)
• Plugin installation and registration (use desktop-framework-tauri)
• Window management, system tray, or menus (use desktop-framework-tauri)
• General Rust programming unrelated to Tauri ACL
• Frontend framework patterns

**Key patterns covered:**

• Capability file structure and fields ([examples/core.md](examples/core.md))
• Window-specific and platform-specific capabilities ([examples/core.md](examples/core.md))
• Scoped permissions with allow/deny lists ([examples/core.md](examples/core.md))
• Custom permission definitions in TOML ([examples/custom-permissions.md](examples/custom-permissions.md))
• Permission sets for grouping related permissions ([examples/custom-permissions.md](examples/custom-permissions.md))
• Remote domain access ([examples/core.md](examples/core.md))
• Debugging permission errors ([examples/core.md](examples/core.md))
• Migration from v1 allowlist ([reference.md](reference.md))

**Detailed resources:**

• [examples/core.md](examples/core.md) - Capability files, scoped permissions, window/platform targeting, remote access, debugging
• [examples/custom-permissions.md](examples/custom-permissions.md) - Custom permission definitions, permission sets, app-level permissions
• [reference.md](reference.md) - Permission identifier patterns, path variables, core permissions, v1 migration checklist

---

<philosophy>

Philosophy

Tauri 2 implements a **deny-by-default** access control model. Every potentially dangerous operation (filesystem, network, shell, clipboard) is blocked until explicitly granted in a capability file. This is a fundamental shift from v1's boolean allowlist -- instead of toggling features on/off globally, you define granular permissions scoped to specific windows, platforms, and paths.

**The security hierarchy:**

1. **Capabilities** - Bind permissions to windows/webviews. A window not listed in any capability has zero IPC access. 2. **Permissions** - Define what operations are allowed or denied. Follow the `plugin:command` identifier pattern. 3. **Scopes** - Restrict WHERE operations can act (paths, URLs). Deny always supersedes allow.

**Key design decisions:**

• **Granular, not global** -- permissions are per-window, per-platform, per-path
• **Deny wins** -- if a path is denied by any scope, it is blocked even if allowed by another
• **Runtime, not compile-time** -- missing permissions cause runtime errors, not build errors. This makes debugging harder but allows dynamic permission resolution.
• **Schema-driven** -- capability files reference auto-generated schemas (`desktop-schema.json`, `mobile-schema.json`) for IDE autocompletion

**When to invest in fine-grained capabilities:**

• Multi-window apps where windows need different permission levels
• Apps handling sensitive data (credentials, financial records)
• Apps distributed publicly where security posture matters
• Apps with remote content that needs limited API access

**When simple capabilities suffice:**

• Single-window apps with straightforward needs
• Internal tools where the security boundary is less critical
• Prototypes and MVPs where iteration speed matters more

</philosophy>

---

<patterns>

Core Patterns

Pattern 1: Capability File Structure

Every Tauri 2 app needs at least one capability file in `src-tauri/capabilities/`. The file grants permissions to specific windows.

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "main-capability",
  "d