tauri-core

name	tauri-core
description	Shared reference for the Tauri cluster: the v2 security model (capabilities → permissions → scopes), the IPC trust boundary and command contract, the process/runtime model, CSP, and the per-platform distribution matrix. USE WHEN configuring Tauri permissions/scopes/CSP, wiring IPC commands, or planning a release — the interlocking rules every Tauri spoke shares.
cluster	tauri
version	1.0.0

Tauri Core

Shared model for the tauri cluster. The config, IPC, and distribution spokes all depend on these interlocking concepts — keep them consistent here so no spoke contradicts another.

1. The security model (Tauri v2's defining feature)

Access is default-deny. You opt windows into capabilities, which bundle permissions, which may be narrowed by scopes:

Window/Webview ──has──> Capability ──includes──> Permission(s) ──constrained by──> Scope(s)

• Permission — a single allowed command/behavior (often shipped by a plugin, e.g. fs:read-files). Default + custom permissions live in src-tauri/permissions/ and plugin manifests. → configuring-tauri-permissions
• Capability — a JSON file in src-tauri/capabilities/ that grants a set of permissions to specific windows/webviews (by label) and platforms. This is how you wire permissions to surfaces. → configuring-tauri-capabilities
• Scope — allow/deny data that narrows a permission (e.g. which paths fs may touch, which URLs http may reach). Deny scopes win over allow. → configuring-tauri-scopes

Rule: grant the narrowest capability that works; prefer per-window capabilities over global; treat any scope widening (new path, new host) as a security change worth stating.

2. CSP & web boundary

The Content-Security-Policy in tauri.conf.json governs what the webview may load/execute. Keep it strict (no blanket unsafe-inline/*); add only the origins you need. Custom protocol/header needs → configuring-tauri-csp, configuring-tauri-http-headers.

3. IPC trust boundary & command contract

The frontend is untrusted; Rust is the trusted core. Everything crosses one boundary:

• Commands (JS → Rust): #[tauri::command] fns registered in the invoke_handler; called via invoke(). Validate every argument in Rust — never trust the webview. → calling-rust-from-tauri-frontend
• Events (Rust → JS and back): emit/listen for fire-and-forget streams. → calling-frontend-from-tauri-rust, listening-to-tauri-events
• A command is reachable from a window only if a capability grants the matching permission. → understanding-tauri-ipc

4. Process & runtime model

• Core process (Rust) owns the event loop, windows, plugins, and the privileged API; one per app. → understanding-tauri-process-model, understanding-tauri-runtime-authority
• Webview process(es) render UI, sandboxed, reach the core only via IPC.
• Sidecars are external binaries the core spawns under scope control. → embedding-tauri-sidecars, running-nodejs-sidecar-in-tauri
• Lifecycle/security posture → understanding-tauri-lifecycle-security, understanding-tauri-ecosystem-security.

5. Distribution matrix

Target	Spoke	Needs
macOS	distributing-tauri-for-macos	Apple Developer ID, notarization
Windows	distributing-tauri-for-windows	code-signing cert (Authenticode)
Linux	packaging-tauri-for-linux	AppImage/deb/rpm targets
iOS	distributing-tauri-for-ios	Apple provisioning, Xcode toolchain
Android	distributing-tauri-for-android	Android SDK/NDK, keystore

Cross-cutting: signing-tauri-apps (identities), optimizing-tauri-binary-size, building-tauri-with-github-actions (CI matrix), using-crabnebula-cloud-with-tauri (managed).

6. Version / conventions

• Target Tauri v2 (tauri-v2); the capability/permission system above is v2-specific. Coming from v1 → migrating-tauri-apps. Keep core + plugin versions aligned → updating-tauri-dependencies.
• Frontend is framework-agnostic (any JS, or a Rust frontend) → integrating-tauri-js-frontends, integrating-tauri-rust-frontends.

7. Shared guardrails

• Default-deny: narrowest capability/permission/scope that works; per-window over global.
• Validate all command inputs in Rust; the webview is untrusted.
• Strict CSP; explicit allowlists only.
• State every security-surface change (new permission, scope path, host, capability).
• Confirm signing identity + platform prerequisites before a release build.
• Tauri vs Electron: pick Tauri for small binaries + a hardened Rust core + the capability model; if the team is all-JS with heavy Node-native needs, weigh the electron cluster.