What is a Tauri v2 capability configuration?

In Tauri v2, capabilities define what permissions are granted to individual window groups, targeting specific platforms and security scopes.

Where do capability files live in a Tauri project?

They are typically defined in JSON or TOML files within the src-tauri/capabilities/ directory.

How do scoped permissions work in Tauri v2?

Certain plugins (like filesystem or shell) require a defined scope list (e.g. allowed paths or execute targets) to limit system exposure and prevent vulnerabilities.

Tauri v2 Capability Builder | Generate Custom Permissions

1. Capability Metadata

Identifierkebab-case pattern

Description

Target Windows

main

Target Platforms

2. Core Plugins Permissions Matrix

Toggle specific security permissions for each core Tauri plug-in. Adding a scoped permission (like fs:allow-read) will prompt you to configure custom scope parameters.

fs:defaultAllows basic safe file system operations

fs:allow-readNeeds ScopeAllows reading files (Requires Scope)

fs:allow-writeNeeds ScopeAllows writing/updating files (Requires Scope)

fs:allow-existsNeeds ScopeAllows checking if paths exist (Requires Scope)

fs:allow-mkdirNeeds ScopeAllows creating directories (Requires Scope)

fs:allow-removeNeeds ScopeAllows deleting files/directories (Requires Scope)

3. Dynamic Scope Rules Engine

Active Rules Table

Type	Scope Path Target	Action
No filesystem scope rules added. Scoped permissions will generate warnings.

src-tauri/capabilities/default.jsonREAD-ONLY

{
  "$schema": "../gen/schemas/desktop-schema.json",
  "identifier": "default-capability",
  "description": "Capability for the main application windows",
  "windows": [
    "main"
  ],
  "platforms": [
    "macOS",
    "windows",
    "linux",
    "android",
    "iOS"
  ],
  "permissions": [
    "core:default"
  ]
}

Visual Validation & Safety Checklist

Everything looks secure! Zero warnings or syntax anomalies detected.

Using this configuration? Cite us!

Copy this Markdown citation link to reference the Tauri v2 Capability Builder in your GitHub README or technical blog posts:

[Tauri v2 Capability Builder](https://tauri-capability-builder.prophecccy.xyz)

Tauri v2 ACL & Capability Troubleshooting

How do you fix Tauri v2 filesystem permission denied errors?

To fix Tauri v2 filesystem permission denied errors, you must explicitly register the fs:allow-read or fs:allow-write permission inside your capability file at src-tauri/capabilities/default.json and define a precise path scope under the scope property to allow access to targeted directories like $APP_DATA/**/*.

{
  "permissions": ["fs:allow-read"],
  "scope": {
    "allow": [{ "path": "$APP_DATA/**/*" }]
  }
}

How do you configure dynamic scopes for the Tauri v2 shell plugin?

To authorize external command or sidecar execution in Tauri v2, you must assign the shell:allow-execute permission inside src-tauri/capabilities/default.json. You must then map an authorized array containing target binary paths, arguments configurations, and sidecar flags straight to the capability’s local permission scope definitions.

{
  "permissions": [
    {
      "identifier": "shell:allow-execute",
      "allow": [{ "name": "binaries/my-sidecar", "sidecar": true, "args": true }]
    }
  ]
}

What is the difference between Tauri v1 allowlist and Tauri v2 capabilities?

Tauri v1 used global allowlist toggles directly in tauri.conf.json. Tauri v2 replaces this model with decentralized, file-based Capabilities inside the src-tauri/capabilities/ folder, utilizing an Access Control List (ACL) that maps permissions and scope restrictions directly to specific target windows and platforms.