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.

The app updates itself from the release feed once installed.

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

Code-signing certificates are not yet configured in the release pipeline, so your OS will warn you. This is expected, and worth knowing before you assume the download is broken:

• 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
  

Rather than ask you to take 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 Limboo-1.5.1.AppImage --repo limboo-ai/limboo  # provenance

Signed builds are the next release-engineering task. 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. Beneath it sits a provider-neutral OS-level sandbox whose non-negotiable floor keeps your secrets store, database, and settings unreadable no matter what the agent is told to do. Two agents, one set of rules you actually wrote.

The UI never knows which agent is running. Providers sit behind a narrow adapter seam: executable detection, run invocation, wire-format translation, permission mapping, resume tokens. Everything above it — the timeline, approvals, plans, memory, search, worktrees — is provider-neutral by construction. Adding an agent is writing an adapter, not forking the app.

Why this isn't another Claude Code or Codex clone

A clone reimplements the parts that are already excellent: the agent loop, the tool protocol, the chat.

Limboo deliberately owns none of them. It has no model, no agent loop, and no inference of its own. It doesn't hold your API keys — each agent authenticates itself, exactly as it does in your terminal. Run the CLI directly tomorrow and it still works; nothing here is a lock-in layer.

What Limboo owns is everything the agent isn't responsible for and every agent needs: the repository's state across time, durable knowledge that isn't a vendor's, a permission model with an OS-level floor, isolated execution roots, and the translation that makes those work for more than one provider.

The distinction in one line: wrapper-style tools make the agent easier to look at; Limboo makes the world the agent acts in durable, verifiable, and yours.

And it is local-first by construction. There is no backend, no telemetry, and no cloud sync. The only network traffic is the agent talking to its own provider. The project, its history, and its memory stay on your machine.

Key features

• Session-centric workspace — repo + branch + chat + agent + terminal + checkpoints + memory, all in one place.
• **Two agents, o