Victauri

Victauri

Verified Introspection & Control for Tauri Applications

Full-stack testing for Tauri apps. Click a button in the frontend, verify the Rust handler ran, confirm the database row was written — from one test.

---

Testing Tauri apps today means choosing between frontend mocks that lie about your backend, WebDriver setups that take a weekend, or paying for macOS CI runners. Victauri replaces all three: it embeds a lightweight server inside your Tauri process (debug builds only) that gives your test suite, curl, and CI direct access to the DOM, IPC layer, Rust backend state, the database, and native windows — from one test, on all three platforms. No WebDriver. No browser dependency. Works on macOS, Windows, and Linux.

That same server also speaks MCP, so any AI agent — Claude Code, Cursor, Windsurf — can drive and debug your app with the exact same full-stack access. Testing is the job; the agent integration is the bonus.

Tested against real-world Tauri apps. In a one-time deep evaluation (May 2026) across 5 open-source apps (Kanri, En Croissant, Surrealist, Duckling, Lettura), 867 / 895 checks passed (96.9%) with zero Victauri bugs and zero changes to the apps. A reproducible compat harness (scripts/compat) re-runs an app-agnostic smoke battery against the *current* code on demand (and weekly), pinned to three Tauri-2 apps (Kanri, En Croissant, Lettura). It is a best-effort net for upstream drift, not a release gate — third-party apps move on their own schedules and periodically need re-pinning. See the compat README for what it covers and current per-app status.

Note — browser mode removed (2026-06-09). The experimental victauri-browser extension + @4da/victauri-browser npm package (MCP for *any website*) have been removed so Victauri can focus on its strength: full-stack introspection *inside* Tauri apps. For browser automation, use Playwright or the Chrome DevTools Protocol. The Tauri plugin is unaffected. Details & migration: #15.

What You Get

For your test suite and CI:

• Full-stack verification — click a button, verify the IPC call, query the database to confirm the write, check the UI updated — in one test
• Direct backend access — query SQLite databases, browse app files, read config, inspect process memory — no webview proxy
• Ghost command detection — find high-confidence orphaned frontend calls (confirmed_ghosts: invoked but only ever errored "not found"), and backend commands the frontend never calls
• Cross-boundary state checking — compare DOM state against Rust backend state and catch the drift between them
• Time-travel recording — record interactions, checkpoint state, replay sequences, generate test files
• Cross-platform, no WebDriver — the same tool surface on macOS, Windows, and Linux (no CDP dependency); runs headless in CI under xvfb. Platform limits are documented, not hidden: trusted (OS-level) input is Windows-only (other platforms fall back to synthetic events), and window screenshots need X11/XWayland on Linux (pure Wayland fails with a clear error)
• Zero runtime cost in release — the server is gated behind #[cfg(debug_assertions)], so init() is a no-op and nothing listens in release builds. Add victauri-plugin as a normal [dependencies] entry (the app binary cannot see [dev-dependencies]); the crate still compiles in, so to keep it out of release binaries entirely make it an optional dependency behind a Cargo feature (victauri init --optional scaffolds it). SQLite note: the default bundled-sqlite feature turns on rusqlite/bundled, and Cargo feature unification applies it to *your app's* rusqlite too, in release builds as well. If your app links a system SQLite or SQLCipher, use default-features = false, features = ["sqlite"]

Bonus — for AI agents: the same server speaks MCP, so Claude Code, Cursor, Windsurf, and any MCP client get this full-stack access for interactive debugging — no extra setup.

Will Victauri work on your app?

Victauri is a development-time dependency you add to your own app's source and rebuild (a normal [dependencies] entry — not [dev-dependencies], which the app binary cannot use) — not a tool you attach to an already-running or shipped app. It works when all four hold:

1. Tauri 2, or a Tauri 3 pre-release (turn on victauri-plugin's tauri-v3 feature — see the plugin README). Tauri 1.x apps can't host it — their webkit2gtk-sys 0.18 and Victauri's 2.x both link the native web_kit2 library, an unresolvable cargo conflict. (Tauri 2 is the current major; Tauri 1 is legacy.)
2. Built from source with the plugin wired in — one line in Cargo.toml, .plugin(victauri_plugin::init()), and the victauri:default permission (a capability file, or the runtime grant victauri init --optional generates). There is no inject-into-a-foreign-binary path.
3. A debug build. The server is #[cfg(debug_assertions)]-gated, so init() is a no-op and nothing listens in release. It's a dev/test-time tool by design.
4. Each window grants `victauri:default`. Tauri's per-window permission ACL silently blinds the bridge without it; the window introspectability tool detects and explains this.

Framework does not matter, because the bridge works at DOM level: it has been run on React, Vue/Nuxt and vanilla apps (what was actually run). Nor does the OS/webview engine: WebView2, WKWebView and WebKitGTK are all exercised in CI.

Full details, edge cases, and a tested-apps list: Compatibility.

Quick Start

Install the CLI

cargo install victauri-cli

Set up your project

From your Tauri project root:

victauri init

This will:

• Add victauri-plugin and victauri-core (dev: victauri-test, tokio) to your Cargo.toml
• Add .plugin(victauri_plugin::init()) to your Tauri builder when it finds one
• Create capabilities/victauri.json (grants victauri:default), .mcp.json, starter tests in tests/, a CI workflow, a CLAUDE.md block and a Claude Code skill (.claude/skills/victauri/SKILL.md)
• Print any steps it could not do itself

Wire the plugin

Skip this if init reported that it patched your builder. Otherwise add one line:

// src-tauri/src/main.rs (or lib.rs)

tauri::Builder::default() .plugin(victauri_plugin::init()) .invoke_handler(tauri::generate_handler![/* your commands */]) .run(tauri::generate_context!()) .expect("error while running tauri application");

In release builds, init() returns a no-op plugin: the server never starts and the linker strips it, so no feature flags are needed. #[inspectable] likewise compiles none of its metadata (descriptions, intents, examples) into a release build. The plugin's dependencies are still compiled (see below).

Zero release footprint. As an ordinary dependency the crate still *compiles* into a release build (inert; the linker drops the unreachable server, but the default bundled-sqlite feature adds SQLite's C code — about +1.7 MB without LTO, ~58 KB with LTO in a fresh project — and also switches your app's own rusqlite, if any, to bundled). victauri init --optional instead scaffolds Victauri as an optional dependency behind a victauri Cargo feature, so release builds contain none of it; you then start the app with the feature on (npm run tauri dev -- --features victauri, or pnpm tauri dev --features victauri). See Getting Started → Zero release footprint.

Run tests

Start your app, then run the smoke suite:

npm run tauri dev                                # start your app (or pnpm/yarn/bun tauri dev)

cd src-tauri && VICTAURI_E2E=1 cargo test --test smoke -- --test-threads=1 # in a second terminal; tests share one app

On Windows the running app locks its .exe, and cargo test rebuilds it, so give the test run its own target directory: CARGO_TARGET_DIR=target-test VICTAURI_E2E=1 cargo test --test smoke -- --test-threads=1.

Or use the CLI for instant validation:

victauri test                                    # 11 built-in smoke checks

victauri check # server health + IPC diagnostics victauri call dom_snapshot # any tool from the shell → JSON on stdout

Use with your agent

One command per client. Each writes (or merges into) that client's MCP config, pointing at victauri bridge --app , plus agent instructions telling it to prefer Victauri over CDP/Playwright, verify it reached the right app, and await async work with wait_for:

Existing configs are merged, never overwritten (comments in JSONC files survive), re-running changes nothing, and --dry-run shows what would change. See how Victauri compares to other Tauri agent and test tools.

Connect an AI agent by hand

Add .mcp.json to your project root (created automatically by victauri init):

{

"mcpServers": { "victauri": { "command": "victauri", "args": ["bridge"] } } }

The victauri bridge stdio proxy discovers the running app's port at connect time and re-discovers on restart, so th