Tauri Sandbox Permissions: Debugging Silent Command Failures in v2

Debugging why a Tauri command executes silently in version 2 can feel like chasing a ghost. You write a function, call it from the frontend, and nothing happens—not even a console error. The culprit is almost always the sandboxing system introduced in Tauri v2, which requires explicit permission declarations for every plugin action.

How Tauri v2 enforces sandbox permissions

Tauri v2 replaced its predecessor’s flat permission model with a granular capability system. Every plugin operation—whether reading a file, executing a shell command, or opening a URL—must be explicitly allowed in the application’s configuration file. Without the correct declaration, the command fails silently on the frontend, and the Rust backend never executes it.

The primary configuration file is src-tauri/capabilities/main.json, where developers define permissions for the main window:

{
  "identifier": "main-capability",
  "description": "Permissions for main window",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "fs:read-all",
    "fs:write-all",
    "shell:allow-execute",
    "opener:allow-open",
    "global-shortcut:allow-register",
    "global-shortcut:allow-unregister"
  ]
}

Note that as of Tauri v2.1, shell:allow-open is obsolete. The recommended replacement is tauri-plugin-opener with the permission opener:allow-open.

Step-by-step debugging for silent command failures

When a Tauri command stops responding without errors, follow this structured approach to identify the root cause:

• Inspect the browser console in development mode by pressing Cmd+Option+I. Look for rejected promises or permission-related errors, such as plugin:shell|execute not allowed.

• Review terminal output while running tauri dev. The Rust backend logs permission denials directly in the terminal. Search for messages like [tauri] permission denied or not allowed.

• Enable verbose logging by setting the environment variable RUST_LOG=tauri=debug before launching the development server. This provides detailed backend logs that clarify permission issues.

• Verify the capabilities file first. Misspelled or missing permission identifiers are the most common cause of silent failures.

The console typically reveals permission errors as a rejected promise with a message such as plugin:shell|execute not allowed. Always start troubleshooting by reviewing the capabilities configuration.

Essential permissions for common use cases

Tauri’s permission system supports both broad and scoped permissions. Below are the most frequently required declarations for a typical desktop application:

{
  "permissions": [
    "core:default",
    "fs:read-all",         // Read any file on the system
    "fs:write-all",        // Write any file on the system
    {
      "identifier": "shell:allow-execute",
      "allow": [
        {
          "name": "my-cmd",
          "cmd": "adb",
          "args": true
        }
      ]
    },
    "opener:allow-open",   // Open URLs and files (replaces shell:allow-open)
    "path:allow-app-data-dir",
    "notification:default",
    "global-shortcut:allow-register",
    "clipboard-manager:allow-read-text",
    "clipboard-manager:allow-write-text"
  ]
}

Important: The shell:allow-execute permission now requires an explicit allow scope. Wildcards are blocked by default for security reasons, so specific commands must be listed individually.

Using scoped permissions for production safety

For filesystem operations, Tauri encourages the use of scoped permissions to limit access to only necessary directories. This reduces the attack surface and aligns with the principle of least privilege.

A scoped permission example for reading only the application data directory:

{
  "identifier": "fs:allow-app-data-read",
  "allow": [
    {
      "path": "$APPDATA/**"
    }
  ]
}

While fs:read-all simplifies development, it should never be used in production builds. Always define precise scopes to protect user data and system integrity.

Final assessment: A necessary trade-off for security

Tauri v2’s permission model prioritizes security through sandboxing, but the silent failure mode can frustrate developers. Once you understand the debugging flow and common pitfalls, resolving silent command failures becomes straightforward.

Always check the capabilities file first when a plugin or command stops working after an update. Minor changes in permission identifiers, such as opener replacing shell:allow-open, are frequent sources of unexpected behavior. By adopting scoped permissions and reviewing configurations proactively, you can build secure Tauri applications without sacrificing functionality.