LiveAgent: A Local-First Agent Desktop Built on Tauri, Rust and React
A fully functional AI Agent desktop client that supports Webui access and can be creatively customized and expanded!
At a glance
- What is it?
- Stack-Cairn's LiveAgent is an MIT-licensed desktop client that gives a model direct access to your file system, shell and scheduled tasks, with an optional Go gateway for browser access. The architecture is coherent and the local execution surface is broad, but the README is a feature list rather than a manual, and that gap is what you have to weigh before installing.
- Who is it for?
- Adopt LiveAgent if you want a desktop agent that edits files, runs Bash and manages long-running processes on your own machine, and you are comfortable reading source to fill the gaps the README leaves. Do not adopt it if you need a documented configuration reference, a stable plugin API contract, or an assurance that the Chinese-language community channels are optional.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap LiveAgent is trying to close
Most chat interfaces to a language model stop at text. The model describes a shell command; you paste it into a terminal. LiveAgent's stated purpose is to remove that copy-paste step for people working on their own machine. The README describes it as a "local-first AI agent desktop client" that integrates model reasoning with local system tools so the agent can "genuinely operate your file system, run commands, and manage scheduled tasks." The intended user is a developer or power user who already pays for model access through an API key or a relay service and wants an agent loop running against a real working directory rather than a sandbox. The README's sponsor section names three API relay providers (PackyCode, RightCode, Cubence) that supplied model resources during development, which tells you the expected setup is bring-your-own-endpoint rather than a bundled subscription.
What the agent can actually touch on your machine
The tool surface listed in the README is specific. File operations are named as Read, Write, Edit and Delete, with Glob and Grep for pattern and regex search. Bash execution is described as non-interactive, taking a working directory and a timeout, and a component called ManagedProcess supervises resident tasks such as dev servers. Sub-agents are described as running in parallel with worktree isolation and automatic merging, which is the same isolation model used by command-line coding agents: each parallel branch gets its own checkout so two agents do not write to the same files. A TunnelManager exposes local services to the public internet, described as one click. Read that list as a permission surface, not a feature list. An agent with Write, Delete and unrestricted Bash on your home directory is a different risk category from one that only reads. The README does not describe an approval prompt, a path allowlist, or a sandbox boundary around these tools, and I cannot confirm from the supplied material whether one exists.
The Tauri, Rust, React and Go split
The badges and the feature text give a rough architecture. The shell is Tauri 2, so the desktop binary is Rust with a system webview rather than a bundled Chromium. The UI is React 19. The remote gateway is Go, communicating over WebSocket with Protobuf, and the README notes that the Tauri side "natively bridges any stdio / http MCP server," which places MCP process management in the Rust layer rather than in JavaScript. Persistence is split: conversation history uses what the README calls dual-layer Segment plus Summary Checkpoint storage to keep long sessions from losing context, and memory uses Markdown files plus SQLite full-text search. That Markdown-plus-SQLite choice means your agent's accumulated knowledge is greppable and editable outside the app, which is a real advantage over an opaque vector store. The cost is that you own the consistency between the two representations.
Installing it, and what the README does not tell you
Installation is download-and-run. The README points to GitHub Releases and states that installers are "automatically built, signed, and published by GitHub Actions." On macOS you pick LiveAgent-<version>-macOS-aarch64.dmg for Apple Silicon or LiveAgent-<version>-macOS-x64.dmg for Intel, open the DMG and drag the app to Applications; the README states the installer is signed and notarized by Apple, so no security override is needed on first launch. Windows requires x64 and the WebView2 runtime, which the README says ships with Windows 11. Linux requires x86_64 and WebKitGTK 4.1, with Ubuntu 22.04+ or Debian 12+ given as examples. That is where the concrete instructions end. The cleaned README does not give the config file path, the key names for model routing, the Base URL field format, or the command to start the gateway. Release v1.3.2 is dated 2026-09-10, five days after v1.3.1, so check the release notes for the version you install rather than assuming the README matches it.
MCP bridging and Skills packages are two different extension models
The README treats MCP and Skills as one ecosystem section, but they solve different problems. MCP is a protocol bridge: the Tauri side connects to any stdio or HTTP MCP server, so the extension is a separate process you point the app at, and the tool definitions come from that server. Skills are described as packages with "progressive disclosure and on-demand loading," plus install, create and package support, and the README names a ClawHub ecosystem as the distribution channel. Progressive disclosure implies the agent sees skill metadata first and loads full instructions only when relevant, which keeps context small when you have many skills installed. The practical difference: an MCP server is code you run, a Skill is content the model reads. The README does not document the Skill manifest format or the ClawHub publishing flow, so packaging your own skill is a source-reading exercise.
The remote gateway, and where it stops being local-first
Deploying the Go gateway turns the desktop app into a remotely controlled agent. The README says a WebUI lets you control the local agent from any browser, and that a "bounded seq window replays short outages, with desktop-side persistence as the safety net." That is a specific design decision worth understanding: the gateway does not guarantee delivery of every message after a long disconnect, it replays a bounded window and relies on what the desktop persisted. For a short network blip you lose nothing. For a laptop that slept for an hour, you should expect to reconcile state yourself. This is also the feature that changes the threat model. A local agent with Bash access is a local risk. The same agent behind a gateway reachable from a browser is a network-exposed risk, and the README does not describe authentication, TLS termination, or binding defaults for the gateway. Treat that as the single largest unknown in the project.
How it compares to a terminal agent like Claude Code
The obvious alternative is a command-line coding agent such as Claude Code, which the repository's own topics list. The difference is where the agent loop lives. A terminal agent runs inside your shell session, inherits your environment and your current directory, and outputs text you can pipe. LiveAgent runs a persistent GUI process with its own memory store, its own scheduled task runner, and an optional network gateway, and it targets multiple model protocols (Claude, Codex, Gemini) behind one interface with custom Base URL support. If your work is one repository and one terminal, the terminal agent is the smaller tool and the better fit. LiveAgent earns its place when you want scheduled background jobs, cross-session memory, parallel sub-agents with worktree isolation, and browser access to the same agent from a second machine. The trade is a much larger attack surface and a much larger configuration surface, and only one of those is documented.
Licence, maintenance and what to check before you commit
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive and carries no copyleft obligation on your own code, though it also means no warranty, and the sponsor and relay-provider links in the README are commercial relationships rather than governance. The release cadence visible in the supplied data is three releases in ten days (v1.3.0 on 2026-09-01, v1.3.1 on 2026-09-05, v1.3.2 on 2026-09-10), which suggests active development and also suggests the README will drift from the shipped behaviour between releases. There is no homepage listed, so the repository and its docs/ directory are the only reference. If you deploy the gateway, pin the gateway version alongside the desktop version, because a WebSocket plus Protobuf protocol between two independently released components is exactly the kind of interface that breaks silently on a partial upgrade.
Editorial conclusion
Adopt LiveAgent if you want a desktop agent that edits files, runs Bash and manages long-running processes on your own machine, and you are comfortable reading source to fill the gaps the README leaves. Do not adopt it if you need a documented configuration reference, a stable plugin API contract, or an assurance that the Chinese-language community channels are optional. Before installing, verify three things in the repository: the exact tool names and permission prompts the agent uses, the config file path and key names for model routing, and whether the gateway's Protobuf schema is versioned. Everything else is a judgement call you can make after the first run.
Community notes