PI-Desktop: an Electron and Rust agent workspace that is still on beta tags

Despite the name, this is an AI agent desktop and has no connection to Raspberry Pi

Many people who look for pi desktop are after Raspberry Pi desktop environments, remote access or an OS install. PI-Desktop is something else. The repository describes it as a local-first AI coding agent desktop built from Electron, a Rust host core, the pi Agent Harness and user-installable plugins. The README calls it a modular desktop workspace for AI agents, available for macOS, Windows and Linux.

If you arrived wanting to set up a Raspberry Pi display, nothing in this repository helps. If you arrived wanting a place where coding agents keep their projects, sessions, reviews and previews, read on. The project's own framing is that terminal agents are good at execution and IDE agents are good at living inside an editor, and that PI-Desktop gives agents a persistent workspace independent of either.

The release line is an early preview, and the tags are moving by the day

The README carries a banner that says the current release line is 0.21.x, Early Preview. The root package.json and the Cargo workspace both say version 0.21.0. Meanwhile the newest tags are v0.22.0-beta.1 on 2026-10-26, v0.22.0-beta.2 on 2026-10-28 and v0.22.0-beta.3 on 2026-11-01, three betas in about a week. The last push to the repository was on 2026-11-02, and it is not archived.

The practical consequence is churn. A beta every two to three days means behavior can change between the build you install and the one you update to. The banner and the tags also disagree about which line is current, so check which one a download link points to. Do not build a team workflow on top of it until you have settled on a tagged build, and keep project data under version control so a bad update cannot take work with it.

Plugins can register eleven kinds of capability, from tools to resident services

The project keeps its Core small and assembles the real workflow through plugins. The README lists eleven capabilities: Command, Panel, Floating Widget, Work Panel View, Agent Tool, Completion, Skill, Theme, MCP Server, Service and Message Bus. They are grouped into three layers. Agent extensions cover tools, skills, completion and pi extensions. Workspace extensions cover commands, panels, work panel views, floating widgets and themes. Platform extensions cover MCP servers, resident services and a plugin message bus.

The README sketches plugins that are whole products, such as a Voice Agent with a floating widget, a speech service, an agent tool and commands, or a GitHub Workspace with a work panel, an MCP server, agent tools and a background service. Plugins ship as .piplug packages or through the marketplace. A Service is persistent background work, and a Completion plugin uses the models you already configured. That makes a plugin far more powerful than a prompt snippet, so read what a package registers before you install it from anyone you do not know.

Agent, Plan and Goal are three different levels of autonomy

PI-Desktop offers three ways to work. In Agent mode you give a task and the agent reads code, edits files, runs commands, tests and iterates, which the README recommends for day-to-day development. In Plan mode the agent studies the project first and produces an implementation plan for you to review, which the README suggests for refactors and high-risk changes. In Goal mode you lock the objective and acceptance criteria and let the agent drive the execution, aimed at complex and long-running tasks.

The README adds that privileged operations still pass through PI-Desktop's permission layer, in every mode. So Goal mode does not mean unrestricted. The cost of Goal mode is that you hand over the path, so the quality of your acceptance criteria decides whether the result is useful. Start with Plan on anything that touches many files, and keep Goal for tasks where a wrong turn is cheap to undo.

Subagents share a parent, Worker Sessions stand alone

The project has two levels of delegation. Subagents are background agents for independent work such as code exploration, implementation, test analysis, research and review. Each gets its own context and reports back to the parent agent.

The Session Orchestrator is the heavier option. A main session delegates to full Worker Sessions, and the README's example splits work into frontend, backend, tests and review workers. A worker is a full PI-Desktop session with independent context, independent execution, a full transcript, and the ability to be inspected directly and reused. The difference matters when something goes wrong. A subagent's work reaches you as a report, while a worker leaves a transcript you can open and read. Use subagents for quick fan-out and workers when you want to audit how a result was reached. The README does not say how many workers can run at once, so test your own machine before assuming parallelism will scale.

Building from source needs Node 22.19, pnpm and a Rust toolchain

The root package.json names [email protected] as the package manager and sets engines to node >=22.19.0 and pnpm >=10. It is a pnpm workspace plus a Cargo workspace whose only member is crates/host-core, licensed LGPL-3.0-or-later. The scripts split the work: build runs the JavaScript packages and then the host core, build:js covers only the packages, and build:host covers only the Rust side. The Rust parts use these commands:

cargo build --release -p host-core
cargo test -p host-core

The dev script starts the desktop package through pnpm filtering, and pack and dist package it. Tests run build:js, then the package tests, then cargo test for host-core. The end-to-end smoke script reads three variables from .env.example, PI_DESKTOP_TEST_BASE_URL, PI_DESKTOP_TEST_MODEL and PI_DESKTOP_TEST_API_KEY, and the file warns you never to commit real keys. If you only want to use the app, skip all of this and download a build from the releases page.

Local-first covers your projects, but a cloud model still sees what you send it

The tagline is that your projects stay local, your models stay replaceable and your workspace stays yours. The model freedom section says you can use cloud models, local models, custom gateways and compatible APIs, and switch without rebuilding the workflow.

Those two ideas fit together, but they are not the same thing. The projects and sessions live in the desktop app. Whatever prompt and file content you send to a hosted model goes to that provider, so choosing a cloud model reintroduces the usual data-sharing questions. If you need nothing to leave the machine, pair it with a local model and check that your plugins do not call out. The project is also LGPL-3.0, which allows linking from other code under conditions, so a company embedding or modifying it should have someone read the licence text. Documentation is hosted at pi-docs.aiuo.net, and the plugin guide is in docs/plugin-development.md.

Editorial conclusion

Try PI-Desktop if you want a plugin-driven desktop workspace for coding agents and can live with beta builds, a Node 22.19 plus Rust toolchain if you build from source, and an LGPL-3.0 licence. Skip it for production workflows that need a stable release line, and do not confuse it with Raspberry Pi desktop software, which it has nothing to do with.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. vastsa/PI-Desktop on GitHub