Limboo

The operating system for AI software development.

A local-first desktop workspace that gives a coding agent everything it needs to do real engineering: projects, sessions, file watching, repository indexing, git, worktrees, terminals, memory, search, permissions, and context. Limboo is not an AI model, and it is not an agent. It is the environment around one — and it works with more than one.

Download · Why it exists · Documentation · Architecture · Contributing · Roadmap · Security

What is Limboo?

Limboo is a desktop application (Electron + React + TypeScript) that acts as the workspace around a coding agent. The agent already understands programming, debugging, planning, and git. Limboo provides the environment where it can perform at its highest level: it manages the repository, watches the filesystem, runs the terminal, owns the database, holds durable project memory, and enforces a strict security boundary, while the agent focuses exclusively on writing software.

It works with more than one agent. Claude (through the Claude Agent SDK) and Cursor (through the cursor-agent CLI) both run as first-class providers behind a narrow adapter seam — picking a model picks the provider, and everything above that seam behaves identically either way.

Every unit of work is a Session — a bundle of a repository, branch, chat history, agent, terminal history, checkpoints, permissions, context, memory, tasks, and generated files. Instead of opening many windows, everything lives inside one workspace.

Download

Installers for Windows, macOS, and Linux are published on every release, on both x64 and arm64. Every download below lives on the latest release.

The app updates itself from the release feed once installed — including the .deb, .rpm and .pacman builds, which apply updates through your system package manager and will ask for your password.

AppImage on Ubuntu 24.04+: AppImages need FUSE 2, which Ubuntu no longer installs by default. sudo apt install libfuse2t64 fixes dlopen(): error loading libfuse.so.2. It installs alongside FUSE 3 without replacing it.

These builds are unsigned — here's what you'll see

The signing pipeline is implemented (Developer ID + notarization for macOS, Authenticode for Windows, plus a Microsoft Store channel), but it is opt-in from credentials that are not yet configured — so published builds are currently unsigned and your OS will warn you. This is expected, not a broken download:

• Windows — SmartScreen says "Windows protected your PC." Choose More info → Run anyway.

• macOS — Gatekeeper refuses an app from an unidentified developer. Right-click the app → Open, or clear the quarantine flag:

  xattr -dr com.apple.quarantine /Applications/Limboo.app
  

  Being unsigned also means macOS cannot auto-update: Squirrel.Mac refuses to update an app whose signature it cannot verify. Limboo detects this and says so in Settings → Updates rather than offering a button that fails. Windows and Linux self-update normally.

• Linux — no code-signing mechanism exists for these formats. Integrity comes from the checksum manifest and build provenance below.

What each route buys once enabled, so the trade-offs are clear up front: a macOS Developer ID removes the Gatekeeper prompt and switches macOS auto-update on; a self-signed Windows certificate does not remove the SmartScreen warning (it chains to no trusted root) and only provides a stable publisher identity; the Microsoft Store is the warning-free Windows route that needs no certificate at all. See code signing.

Rather than ask you to take any of that on trust, every artifact ships with a checksum manifest and a build-provenance attestation recorded in a public transparency log:

sha256sum -c SHA256SUMS                                             # integrity
gh attestation verify <file> --repo limboo-ai/limboo                # provenance

Upgrading from v1.5.1 or earlier on macOS? Download the new .dmg once, manually. Those builds shipped an update archive Squirrel.Mac could not read, so they cannot auto-update to this release — the in-app updater will keep reporting a failure until you replace the app. Windows and Linux upgrade normally.

Prefer to build it yourself? See Quick start.

Why it exists

There is no shortage of ways to put a face on a coding agent. Most of them are genuinely good at what they set out to do: run several agents at once, show you the diffs, give each task its own branch, keep the transcripts tidy. If that is what you need, you are well served today.

Limboo starts from a different observation — one you have probably felt without naming it.

The agents reason brilliantly and remember the wrong things

Ask a coding agent to resume yesterday's task and it will pick up the conversation perfectly. It remembers what it decided, what it tried, what you told it to avoid. What it does not remember is the world that conversation was about.

Sessions persist the conversation, not the filesystem. In between, your teammate merged a refactor. A dependency went up a major version. Someone rebased the branch out from under the diff. The transcript is intact and now subtly fictional — and the agent argues confidently from it, because nothing told it otherwise. You spend the first few turns of every resumed session pushing it back to reality, and the worst cases are the ones where you don't notice.

This is not a flaw in the model's reasoning. It is a missing system. Nothing in the stack is responsible for the world the agent acts in.

Watching an agent is not the same as grounding it

The tooling that grew up around these agents solved a real and different problem: visibility. Boards, parallel sessions, isolated branches, inline review — they make many agents watchable. Limboo has most of that too, and none of it is what makes it worth building.

Because underneath the dashboards, the environment is still ambient. Whatever changed between turns remains the agent's problem to rediscover. Each provider keeps its own memory, its own permission model, its own configuration. Switch agents and you start over: the knowledge your last agent accumulated stays locked in that vendor's format, and the safety rules you carefully tuned apply to only one of them.

So Limboo makes the environment a system

The bet is simple: the environment deserves to be real infrastructure, owned by the app, with its own state — not a side effect of whichever agent happens to be running. Four consequences follow, and they are the actual product:

Sessions resume against verified repository reality. Reopen a session and Limboo revalidates the worktree against the exact state that session last saw, then computes a structured repository delta: commits landed, files changed with dependency manifests and migrations flagged, symbols added or removed, and which files import what moved. That delta is handed to the agent once, before your next prompt, so it reconciles up front instead of discovering the drift three tool calls in. Bounded, argv-only git; never blocks you from switching sessions.

The app owns the knowledge, so it outlives the agent. Durable project memory and the code-search index are platform services Limboo maintains — offline, in local SQLite with FTS5/BM25 ranking, no embeddings API. Both agents query the same memory and the same index through the same tools. Your project's accumulated knowledge is not a vendor's asset, and it survives switching models mid-project. Memory even links to repository symbols, so guidance whose code was deleted is automatically demoted until that code returns.

One authorization core, whichever agent is running. Every tool call — Claude's through the SDK callback, Cursor's through a per-run hooks bridge — enters the same decision function, with the same risk classes, the same path guards, and the same approval dialog