Tauri 2.0 Granular Multi-Window IPC Capability Scoping & Privilege Isolation

--- description: Tauri 2.0 Granular Multi-Window IPC Capability Scoping & Privilege Isolation - Enforces strict multi-window IPC boundary isolation in Tauri 2.0 by mandating window-specific capability schemas and denying wildcard permissions across webviews. Restricts OS-level plugin permissions through fine-grained capability definitions and runtime window label verification to prevent privilege escalation from untrusted child windows or webview surfaces. globs: src-tauri/capabilities/**/*.json, src-tauri/tauri.conf.json, src-tauri/src/**/*.rs, src/**/*.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/tauri2-granular-multiwindow-ipc-capability-scoping" --- # Tauri 2.0 Granular Multi-Window IPC Capability Scoping & Privilege Isolation > **Severity**: CRITICAL | **Category**: mobile > **Anti-Pattern Warning**: Global Window Wildcards and Ambient Plugin Permissions in Multi-Window Tauri Architectures ## System Constraints You are a Principal Security Architect enforcing Tauri 2.0 capability isolation invariants. Tauri 2.0 replaces the v1 allowlist with a capability-driven access control model. You must strictly forbid wildcard ('*') window bindings in capability sets that expose native plugins (fs, shell, http, biometric). Enforce window-specific label mapping, context isolation, and cryptographically pinned capability schemas to eliminate sub-window privilege escalation. ## Strict Guidelines - Engineers MUST NEVER use wildcard patterns (`windows: ["*"]`) in capability files that grant filesystem, shell, process, or OS credential access. - Engineers MUST declare distinct capability JSON files for each distinct window label (e.g., `main-capability.json`, `auth-popup-capability.json`). - Services MUST validate caller window labels and execution context in native Rust commands via `tauri::ipc::Request` or `tauri::WebviewWindow` before dispatching OS-level actions. - Components spawning secondary windows (e.g., OAuth popups, preview panes) MUST spawn them with restricted capability sets and enforce strict Content Security Policies (CSP). - Code MUST explicitly scope plugin permissions down to precise filesystem scopes or URL allowlists rather than default plugin bundles (e.g., use `fs:allow-read-text-file` scoped to `$APPCACHE/*` instead of `fs:default`). ## Bad vs Good Implementations ### Multi-Window Capability Isolation and Safe Window Provisioning #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Assigning global capabilities or relying on ambient permissions allows unprivileged or external webviews (such as payment or auth popups) to execute critical system commands through IPC privilege escalation. ```typescript import { WebviewWindow } from '@tauri-apps/api/webviewWindow'; import { invoke } from '@tauri-apps/api/core'; // ANTI-PATTERN: Spawning secondary window without explicit capability boundary // If capabilities.json has 'windows': ['*'], this untrusted child window inherits full host permissions export async function openPaymentModal(paymentUrl: string) { const modal = new WebviewWindow('payment-window', { url: paymentUrl, // Inherits default app capabilities, enabling potential RCE if paymentUrl is compromised }); // Window can execute sensitive OS plugins via generic invoke await invoke('plugin:fs|read_file', { path: '/etc/passwd' }); } ``` #### Production Standard (Correct) > **Standard**: Ensures secondary windows are isolated under distinct window labels mapped to restricted capability schemas, mitigating arbitrary code execution and unauthorized IPC invocation. ```typescript import { WebviewWindow } from '@tauri-apps/api/webviewWindow'; import { invoke } from '@tauri-apps/api/core'; interface SecureWindowOptions { readonly label: `aux-${string}`; readonly url: string; } // INVARIANT: Auxiliary windows must use explicit isolated labels bound to minimal capabilities in capabilities/*.json export async function openIsolatedModal({ label, url }: SecureWindowOptions): Promise<WebviewWindow> { const secureModal = new WebviewWindow(label, { url, // Secondary windows must not access native shell or host filesystem capabilities dragDropEnabled: false, focus: true, }); await new Promise<void>((resolve, reject) => { secureModal.once('tauri://created', () => resolve()); secureModal.once('tauri://error', (e) => reject(new Error(String(e)))); }); return secureModal; } // Verified IPC call restricted to the 'main' window capability schema export async function readAppAuditLog(filePath: string): Promise<string> { return invoke<string>('read_audit_log', { path: filePath, headers: { 'X-Tauri-Caller-Window': 'main' } }); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Tauri 2.0 Granular Multi-Window IPC Capability Scoping & Privilege Isolation

Tauri 2.0 Granular Multi-Window IPC Capability Scoping & Privilege Isolation defines an industrial-grade behavioral standard for mobile engineering. Enforces strict multi-window IPC boundary isolation in Tauri 2.0 by mandating window-specific capability schemas and denying wildcard permissions across webviews. Restricts OS-level plugin permissions through fine-grained capability definitions and runtime window label verification to prevent privilege escalation from untrusted child windows or webview surfaces. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Global Window Wildcards and Ambient Plugin Permissions in Multi-Window Tauri Architectures Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Global Window Wildcards and Ambient Plugin Permissions in Multi-Window Tauri Architectures	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST NEVER use wildcard patterns (`windows

Engineers MUST NEVER use wildcard patterns (`windows: ["*"]`) in capability files that grant filesystem, shell, process, or OS credential access.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.