Desktop App (Tauri)

Mac + Windows · Tauri v2 · v0.6.0-beta

This page was rewritten on 2026-07-03

An earlier version described two tier builds (Scholar and Wizard) fed by a browser extension, with a LOCI_TIER build flag, tier-specific installers, and a native-messaging bridge. None of that exists in the repository. The shipped app is a single build, described below.

The loci desktop app is the cockpit: a native dashboard plus a tab for each instrument your palace generates for itself. It ships in the public repository under desktop/, released together with the CLI as the 0.6 open beta.

The app is an expression built on top of the substrate, not the substrate. The substrate is plain markdown, and you do not need the app to start: any file-aware AI can run a palace from templates/ alone.

---

What the app does

• Operations tab: the native dashboard. Reads palace state directly from disk: scheduled-job status, recent handovers, and open tasks.
• Instrument tabs: one tab per palace map the app discovers. A palace map is a self-contained *.html page your palace generates for itself (a map, a watcher, a ledger) with its data embedded as JSON. The app finds instruments by convention, never by configuration, and embeds them through a path-validated read (no raw filesystem exposure).
• Tool shelf, a gate ledger: reads the tools list from your palace's palace-map.json and renders one card per tool with its recorded quarantine verdict: admitted, admitted-escorted, deferred, held-conditional, or rejected. The shelf lists; it never loads or runs a tool. If your palace has no ledger, the section stays quiet.
• Palace detection and portability: point the app at a folder and it finds your palace. Both supported layouts load: rooms at the palace root, or rooms inside a _palace/ subfolder. No fixed home directory is required.
• Scaffolding: no palace yet? The app can bootstrap a fresh one, including a short guided first-run setup.
• Update check: compares the version anchor in your palace's PALACE-METHODOLOGY.md against the published methodology (a single GET, no user data sent) and reports the delta. It proposes; it never applies anything by itself.
• Local inference (optional): connects to a local Ollama instance for AI features with zero API keys. Fails closed: if no backend is available, inference features stay off rather than silently calling out.

The app ships a working MCP server (JSON-RPC over HTTP, 127.0.0.1:3456 only) in v0.6.0-beta, compiled into the release. There is no button for it yet: see the MCP API reference for how to reach it today, and Architecture and the FAQ for the full status.

---

First run

1. The app asks you to pick a folder.
2. It detects and validates a palace there (either supported layout) and loads it.
3. If there is no palace, it offers to scaffold one, with a short setup ceremony to name things.

That is the whole flow. There is no account, no sync, and nothing leaves your machine.

---

Downloads

No prebuilt installers are published yet. Build from source below.

---

Building from source

Prerequisites: Rust (stable), the wasm32-unknown-unknown target, Trunk, Node.js 18+, Tauri CLI v2

The desktop frontend is a Leptos (Rust/WASM) app in src-leptos/, not a plain TypeScript app. Tauri's dev and build commands shell out to Trunk to compile it, so Trunk and the wasm32 target need to be installed first:

rustup target add wasm32-unknown-unknown
cargo install trunk

Then:

git clone https://github.com/huximaxi/loci
cd loci/desktop
npm install

Development:

npm run tauri:dev

Production build:

npm run tauri:build

Or use the build script:

./build.sh            # macOS universal .dmg (arm64 + x86_64), the default
./build.sh --windows  # Windows NSIS .exe (run on Windows or a Windows CI runner)
./build.sh --dev      # dev server only, no bundle

macOS bundles land in src-tauri/target/universal-apple-darwin/release/bundle/dmg/. Windows installers land in src-tauri/target/release/bundle/nsis/.

---

Rust backend commands

The frontend talks to a Rust backend through Tauri commands. The main ones, grouped by concern:

Commands	What they do
detect_palace, validate_palace_path, load_palace	Find and load a palace (both layouts)
scaffold_palace, scaffold_palace_from_ceremony	Bootstrap a new palace
list_palace_maps, read_palace_map_html	Discover instrument pages and read them for embedding
read_tools_ledger	Read the tool shelf gate ledger from the palace map
read_cron_states, read_handovers, read_tasks	Feed the Operations dashboard from disk
check_for_updates	Report the methodology version delta, read-only
check_ollama_health, list_ollama_models, call_ollama, chat_query	Optional local inference via Ollama
read_loci_config, write_loci_config	App configuration persistence

There is no tier column because there are no tiers: every command in this table ships in the one build. The build's product name and window title still read "loci wizard", a naming leftover from the retired tier system; the commands and behavior underneath are the single unified build described above.

start_mcp_server, stop_mcp_server, and mcp_server_status run the shipped MCP server (v0.6.0-beta, real and compiled in). The shipped frontend never calls them, so today they only run via direct invocation, not from anywhere in the app's interface. See the MCP API reference for the wire protocol.

---

The CLI sibling

The same release includes loci-cli/, a small Rust binary that reads your palace from the terminal. Five commands, all read-only: loci status, loci crystals, loci read, loci handover, loci init. No network, no inference, no daemons.

cargo install --path loci-cli

The desktop app and the CLI are two doors into the same palace. Use either, both, or neither.