Tauri 2 capability files: limits of build-time permission scoping across desktop and mobile targets

Direct answer

A single shared capability file is realistic for Tauri 2.x desktop and mobile builds only when every permission identifier is recognized by the plugin set on all targets. In practice, splitting per target is safer whenever desktop-only permissions—such as arbitrary filesystem paths or raw shell execution—are involved. Build-time validation typically rejects an unknown permission identifier for a target rather than silently dropping it, so a desktop-only permission usually fails the mobile build during capability validation. If a permission is accepted but the underlying OS API is sandboxed (for example, unrestricted filesystem paths on iOS or Android), the command compiles and then fails at runtime with a platform error. Desktop has no runtime elevation API inside the capability system; expanding access requires rebuilding and redistributing the binary.

Confirmed vs. likely

Confirmed by Tauri 2.x design: capability files live under src-tauri/capabilities/, are validated at build time, and desktop access is fixed at build time. Mobile OSes layer their own requirements on top of Tauri capabilities—entitlements, usage-description strings, and interactive prompts—which are configured in platform project files, not in the capability JSON.

Likely but version-sensitive: whether a specific desktop permission is rejected by mobile validation or merely becomes a no-op depends on the plugin's permission set and the exact Tauri 2 minor release. The capability schema field used for platform scoping has shifted across versions, so confirm the current field name before relying on it.

Steps for this case

1. Audit each plugin permission against its platform-gated list. Remove desktop-only identifiers from any shared file, or gate them using the platform field supported by your Tauri version.
2. Keep a shared baseline capability for genuinely cross-platform permissions (app-scoped storage, clipboard, notifications) and add platform-specific files only where behavior diverges.
3. For mobile, configure OS-level requirements separately: iOS entitlements and NS*UsageDescription keys, Android manifest permissions and runtime permission requests.
4. Run the mobile build with the shared file in place. If validation fails, the error identifies the rejected identifier; split that permission into a desktop-only capability file.
5. Test sandboxed commands on a simulator or device. A runtime platform error confirms the permission compiled but the OS blocked it.

Missing diagnostic

Which Tauri 2 minor version and plugin set are you using? The exact platform-scoping field name and the set of mobile-rejected permissions vary by release, and that detail determines whether you can safely keep a single file or must split.