limecloud/lime: a GPLv3 Electron desktop agent that runs code, files and terminals in one thread

What problem Lime takes on, and who it is written for

Most agent tools stop at conversation. The README frames Lime against that: "Lime is more than a chat box: it understands context, calls tools, edits files, runs commands, organizes material, creates deliverables, and keeps moving a task forward from one desktop workspace." The problem it addresses is task continuity. A coding task usually spans reading a repository, tracing a call path, editing several files, running tests and explaining the diff. Lime's claim is that all of those steps stay inside one traceable chain rather than being scattered across a chat window, a terminal and an editor.

The audience is stated plainly in the README: developers who read code, change code, run tests and ship features; full-stack teams that mix product, design, data, documentation and automation; and researchers or creators who work with local material and need terminal access alongside content work. The repository topics back this up, listing agent, agent-collaboration, agent-harness, knowledge-base, research-tool and writing-tool together. That breadth is the point. It is also the first thing to be sceptical about, because a tool that claims engineering, research and content workflows has to earn each of them separately.

Thread, Turn and Item: how Lime structures a task

The README describes the execution model in four nouns: Thread, Turn, Item and reusable artifacts. Work is "projected" onto these so that a task "can be paused, reviewed, restored, and continued." That is a state model, not a chat history. A Turn is one pass of the agent loop; Items are the individual actions and results inside it, such as a file change, a command output or a tool result. Artifacts are the reusable outputs.

The loop itself is described in the README as context first, then a plan. Lime reads the goal, repository, files, history and constraints before proposing an executable plan, then acts within granted permissions: reading and writing files, searching, applying patches, running terminal commands, testing and calling tools. Approvals sit at the boundary. The README says you can approve risky actions, pause, revise the plan, or inspect uncommitted changes at any point.

The repository layout shows a layered implementation rather than a single process. There is an electron/ directory, a lime-rs/ directory with its own rust-toolchain.toml, a packages/ workspace declared in pnpm-workspace.yaml, and separate TypeScript configs for electron, renderer and node targets. The README's feature walkthrough mentions splitting a requirement across "the frontend, App Server, Rust runtime, protocol, and tests" and executing in dependency order. So the architecture is a TypeScript renderer and Electron main process talking to a Rust runtime, with the agent loop spanning both. The README does not document the protocol between those layers, so anyone evaluating the internals has to read the source.

Installing Lime and getting a first task moving

The README points to GitHub Releases as the distribution channel and lists macOS and Windows as the supported platforms, with Electron named as the desktop shell. The repository also carries a homebrew/ directory, which suggests a Homebrew path exists, but the README does not spell out the tap name, so treat that as something to confirm in the repository rather than assume.

For a source build, the toolchain is pinned in package.json: pnpm 9.15.9 as packageManager and Node >=22.0.0 in engines. The workspace is declared as packages/*. A source checkout starts like this:

corepack enable
pnpm install

corepack reads the packageManager field and gives you the pinned pnpm, so the install does not depend on whichever pnpm you happen to have globally. After that, the scripts in package.json are the entry point; the file is long and truncated in the repository listing, so run pnpm run to list what is actually available in the version you checked out rather than guessing a dev script name.

The repository also ships a Makefile dedicated to test layers. If you want to confirm the checkout is healthy before trusting the agent with a repository, the frontend unit layer is the cheapest gate:

make tdd

The Makefile help text describes make tdd as "Run frontend unit tests for local/AI TDD", and it delegates to test-unit. To run a single file, the Makefile requires an explicit FILE argument:

make tdd-file FILE=scripts/run-vitest-layer.unit.test.mjs

For the Rust side, make tdd-rust runs the layer budget guard and the Rust unit layer, and make tdd-rust-filter takes a FILTER argument. The help text gives the shape of it:

make tdd-rust-filter FILTER=workspace_support::tests::sa

The first real use is described in the README as pointing Lime at a repository and an error. The agent reads the relevant files and configuration, traces the call path, states its assumptions, changes the implementation, runs focused tests and shows the diff. You then stay in the same Thread to ask why the change was made or what the edge cases are. That last part is the actual differentiator: the review happens against the same state the agent acted on, not against a summary written afterwards.

Where Lime is the wrong tool

Lime is a desktop application. The README describes it as an open-source full-stack desktop AI agent and the badges mark it as Electron on macOS and Windows. Nothing in the README describes a headless server mode, a CI runner or a Linux build. If your agent work happens in a pipeline, on a build machine, or on Linux, this is not the tool for that job.

There is a second boundary around trust. Lime runs terminal commands and writes files. The README frames this as acting "within granted permissions" and asks you to approve risky actions, which means the safety story depends on the permission configuration you set up, not on a sandbox described in the documentation. The README does not document a container or VM isolation layer for command execution. On a machine with credentials in the environment, that distinction matters, and it is something to verify in the source before running the agent against anything you care about.

The licence is a third boundary. package.json declares "license": "GPL-3.0-only", and the README badge says GPLv3. That is a copyleft licence. If you plan to embed Lime in a distributed product, or ship a modified build, the obligations follow the code. This is not a reason to avoid it for internal use or for personal work, but it is a reason to read the licence before a commercial distribution decision, and nothing here is legal advice.

Provider choice, MCP and Skills versus a fixed-model CLI agent

The README positions Lime in the same category as Claude Code, WorkBuddy and Codex, and then names the differences: a desktop GUI, a visual workspace, configurable providers, and mixed engineering, research and content workflows. The provider point is the sharpest one. The README states that Lime "does not lock you to one model service" and that you configure providers, models and credentials, then extend the agent through MCP, Skills and controlled tools. The README also mentions managing capability catalogs, credentials, routing, retries and failure boundaries.

That is a real architectural difference from a CLI coding agent bound to a single vendor's models. It also moves work onto you. Routing and retry behaviour are configuration you own, and the README does not document defaults for any of it. A CLI agent that ships with one provider has already made those decisions; Lime hands them back.

Skills are the second extension point. The README describes encoding a recurring check, release step, research method or team rule as a Skill, which the agent can then discover and run through MCP or controlled capabilities instead of repeating the instruction in every prompt. That is a meaningful difference from prompt templates: a Skill is a reusable execution unit, and the README treats it as part of the capability surface rather than as text.

Multi-agent delegation is the third. The README describes splitting subtasks across agents for research, implementation, testing and documentation, while the main Thread keeps shared context, permissions and review boundaries. The repository's agent-collaboration topic confirms this is a first-class concern. The README does not document how conflicts between parallel agents are resolved, which is the obvious question to ask before relying on it for large changes.

Maintenance, releases and the upgrade cost you are signing up for

Lime is not archived, and the last push was on 2026-09-08. The release history is dense: v1.142.0 on 2026-09-08, v1.141.0 on 2026-09-06, and v1.140.0 on 2026-09-04. Three minor releases in five days is a fast cadence, and package.json sits at version 1.144.1, ahead of the newest release listed. That gap is worth noting: the version in the repository and the version in the newest published release do not match, so pin to a release tag if you need reproducibility.

A cadence like that has a cost. Minor versions arriving every couple of days means the surface you depend on, including provider configuration and Skill definitions, can move without a major-version signal. For a desktop app you launch yourself, upgrading is a download. For a team standardising on it, the upgrade path is the thing to plan, and the README does not document a migration or rollback procedure for configuration between versions.

The engineering discipline visible in the repository is unusually explicit. There is a governance/ directory, and package.json exposes scripts such as governance:file-size, governance:scripts, governance:architecture-confirmation, governance:modality-contracts and governance:desktop-reference-boundary. The Makefile separates frontend and Rust test layers and includes budget guards, with make test-layer-budget described as guarding "against new component VM migration candidates" and make test-rust-layer-budget guarding Rust e2e tests from the default TDD path. Those guards are a signal that the maintainers are managing growth deliberately. They are also a signal that contributing has a process attached, which raises the cost of a fork.

On licence, GPL-3.0-only governs the code. Using Lime internally, or modifying it for your own use, sits comfortably inside that. Distributing a modified desktop build is where the copyleft obligations become a decision rather than a detail.

Multimodal and content work: the part that is hardest to verify

The README lists multimodal understanding and generation as a core capability: text, code, images, screenshots, audio, video, PDFs, tables and structured data in one task, with output in the form of images, audio, video, documents and charts. The content workflow is described as taking web pages, references, screenshots, meeting records and prior results, structuring them, identifying gaps, and producing a report, script, plan or launch draft.

This is where the breadth claim does the most work and where the documentation gives the least. The README does not name the models or services behind image, audio or video generation, and it does not describe how those outputs are stored as artifacts. Given that provider configuration is user-supplied, the practical quality of multimodal output likely depends on which providers you connect rather than on Lime itself. The orchestration is Lime's contribution; the generation is not.

A reasonable way to read the positioning: Lime is strongest where a task crosses boundaries, such as a bug fix that also needs a written explanation, or research that ends in a document. It is weakest as a claim about any single modality in isolation, because for those the underlying model does the work and the README does not document which ones are wired up by default.

Editorial conclusion

Adopt Lime if you want a desktop GUI agent that can edit files, run terminal commands and keep a reviewable Thread, and you accept GPL-3.0-only terms plus a Node 22 and pnpm 9.15.9 toolchain. Skip it if you need a headless CLI agent that runs in CI, or if you cannot take a copyleft licence into your product. Before you commit, verify that the release you download matches the v1.144.1 version in package.json, check the licence obligations against your distribution model, and confirm the permission model around terminal commands on the machine you intend to run it on.

Frequently asked questions

Official sources

1. Issues
2. limecloud/lime on GitHub
3. Project website
4. README
5. Releases