AiderDesk: an Electron orchestration layer wrapped around the Aider CLI

What changed when the project stopped being a GUI

The repository description is one line long, a platform for AI-powered software engineers, which undersells it. The README's own framing is more honest: AiderDesk started as a graphical interface for the Aider CLI and evolved into an orchestration layer aimed at engineers who would rather not trade control for convenience.

That evolution is visible in the release history. v0.83.0, published on 2026-09-14, made terminal sessions persist across task and project switches with full output replay and automatic restart after exit. v0.82.0 a week earlier added a branch management UI, a confirmation dialog listing exactly which commits a push will send, opt-in force push, a choice of pull strategy for diverged branches, and a Resolve with AI action for failed operations. v0.81.0 on 2026-08-31 added nested subtasks so work can be broken into a hierarchy rather than a flat list, the `/skill:` command, SSH cloning, and install counts in the extensions gallery.

Three weekly releases in three weeks is the signal worth noting here. This is not a finished product being polished, it is an interface being pulled toward a feature set, and the version numbers reflect that: the newest tag is v0.83.0 while the manifest in the repository already reads 0.84.0-dev.

The technical shape is a substantial TypeScript and Electron codebase. The tree carries multiple tsconfig files split by target, separate Vite configs for the renderer and the server, Vitest configs for both, an `e2e/` directory, Husky hooks, and a `packages/` workspace holding the MCP server, the extensions package and a tree-sitter utility.

Git worktrees as the isolation primitive

The design decision that does the most work is the choice to make a git worktree the unit of a task. Each task gets its own directory, so an agent can refactor, experiment or rewrite freely without touching the branch you have checked out locally. When the work is worth keeping, you review the diffs and merge the worktree branch back through a built-in merge flow.

That is a real architectural commitment rather than a feature checkbox. The v0.82.0 notes add checkoutless merge and squash for worktrees, so work can be folded into a target branch without checking it out at all. Combined with automatic upstream setup on first push and per-branch UI operations for list, create, checkout, rename and delete, it turns the worktree from a plumbing trick into the primary object the interface manipulates.

Task management sits on top of the same idea. Projects are repositories, tasks are features or bugs inside them, and since v0.81.0 subtasks nest, so a large piece of work becomes a tree in the sidebar. Tasks can be duplicated or forked to explore an alternative path without destroying the original conversation, which is the feature people who get stuck in bad context loops will use most.

Deleting individual messages from chat history is the other half of that escape hatch. It is a blunt instrument by design, and it is exactly what you want when a wrong assumption early in a conversation has poisoned everything after it.

Approval gates, diff review and the token you can see

The three stated principles are transparency, control and flexibility, and they map onto specific mechanisms rather than slogans. Transparency means seeing every token, every context file and every proposed change before it lands. Control means the AI behaves like a junior pair programmer rather than an autopilot: you approve tools, authorize destructive actions, fork tasks and edit history. Flexibility means your IDE, terminal and git workflow survive the arrival.

Concretely, review happens through a diff viewer with side-by-side and unified modes for line-by-line inspection, and approval gates can require human authorization before the agent runs a shell command or touches a file. Since v0.83.0, bash tool calls can carry an optional description rendered in the tool message, which addresses a genuine legibility problem when a model reaches for the shell for something whose purpose is not obvious from the command alone.

Context selection gets similar attention. The context engine uses vector embeddings through LanceDB plus repository mapping so the agent loads the files it needs instead of dumping the tree into the window. Semantic search across the codebase is the default mode, and you can pin documentation URLs and code symbols to force attention onto something specific.

Model choice is wide. The README names OpenAI, Anthropic, Gemini, DeepSeek and Ollama, plus more than 25 other providers. Subagents let you define profiles with their own system prompts and boundaries, with a strict refactor agent and a UI or UX expert given as examples. That separation of concerns is what makes the orchestration framing credible rather than decorative.

Extension hooks, MCP servers and skills

Three extension paths exist, and they sit at different layers. Extensions are TypeScript code that runs inside the platform. They can intercept lifecycle events, of which the README names `onTaskCreated`, `onPromptFinished`, `onToolCalled` and `onFileAdded` among more than thirty, which is how you enforce a project-specific linter on every prompt the agent finishes. They can expose new callable tools to the model, such as one that triggers an internal CI or CD pipeline. And they can inject React components, including sidebar panels and live-preview renderers inside the chat itself.

Installation from the command line is one call:

npx @aiderdesk/extensions install

Model Context Protocol support is the second path, and it goes both directions. As a client, AiderDesk connects to any standard MCP server, which is how you give the assistant scoped access to Jira, Linear, an internal wiki or a database. As a server, it exposes itself as an MCP endpoint, so Claude Desktop or Cursor can drive a session running in the app.

Custom commands and Skills are the third. Project shell commands, linters and test suites can be injected into the agent's toolkit so it verifies its own output before reporting back. Skills load on demand with progressive disclosure, which keeps token cost down for large bodies of reusable expertise.

One structural detail in the manifest is worth flagging for anyone planning to run the server headless. A `build:mcp-server` script targets the `packages/mcp-server` workspace separately from the desktop app, and `publish:mcp-server` publishes it independently, so the MCP surface can exist without the Electron binary.

Running the app, and building it from source

The documented install path is short by design: download the latest release for your operating system and run the executable. npm, Docker, Homebrew and Scoop are listed in the installation guide on the documentation site rather than in the README, which is where you go if you would rather not click a download.

Building from source needs more than Node. The `postinstall` script runs `electron-builder install-app-deps`, downloads a probe binary through `scripts/download-probe.mjs`, applies patches with patch-package, and builds the extensions package, which is why a fresh clone takes a while before it will start. Development is the usual pair:

npm run dev
npm run build

Docker is the more interesting route, because the image has to carry a Python runtime for the Aider connector. The build stage installs Python and build-essential on a node:24-slim base, then compiles native modules and patches dependencies before the server is built:

FROM node:24-slim AS builder
WORKDIR /app
RUN npm ci --ignore-scripts
RUN npx patch-package
RUN npm run build:extensions
RUN node scripts/download-probe.mjs

Two things in that file are more than routine. A build argument for PostHog's public API key is passed through the server build, so the image can be built with or without telemetry wiring. And a node script strips the `postinstall` hook out of `package.json` at image build time, with a TODO explaining it as a temporary measure until the project moves to a monorepo layout. That is a good indicator of how actively the build is being reworked.

Native modules are a real part of the picture. node-pty needs compilation, which is why build-essential and Python appear in both stages, and why the production image installs Python 3.12 from the deadsnakes PPA rather than relying on the distribution default.

Editorial conclusion

AiderDesk earns its keep when your AI sessions are long enough that losing thread state costs you more than the UI overhead costs you, and when several worktrees on one repository are normal rather than exotic. Skip it if a terminal and a config file already cover your workflow, since the added value is approval surface and history editing rather than better code generation. The last release recorded is v0.83.0 from 2026-09-14 while `package.json` carries 0.84.0-dev, so expect a moving main branch. The last push was on 2026-09-20, and the licence is Apache-2.0, which matters if you plan to ship an internal extension.

Frequently asked questions

Official sources

1. hotovo/aider-desk on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases