PI-Desktop: The Open-Source Desktop Where AI Agents Get Their Own Workspace

Your coding agent lives in a terminal, or in a sidebar of an IDE, or in a browser tab that dies when you close it. PI-Desktop makes a different bet: give AI agents a persistent, independent, extensible desktop of their own. It is a local-first, model-agnostic workspace - 4,949 stars and 412 forks, LGPL-3.0 licensed, with builds for macOS, Windows, and Linux - where projects, sessions, reviews, previews, and multiple cooperating agents live in one environment that survives app restarts. The repository describes itself as neither a wrapper around one model nor another IDE extension, and the source tree backs that up: an Electron desktop shell, a Rust host core that owns sessions, permissions, and state, a TypeScript agent layer, and a plugin platform with its own SDK, devkit, and wire protocol. In this tour we walk the actual architecture, then show how to go from download to a working multi-agent workspace. It pairs naturally with the other pieces of the agent stack we have covered recently - frameworks that build apps around agents and shared memory across agent CLIs - but PI-Desktop is the piece you actually sit in front of.

Why You Need This

Chat threads are disposable; real work is not. PI-Desktop is organized around Project, Session, Agent, and Work instead of the ephemeral conversation, and that single decision changes what an agent tool can be. Sessions are pinned, archived, branched, and searched; you can queue prompts while an agent is already running; reference project files with an @-mention; review diffs; inspect command output; and keep streaming checkpoints so interrupted work is recoverable. A session continues across app launches. On top of that persistence sits orchestration: one main session can spawn Worker sessions for frontend, backend, tests, and review, each a full PI-Desktop session with independent context and a complete transcript, directly inspectable rather than a black box. And because it is local-first - projects, sessions, settings, and logs stay on your machine, API credentials go in the OS keychain, there is no telemetry and no mandatory account or relay, and model requests go directly to your configured provider - it answers the trust question that cloud agent platforms keep dodging. For developers who want agents as infrastructure rather than a chat toy, this is the missing desktop layer.

How It Works

The repository is a pnpm monorepo plus a Cargo workspace, and its layers map cleanly onto the diagram below.

The shell is apps/desktop, an Electron application built with electron-vite, which launches apps/pi-host - the TypeScript host process that drives crates/host-core, the Rust heart of the system. The UI talks to the host over the RACP protocol (packages/racp), a JSON-RPC layer with a WebSocket binding and typed host operations, which lands on the core’s RPC bridge and dispatches into Rust. The host core owns everything durable: a local database for persistence, the sessions module that gives PI-Desktop its continuity, the plans module that anchors review-before-execution workflows to sessions, and the providers module through which every model call flows. Agent execution is split between packages/agent-host and packages/agent-runtime, where message handling, context compaction, speech, and image generation live; both sit on packages/host-runtime, the bridge package over the Rust core. Every tool request - file edits, shell commands, extensions - passes through the tools and permissions module with an allow, ask, or deny decision before execution, and the plugin runtime goes through the same gate.

The extension platform is the second product inside the product. The Rust plugin runtime loads plugins built against packages/plugin-sdk, which enforces filesystem and network policies and exposes the plugin message bus and MCP configuration; packages/plugin-devkit layers scaffolding and packaging on top for authors. A plugin can add commands, panels, floating widgets, work panel views, themes, agent tools, skills, model completions, MCP servers, resident background services, or talk to other plugins over the message bus - and plugins ship as .piplug packages or through a marketplace. Underneath, packages/i18n localizes the shell and packages/shared carries the common types, which is how the project ships a bilingual interface without forking the codebase.

Advantages

• Persistent sessions, disposable agents. The same session survives restarts, branches like a git history, and can be searched later - so an agent becomes a long-lived collaborator instead of a chat you screenshot.
• Parallel orchestration you can audit. Worker sessions run with independent context and full transcripts; delegation is inspectable, which is exactly what the multi-agent patterns we covered in the OpenAI incident analysis demand.
• Model freedom without workflow lock-in. OpenAI, Anthropic, OpenAI-compatible APIs, custom gateways, Ollama, LM Studio, or fully local models - configured per session with independent context window, output limit, reasoning effort, and temperature, switchable mid-session.
• Local-first by default. Your projects, sessions, and logs never leave the machine; credentials live in the OS keychain; model requests go straight to the provider.
• A real permission gate. Privileged operations route through an explicit allow, ask, or deny layer - including tools registered by plugins - so autonomy is a dial you set per session, not a promise.

Benefits

For developers, PI-Desktop is the difference between managing a pile of terminal tabs and running an agent workspace: one environment holds every project, each with its own session history, and importing existing sessions from Claude Code, Codex, OpenCode, or Pi means the switch does not orphan your history. For teams and tinkerers, the plugin platform turns the desktop into a product surface - the documentation’s own examples include a voice agent assembled from a floating widget, a speech service, an agent tool, and commands, plus GitHub and analytics workspaces - all distributable as .piplug packages. For the privacy-minded, the local-first table in the README is unusually specific and unusually honest: no mandatory cloud relay, no telemetry, keychain-stored secrets. And pragmatically, the distribution story is finished: signed and notarized macOS builds, Windows installer and portable, Linux AppImage, deb, and rpm - a 0.15.x early preview that already feels like a shipped product, which explains the 412 forks building on it.

Usage

Getting started is a download, not a build: grab the package for your platform from the releases page - dmg or zip on macOS (Apple Silicon and Intel), installer or portable on Windows x64, AppImage, deb, or rpm on Linux x64. The first-run flow is four steps: install PI-Desktop, connect a model provider, open a local project, and pick a work mode. The three modes are worth understanding before you start:

• Agent - give it a task and let it read, edit, run commands, test, and iterate. Best for day-to-day development.
• Plan - the agent studies the project and produces an implementation plan for your review before execution. Best for refactors and high-risk changes.
• Goal - define the outcome and let the agent choose the path. Best when you care about the destination, not the route.

Once running, the workflow tools are on the surface: @-reference project files in prompts, use slash commands, queue follow-up prompts while the agent works, and review diffs before accepting them. To go further, the plugin development guide walks through building your first extension against the SDK, and the documentation site covers provider configuration and session management in depth. If you already work with another coding agent, import its local sessions first - then the new desktop starts with your history intact.

Conclusion

PI-Desktop is what happens when someone takes agent tooling seriously as a desktop platform problem rather than a chat problem. The Rust host core gives it durability and speed, the RACP protocol gives the UI an honest boundary to the host, persistent sessions give agents continuity across days and machines, and the plugin system gives the community room to make it theirs. It is early - a 0.15.x preview - but the architecture underneath is the durable kind, the local-first posture is exactly where sentiment is heading, and the multi-agent orchestration is already inspectable end to end. Download it, connect a local model, and open your current project: the desktop stops being where your agent lives and becomes what your agent works in.

Enjoyed this post? Never miss out on future posts by following us