OpenBot: a desktop workspace for persistent AI teammates

One workspace and one conversation per agent

OpenBot is described in its README as a local-first desktop workspace for persistent AI teammates, and the unit of organisation is the agent, not the conversation. Every agent gets its own workspace directory and its own conversation, backed by an independent session: the local Codex App Server, Claude Code, Grok CLI, or through ACP the OpenCode, Gemini, Cursor CLI and Cline CLI runtimes. On top of that the app supplies local FIFO message queues with pause, resume, cancellation and crash-safe persistence, file transfers between agents, an embedded browser, and agent-to-agent messages with replies, reactions and images. The target user is a developer running more than one agent at a time, because the problem it solves is coordination: without a shared surface, a Codex session and a Claude session cannot exchange a file or a status update. There are also shared desktop channel chats with one task owner, explicit delegation and shared history, plus Stop, Resume, Reassign, Archive and Restore controls.

The security posture is stated in a warning at the top

The README opens with a warning block that any evaluation should read first. OpenBot is a development preview, and agents currently run with danger-full-access and approvalPolicy never. They can read and modify files, run commands, use the network, and control the embedded browser without per-action confirmations after the explicit first-launch consent. The guidance is to run only agents and tasks you trust, keep backups, and review the Security section before use. That combination deserves emphasis: the consent is one click at first launch, and after it there is no per-command gate. The app is designed so an agent can act on its own, and the guardrails live in the choice of what you point it at rather than in an approval dialog. The project is honest about this, which is a point in its favour, but it also means the tool belongs on a machine where you are willing to lose files, and the keep-backups instruction is not decorative.

Local-first, not offline

The README makes a distinction that is easy to skim past. OpenBot is local-first, not offline-only. Codex connects to OpenAI, Claude connects to Anthropic, Grok connects to xAI, Gemini connects to Google, Cursor connects to Cursor and Cline connects to Cline, visited pages use the network, and installed plugins may connect to their own services. What local-first buys you is that the workspace, the conversations, the queues and the files stay on your machine, and that the app is usable without an OpenBot account. The optional account works through one-time email codes, with the account API running on Cloudflare Workers and D1, and the account menu is where local data and privacy-safe diagnostics exports live. Local model servers are also detected automatically, with Ollama and LM Studio named, and custom OpenAI-compatible endpoints and custom ACP agents are supported, so the workspace is not locked to hosted providers.

Context compaction and per-agent state

Two features matter for anyone running agents for hours. The first is per-agent context monitoring with automatic compaction before long threads exhaust the model window, which addresses the failure mode where a long conversation silently degrades. The second is the breadth of per-agent state: model, reasoning, profile, notification, browser and panel state are all kept per agent, so switching between a reasoning model for architecture and a faster one for edits does not mean reconfiguring the workspace. Agents are created and edited by prompt, on desktop and on mobile, with editable instructions, an avatar, and a section review before saving, so a definition of what an agent is for can be iterated without touching configuration files. The embedded browser is persistent, so agents can open, inspect and control it across the session rather than starting from a blank page each time.

Computer Use through a separate cua-driver binary

Optional Computer Use is available on macOS, Windows and Linux through the cua-driver binary that ships in the release. OpenBot starts it as its own child process and gives it to every provider, which is a cleaner arrangement than embedding screen control inside the app process. The distinction between the local AppImage and container installs matters here, and so do the Linux specifics. On Ubuntu 23.10 or newer and on Debian 13, unprivileged user namespaces are restricted by AppArmor, and OpenBot exits during launch until you install an AppArmor profile.

sudo install -m 0644 build/linux/openbot.apparmor /etc/apparmor.d/openbot
sudo systemctl reload apparmor

The same file ships inside the AppImage at resources/linux/openbot.apparmor, and the README asks you to edit the attachment path if you keep the AppImage somewhere unusual. The warning is explicit: do not start OpenBot with --no-sandbox, because that removes the boundary between a renderer and the rest of the computer. Voice prompts are not available on Linux, and remote desktop works on Linux x64 in an X11 session such as Xorg or Xvfb but not under Wayland, and the arm64 AppImage does not include it.

Installing on macOS, Windows and Linux

The install paths are conventional desktop distribution, and the supported platforms are macOS 13 or newer on Apple silicon or Intel, Windows 10 or newer on x64, and x64 or arm64 Linux as an AppImage. On macOS you download the OpenBot-*-arm64.dmg or the x64 variant, drag it to Applications and open it. On Windows the OpenBot-*-x64.exe installer comes from GitHub Releases. On Linux the OpenBot-*-x86_64.AppImage or the arm64 build is made executable with `chmod +x OpenBot-*.AppImage` and then run.

On the first start from an AppImage, OpenBot writes ~/.local/share/applications/openbot.desktop and ~/.local/share/icons/openbot.png, which is what lets an openbot:// link, an invitation or a plugin listing, open the app and gives the launcher an icon that stays after the app exits. Deleting those two files undoes it. One Windows detail is worth knowing before you install: releases are signed by SYNTHETIFY LABS SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ, older releases are not code-signed, and SmartScreen can still warn about a new release, so check the release checksum or the GitHub build attestation before running the installer.

Running it headless on a server or in Docker

For an always-on server of your own account on a VPS or home server running Ubuntu 24.04 with systemd, the README documents a terminal install with an email-code sign-in.

curl -fsSL https://raw.githubusercontent.com/nightly-labs/openbot/main/scripts/install-server.sh | sudo bash
sudo openbot login

The same server runs as a container for linux/amd64 and linux/arm64, and the shipped seccomp profile is what lets the Electron sandbox stay on.

curl -fsSLO https://raw.githubusercontent.com/nightly-labs/openbot/main/docker/seccomp.json
docker run -d --name openbot --restart unless-stopped \
  --security-opt seccomp=seccomp.json --security-opt no-new-privileges:true \
  --shm-size 1g --stop-timeout 60 -v openbot-data:/data \
  ghcr.io/nightly-labs/openbot:latest
docker exec -it openbot openbot login

After the install you drive it from the desktop app, the iPhone app or openbot.run/app. There is one provider-specific catch on a headless host: Gemini sign-in needs a desktop browser and xdg-utils, and the sign-in page has to be opened in a desktop session on the same host or VM, because Google sends the callback to that host through 127.0.0.1. A server with no desktop cannot complete that sign-in, so the Gemini path is the part of the provider matrix that does not survive headless operation.

A TypeScript and Electron codebase built on Bun and SolidJS

The repository layout shows how the project is put together, and the top level entry list is a fair map of it: apps/, packages/, remote/, src/, vendor/, marketplace/, plugins in the form of third-party-plugins, native-runtime.lock.json, and build and docker directories. The build is Electron with electron-builder configuration, and the package.json names the product OpenBot with the desktop file openbot.desktop, the version at 0.44.3, and the licence as PolyForm-Noncommercial-1.0.0. That licence is the one thing to look at before anything else in the metadata, because it is not an open source licence in the usual sense: it permits noncommercial use, so a company that wants to use OpenBot in a commercial setting has a different question to answer than it would with MIT or Apache code. The stack itself is Bun with a bun.lock, SolidJS for the interface, Biome for formatting, Vitest for tests, and Storybook, with a workspace catalog pinning shared dependency versions. The recent releases are tight, v0.44.1, v0.44.2 and v0.44.3 all on 2026-10-19, and the last push was on 2026-10-20, so the project moves fast.

Editorial conclusion

OpenBot fits a developer who already runs several coding agents side by side, wants each one isolated in its own workspace with its own queue, and needs them to hand work to each other with a shared browser and file transfer, all on a desktop. It does not fit anyone who needs a hardened production runtime, because the README states the agents currently run with danger-full-access and approvalPolicy never, and it does not fit a server with no desktop, since the Gemini sign-in flow needs a browser session on the same host. Before you run it, read the Security section, keep backups as the warning asks, and on Linux install the AppArmor profile rather than passing --no-sandbox, which the README says removes the boundary between the renderer and the rest of the machine.

Frequently asked questions

Official sources

1. Issues
2. nightly-labs/openbot on GitHub
3. Project website
4. README
5. Releases