Tauri 2.x: Rust Commands as a Validated IPC Boundary for Desktop Note Apps

A desktop note app built with a webview faces an immediate tension: the UI layer wants to read and write files, but granting a browser-like runtime unrestricted filesystem access is risky, and bundling Node just to save a text file adds overhead. Tauri offers a middle path. The useful takeaway is to treat the Rust side as the trust boundary and expose a small, validated command API instead of a generic file bridge.

Commands are an API, not a sandbox

In Tauri 2.x, a command is a Rust function annotated with #[tauri::command]. Its arguments and return value must be serializable with serde, which means they cross the inter-process communication (IPC) boundary as JSON values. The webview calls these functions through invoke from @tauri-apps/api/core; it does not receive Rust types, only JSON.

Registration happens in the Tauri builder, typically through a command handler that collects the functions you expose. Because the payload is JSON, the Rust side must own validation. A command is an API endpoint, not a security sandbox.

A worked save_note command

Consider a note saver that writes user content to an application data directory. The command below accepts a relative path and contents, canonicalizes the target, rejects anything outside a dedicated notes folder, and writes the file with std::fs.

use std::path::PathBuf;
use tauri::command;

#[command]
pub fn save_note(path: String, contents: String) -> Result<String, String> {
    let notes_dir = app_notes_root()?; // resolved from app data dir
    let candidate = notes_dir.join(path);
    let canonical = candidate.canonicalize()
        .map_err(|_| "invalid path".to_string())?;

    if !canonical.starts_with(&notes_dir) {
        return Err("path escapes notes directory".into());
    }

    std::fs::write(&canonical, contents)
        .map_err(|_| "write failed".to_string())?;

    Ok(canonical.file_name()
        .and_then(|n| n.to_str())
        .unwrap_or("note")
        .to_string())
}

On the frontend, the call is a promise. If the Rust side returns Err, the promise rejects with the mapped string.

import { invoke } from '@tauri-apps/api/core';

async function save(path: string, contents: string) {
  try {
    const name = await invoke('save_note', { path, contents });
    return `Saved ${name}`;
  } catch (e) {
    return `Rejected: ${e}`;
  }
}

Note what the example does not do: it does not return raw std::io::Error chains or absolute filesystem paths to the webview. Errors are mapped to stable, safe messages.

Capabilities are not input validation

Tauri v2 replaced the older allowlist model with capabilities. A capability file scopes what plugins and operating-system interfaces an app may use, such as fs, shell, or http. Keeping capabilities minimal is still necessary, but it is not sufficient. A permitted filesystem scope does not canonicalize paths or check symlinks; your command must do that itself.

Another runtime concern is blocking. std::fs::write is synchronous. If a command blocks the async runtime, other commands and IPC calls can stall. For file, database, or network work, move the blocking call onto a blocking task or use an async API.

Trade-offs and verification

The main trade-off is duplication. Every command payload needs a Rust type and a TypeScript shape, plus explicit serde behavior at the boundary. Serialization adds overhead compared to a hypothetical native call, and error mapping is manual.

To verify the boundary works as intended, start with a Rust unit test for the path validator: feed it ../outside.txt and a symlink that resolves outside the notes directory, and assert rejection.

# Run in the Rust crate directory (where Cargo.toml lives)
cargo test path_validator

# Run in the frontend project root (or equivalent script in your template)
npm run tauri dev

Both commands require read/write access to the project directory; the dev server also binds a local port. Expect the unit tests to pass and the desktop window to open. A relevant risk is that development configuration may differ from production, so verify the production capability set and content security policy before publishing.

In the frontend, mock invoke and assert that an invalid JSON shape rejects. Then inspect the generated tauri.conf.json and capability files; toggle a plugin permission off and confirm the corresponding invoke fails while your custom command still behaves as designed. Finally, pin the Tauri version in Cargo.lock and the frontend package versions, then re-test after upgrades because v2 capability identifiers and API package names have shifted between releases.

Commands give you a narrow, reviewable surface. Validate every input, map every error, and keep the webview untrusted.