Lexora: a local-first desktop agent that keeps working on a goal

An agent that works on a goal, not a chat box

Lexora describes itself as a personal AI agent that self-evolves through real desktop practice, and it positions itself explicitly beyond model wrappers and coding copilots. The difference it claims is the unit of work. You state a goal, and Lexora arranges steps around it and keeps pushing forward on your desktop, and you can add requirements at any time and look at the results as it goes.

The examples the readme gives are ordinary working life rather than software tasks: organising reference material from work, repeatedly polishing something you are creating, and planning a trip. The claim is that text becomes the starting point for work, creation and daily life.

Two design decisions follow from that framing. The first is persistence. Conversations and execution records are kept in the task, so work you did not finish today continues when you open the application again, and the methods and tools you found convenient can be saved and reused. The second is that a task is a container of context rather than a single prompt.

The audience is a person on a desktop who wants the agent to operate the machine, not a developer who wants a completion in an editor. The topics on the repository cover desktop agents, local AI, agent loops, MCP, skills, multi-agent setups, Wayland, local-ai and even desktop pets, which is an unusual mixture and gives a fair sense of the project's ambitions.

Tasks hold context, and you can branch a conversation

The workspace model is what makes a long task workable, and there are three parts to it.

First, tasks, files and previews sit side by side, so you can look at the output and edit it in the same view, and multiple tasks keep their own separate context rather than sharing one confusing history.

Second, references. You can select content in a conversation, a file or a web page and attach it as the basis for the next request, so the follow up instruction has a source behind it. That is a small feature with a large effect on an agent that otherwise has to guess what you are talking about.

Third, branches. From an existing conversation you can try a different direction, and the branch canvas shows and continues each attempt while keeping them all. For an agent that writes and edits, trying a second version without losing the first is the difference between an experiment and a commitment.

Around that sit the management features. Tasks can be organised by project or topic, frequently used entries can be pinned, and existing tasks can be found again through search. You can also keep talking while the agent is working, either queueing the message or injecting it into the current execution, which matters when the agent is halfway through a step and you realise the requirement has changed.

Companions, NPC squads and a plugin system built around conversation

The multi-agent side is a first class feature rather than an experiment. The readme describes dispatching companions for a task, with Lexora orchestrating or a specific companion taking over, and it shows an illustration of a crew of companions dispatching further non-player companions as needed.

You can also build your own squad, setting the model, the action rules and the capabilities of each companion, and recruiting NPCs to help with subtasks. Since the model is a per-companion setting, a task can use a cheap model for mechanical work and a stronger one for the part that matters, and the readme lists free model choice as its own feature, with the ability to connect your own model service and pick per companion and per task.

The plugin system is the part that is unusual. You can install from a plugin marketplace, but you can also describe what you want in the conversation, and a companion generates the source code and the install package, you confirm the installation, and then you keep testing and editing it. The generated source stays in the task workspace, so you can maintain it yourself and share it.

Plugins can add standalone pages, split panels, widgets, full themes and window effects, menus and input commands, access to local files you approve, their own settings and private storage, agent instructions and dedicated tools for companions, and responses to task progress, scheduled command execution and system notifications. Plugins use the host's capabilities according to the permissions they declare, and a separate plugin source repository is linked for browsing examples.

Local first, spelled out as a table of destinations

The most valuable part of the readme is the section on data locality, because it makes specific claims a reader can check against their own threat model.

The opening statement is that Lexora does not package your whole project and upload it to the company's servers in the background, and that it does not open source your code on your behalf. Then the table breaks it down. Project files stay in your local directory and are read and written on the machine. Task records, companions and settings are stored locally, with backup and restore supported. API keys and login credentials are encrypted at rest using the encryption facilities the operating system provides. Model requests go from your machine to the model service you configured, and not through a Lexora cloud relay. External tool calls go to the MCP services you enabled or to the addresses a plugin has been permitted to reach. Remote backup, if you configure it, goes to a WebDAV or S3 destination you choose.

The readme is also honest about the consequence. When you use a remote model, the conversation, the referenced content, and any code or file content that a tool read and placed into the context are sent to that model service, and external tools receive the data their invocation needs. So the guarantee is about the vendor's own servers, not about your data staying on your disk. The plugin source repository is separate, which means third party plugins come with their own privacy posture, and a plugin with permission to reach an address can send data there.

Permissions, schedules and the tools you can plug in

The permission model is the one to read carefully before letting an agent near a filesystem.

Permissions are chosen per task, with four levels described: read only, human approval, smart approval, and full access. They can be adjusted while a task is running, and a task can be stopped. Human approval is the middle setting and the one most people will want on a first run, because it puts a human between the agent and any action that changes something.

Scheduled automation sits alongside that. For repeated tasks you set a time and a goal and then look at the records and results of each run. The constraint is stated plainly: scheduled commands need Lexora to be running and the computer to be awake. That rules out the unattended overnight job on a laptop that suspends, and it is a good reminder that this is a desktop application with a user session rather than a server.

Two extension mechanisms complete the picture. Skills let you save writing standards, research processes and project conventions as reusable working methods, which is the memory that survives a new task. MCP connects local or remote services so that existing tools can be brought into a task.

Two smaller features matter for trust. The change and execution records show what the tools did, what the commands returned and which file changes were recorded, and the usage statistics show token consumption per task and per model, so you can see where the quota went.

Installing it, and the stack behind the build

Getting started is short. You download an installer, connect a model service in the settings with an API key or an account authorisation as the provider requires, and then you create a task and give Lexora a goal, choosing a working directory when the task involves files. No Lexora account is required, and the application includes no model quota, since the terms and cost of the model service are the provider's.

The supported targets are listed in the readme: Windows, Ubuntu, Debian, Fedora and Arch Linux on x64 and ARM64, and macOS 15 or later on Apple Silicon. There is one extra step on macOS, where the guide asks you to run an xattr command once to clear the quarantine attribute on the first launch.

The source layout tells you what you are dealing with if you want to build it. The root package is a private pnpm workspace with a version of 0.14.0, the package manager pinned to pnpm 12.5.1, and engines requiring Node 26 or newer.

{
  "name": "@uselexora/lexora",
  "type": "module",
  "version": "0.14.0",
  "private": true,
  "packageManager": "[email protected]",
  "license": "AGPL-3.0-only",
  "engines": {
    "node": ">=26.0.0",
    "pnpm": ">=12.5.1"
  },
  "scripts": {
    "dev": "pnpm dev:buddy",
    "dev:infra": "docker compose --env-file infrastructure/.env -f infrastructure/compose.dev.yml up -d",
    "dev:db:sync": "pnpm --filter @uselexora/lexora-api prisma:sync",

The scripts show the shape of the application: a desktop shell, a web front end, an API layer with a Prisma managed database, a website, and infrastructure services started with Docker Compose for local development. The Rust side is the buddy component, which is where the desktop integration lives, and the release and packaging scripts are separate node programs.

For local development the readme asks for Node.js 26 or later, pnpm 12.5.1 or later and a Rust toolchain, with platform dependencies documented in the packaging directory, and then two commands at the repository root.

pnpm --filter @uselexora/lexora --filter '@uselexora/lexora-buddy...' --filter @uselexora/lexora-website install --frozen-lockfile
pnpm dev

The filter list names the desktop app, the Rust buddy and its workspace, and the website, which is the set you need for a working development environment.

Where Lexora is the wrong tool

Four boundaries are clear from what the project does and does not promise.

The first is the licence. Lexora is AGPL-3.0-only, the strongest copyleft in common use, and the manifest repeats it. Using the application on your own machine is unproblematic, but embedding it, or a derivative of it, in a product you distribute brings source disclosure obligations that a permissive licence would not. That is the single biggest adoption blocker for a company, and it is worth legal review rather than assumption. This is not legal advice.

The second is the dependency on an external model service. Lexora ships no quota and no model, and if you connect a remote provider then your conversations and any file content the agent puts into context are sent to that provider, under that provider's terms. A team that needs a guarantee that nothing leaves the network has to use a local model, and the readme does not describe a bundled one.

The third is the autonomy trade-off. The whole product is built around an agent that acts on your desktop with configurable permissions, and even with human approval in place, the tool is one misclick away from doing something you did not intend. The execution records and the per task permission levels are the mitigation, not a cure.

The fourth is operational fit. Scheduled automation requires the application running and the machine awake, the build wants a recent Node, a pinned pnpm and a Rust toolchain, and the version numbers are still pre-1.0 with releases arriving on consecutive days. This is a young project moving quickly, and it is best treated as something to try rather than something to build a process on.

Editorial conclusion

Lexora is the right tool for a Linux or macOS user who wants an agent that keeps a long task alive between sessions, whose project files must stay on the machine, and who is willing to configure their own model service and grant deliberate permissions. It is the wrong tool for a team that needs a permissive licence, for a user who will not supply an API key, and for a workflow that must run unattended on a machine that sleeps. Before adopting, read the data table in the readme and confirm your model provider's own terms, decide per task whether read-only, human approval or full access is right, and check the release you download, since the version numbers are still pre-1.0 and moving quickly.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. useLexora/Lexora on GitHub