PI-Desktop: an Electron and Rust shell for coding agents you point at your own model
Local-first AI coding agent desktop: Electron + Rust host core + pi Agent Harness + user-installable plugins
At a glance
- What is it?
- PI-Desktop puts an agent workspace on the desktop instead of inside an editor or terminal, with a Rust host core, a permission layer over privileged actions, and plugins users install themselves. It is Early Preview software, and the README says so before anything else.
- Who is it for?
- Adopt PI-Desktop if your agent workflow keeps colliding with an editor or terminal boundary, you want to point sessions at OpenAI, Anthropic, an OpenAI-compatible endpoint, or a local gateway such as Ollama or LM Studio, and you accept that the README labels this Early Preview with extension interfaces still moving. Do not adopt it if you need a frozen plugin API, an audited security posture, or a tool whose release cadence you can predict.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- 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 problem is where coding agents live, not what they can do
Most coding agents run inside a terminal, an editor extension, or a hosted service. That placement decides a lot: which repository you can open, how many sessions you can keep alive, what happens when you switch editors, and who holds your credentials. PI-Desktop takes the position that the agent deserves its own window. Projects, conversations, reviews, files, previews, notifications, and extensions sit in one workspace, and the README states plainly that there is no PI-Desktop account, no mandatory relay, and no editor lock-in. The intended user is someone already running an agent loop against real repositories who is tired of the surrounding tooling constraining the loop. It is not aimed at someone who wants a hosted service with a billing page, and it is not aimed at someone who wants the agent embedded in the editor they already use.
Electron shell, Rust host core, and a permission layer between the agent and your machine
The repository description names the stack: Electron for the desktop shell, a Rust host core, the pi Agent Harness, and user-installable plugins, with TypeScript as the primary language. The README describes the behavioural consequence rather than the internals: agents can read files, edit code, and run commands, but privileged actions pass through PI-Desktop's permission layer, so you review diffs and inspect command output and decide how much autonomy each session gets. Three modes change where the gate sits. Agent is the default loop and adds no approval step. Plan makes the agent research first and produce what the README calls an immutable implementation plan, and execution does not start until you sign off. Goal locks the objective and acceptance criteria, then the agent picks the route. In all three, the README says privileged tools still go through the permission layer. Subagents are the other structural piece: independent work such as codebase exploration, multi-file implementation, research, test analysis, or adversarial review runs in its own context and reports back to the parent agent. That is a context-window argument, and it is the most concrete design claim in the material.
Installing it and pointing it at a model
Distribution is through GitHub releases, and the README links the latest release build for macOS, Windows, and Linux. There is no package-manager instruction in the supplied material, so treat the releases page as the install path. Configuration starts in Settings, then Model configuration, where you choose a provider or a compatible API and add credentials. Supported targets listed in the README include OpenAI and Anthropic, OpenAI-compatible APIs, hosted model gateways, local gateways such as Ollama and LM Studio, multiple models under the same provider, and provider OAuth accounts where supported. Model configuration can carry context windows, output limits, reasoning controls, temperature, and other model-specific behavior, and you can switch models from the Composer without recreating the session. The README does not spell out the individual config keys, so the exact field names have to come from the documentation site at pi-docs.aiuo.net rather than from this article. Likewise, the plugin, skill, MCP server, and subagent formats are described by category, not by schema.
Early Preview is a real constraint, and the release channel shows it
The README carries an Early Preview notice stating that APIs, extension interfaces, and some desktop behaviors may continue to evolve. The release history backs that up: v0.14.6 shipped on 2026-09-10, but so did v0.14.6-rc.6 and v0.14.6-rc.5, hours apart. A project publishing release candidates on the same day as the stable tag is iterating quickly, and anyone building a plugin against the extension interface should assume breakage between versions. The second limitation is quieter. A permission layer that gates privileged actions is only as good as its coverage, and nothing in the supplied material enumerates which actions are gated, how the gate is configured, or what happens when a plugin contributes its own tools and commands. Plugins can add tools, commands, panels, themes, services, skills, and new workspace experiences, per the README, which means the trust boundary extends to whatever you install. If you need a reviewed security model before letting an agent touch a production repository, this is the wrong tool today. If your work is a scratch checkout on a laptop, the trade is easier to accept.
How it differs from an editor-integrated agent
The closest comparison is an agent that lives inside your editor, since that is the arrangement PI-Desktop is arguing against. The difference is not model quality or tool count; it is the boundary. An editor-integrated agent inherits the editor's project model, its extension host, and its session lifetime, so the agent stops when the editor stops and the workspace is whatever the editor has open. PI-Desktop inverts that: the workspace is primary, projects and sessions are managed inside it, and the editor is something you open alongside. The README's specific claims that follow from this are session branching, pinning and archiving conversations, queueing prompts while an agent is running, `@` file references, slash commands, application-wide search, and streaming responses checkpointed so interrupted work can survive restarts or runtime failures whenever possible. That last phrase, whenever possible, is the project's own hedge and worth reading literally. If your entire workflow is one repository and one editor and you never context-switch, the standalone workspace buys you little and costs you a second application to keep current.
Licence and the cost of keeping up
PI-Desktop is LGPL-3.0. For most people installing a desktop build, that is a reading exercise rather than an obligation. It matters if you fork the application, ship a modified build, or link the covered libraries into your own product, because LGPL-3.0 carries conditions that MIT and Apache-2.0 do not. This is not legal advice; read the LICENSE file in the repository and get your own answer if you plan to redistribute. On maintenance: the release cadence visible in the material is fast, with release candidates arriving the same day as stable tags, and the README warns that extension interfaces may change. Budget for re-testing your plugins and skills after upgrades rather than assuming a version bump is inert. The upgrade path itself is the standard one for a desktop app distributed through GitHub releases, and the supplied material does not describe an in-app updater, so plan on downloading builds.
Who this fits, and what to check before you commit
PI-Desktop is a reasonable fit if you already run agent loops across more than one repository, you want to choose the model per session including a local gateway, and you value seeing diffs and command output in a dedicated surface rather than a scrolling terminal. It is a poor fit if you need a stable plugin API, if your organization requires a documented security review before an agent can run commands, or if you want the agent to stay inside the editor you already have open. Two things to verify before you invest time. First, read the Model configuration documentation at pi-docs.aiuo.net and confirm your provider is supported the way you expect, particularly if you rely on a hosted gateway or provider OAuth. Second, check the releases page and pick a stable tag rather than an rc build, since v0.14.6 and its release candidates landed within hours of each other. If you write plugins, wait for the extension interface to settle; the README's own Early Preview notice is the signal, and it is the only signal you need.
Editorial conclusion
Adopt PI-Desktop if your agent workflow keeps colliding with an editor or terminal boundary, you want to point sessions at OpenAI, Anthropic, an OpenAI-compatible endpoint, or a local gateway such as Ollama or LM Studio, and you accept that the README labels this Early Preview with extension interfaces still moving. Do not adopt it if you need a frozen plugin API, an audited security posture, or a tool whose release cadence you can predict. Before installing, read the Settings, Model configuration documentation for the exact provider fields, check the LICENSE file for what LGPL-3.0 means for your distribution model, and confirm on the releases page which v0.14.6 build is stable rather than a release candidate.
Community notes