OpenMausBot: a local-first chat app that puts Claude and Codex agents in your sidebar
Open Source Alternative to Grok Bot with a virtual machine that bots can use
At a glance
- What is it?
- OpenMausBot is an Apache-2.0 Electron app that runs Claude, Codex and Grok CLI agents as chat contacts, each with its own model, cloud computer and approval cards. It is a Grok Bot alternative for engineers who want the agent processes and transcripts to stay on their own machine.
- Who is it for?
- Adopt OpenMausBot if you already pay for Claude or Codex CLI access and want several long-lived agents with separate personalities, models and machines, while the harness server, transcripts and keys stay under ~/.openmausbot. Do not adopt it if you need Linux Wayland host control, since the README states that path remains disabled while issue #345 is open, or if you want a browser-only tool with no per-machine install.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenMausBot actually solves, and for whom
A single chat window with one assistant is a poor container for agent work. You end up with one thread, one model, one permission model and no way to keep a long-running job separate from a quick question. OpenMausBot's answer is to model agents as contacts: the README describes a Telegram-style sidebar where every entry is a real agent, each with its own personality, model, cloud computer and connected apps. The project calls itself an independent, open-source project inspired by Grok Bot, and states plainly that it is not affiliated with xAI.
The intended user is someone who already has the claude, codex or grok CLIs installed and logged in. The README says bots run on those CLIs with your existing logins and subscriptions, no new accounts and no proxy in the middle. That constraint defines the audience precisely: if you do not already hold CLI access to one of those engines, the app has nothing to drive. If you do, the value proposition is organisational rather than computational. You are not getting a better model. You are getting separate threads, separate model choices per bot, and a decision point in front of every risky action.
How the harness server, engines and permission broker fit together
The architecture is visible in the repository layout and the Dockerfile comments. A small harness server binds 127.0.0.1 and owns every agent process. The Dockerfile states the loopback-trust invariant is the auth model, which is why the container keeps binding loopback internally and deploy/docker-compose.yml places Caddy in the same network namespace to terminate TLS and authentication at the edge. Transcripts, keys and events live in ~/.openmausbot rather than a cloud, according to the README.
Engines are pluggable. The README says bots run on the claude, codex and grok CLIs, and that you can point any engine at a custom CLI binary (a versioned build or wrapper) under Settings, Engines. Each bot picks a model from a provider rail where Claude and Codex models sit side by side, defaults are marked, and unavailable providers are dimmed with the reason. Model switching mid-conversation is supported.
The part that matters most for safety is the permission broker. Shell commands, file edits and questions surface as inline cards with Allow, Deny or an answer typed into chat. The README states this applies to cloud and local computers alike. That is a deliberate trade-off: every risky action becomes a human decision, which slows autonomous runs down. For an agent with a shell, that friction is the feature.
Where a bot's computer comes from
Each bot can be given hands in one of three ways. The README lists a cloud Linux desktop, an isolated Local VM, or your own computer where the platform safety boundary is currently certified. The Computer panel spins up the cloud desktop on its own and shows a live screen preview while the bot works, with an Open desktop action to take over in the browser. The same panel can point the bot at this Mac instead.
Host control is the narrow path. The README states it is available on macOS and Ubuntu Xorg after explicit opt-in, and that Ubuntu Wayland host control remains disabled while issue #345 is resolved. Read that as a hard boundary rather than a temporary inconvenience: on a Wayland session you are limited to the cloud desktop or the Local VM. The connected apps layer is separate from all of this. It is a marketplace over Composio Sessions covering Gmail, Slack, GitHub, Notion, Linear and hundreds more, with OAuth performed once so every bot can use them as tools.
Installing OpenMausBot and starting a first bot
The README points at prebuilt installers rather than a package manager for end users. It links signed and notarized .dmg files for Apple silicon and Intel Macs, an x64 Windows installer, and an Ubuntu 24.04 x64 .deb with an AppImage listed as beta. The download badges resolve to the latest release assets, so the filenames below are the ones the README advertises.
# macOS, Apple silicon
curl -L -o OpenMausBot.dmg \
https://github.com/milind-soni/OpenMausBot/releases/latest/download/OpenMausBot.dmg
# Ubuntu 24.04 x64
curl -L -o OpenMausBot-amd64.deb \
https://github.com/milind-soni/OpenMausBot/releases/latest/download/OpenMausBot-amd64.deb
sudo apt install ./OpenMausBot-amd64.debIf you would rather build from source, package.json sets the floor at Node 24 and pins pnpm 10.33.0 as the package manager. The desktop development script prepares cloudflared before launching Electron.
corepack enable
pnpm install
pnpm dev:desktopFor a server deployment the repository ships a Compose file. The .env.example file documents the knobs, and the defaults bind the published port to 127.0.0.1:8080 while the harness itself listens on OMB_PORT 8799 with OMB_WEBHOOK_PORT 8800 inside the container.
cp .env.example .env
docker compose up -dAfter launch, the first real use is to create a bot and give it a model. Open Settings, Engines to confirm which CLIs the harness found, then use the model picker to choose a Claude or Codex model for the bot. Send it a task that touches the filesystem, and you should see an approval card appear in the thread before anything executes. If no card appears, stop and check the broker before letting the bot near a real repository.
Limits, failure modes and the wrong tool
The strongest limitation is stated by the project itself: Ubuntu Wayland host control is disabled pending issue #345. Anyone running a modern Ubuntu desktop on Wayland should assume the your own computer option is unavailable and plan around the cloud desktop or Local VM.
The second is dependency depth. OpenMausBot does not ship a model. It orchestrates CLIs that you must install and keep authenticated, and the Dockerfile installs the engine packages named in the ENGINES build argument, defaulting to @anthropic-ai/claude-code and @openai/codex. An expired login or a breaking CLI release lands on your desk, not the project's. The Dockerfile comments also note that the image never runs Electron and sets ELECTRON_SKIP_BINARY_DOWNLOAD, and that agent-browser --with-deps is avoided because the image deliberately does not ship sudo. Those are container concerns, but they hint at how much surface area sits under the chat UI.
The third is that secrets are write-only in the UI. The README says credentials persist locally and the provider fleet hot-reloads, but that the UI only shows a masked form. That is good hygiene and bad for debugging a wrong key.
Where it is the wrong tool: if you want a hosted assistant reachable from any browser with no local install, this is the opposite design. If you need one shared agent for a whole team rather than per-user local state, the loopback-trust model works against you. And if your work is single-turn question answering, the sidebar, the VM and the broker are overhead you will not use.
How it differs from a hosted bot platform
The obvious alternative is a hosted agent platform in the Grok Bot mould, where the agent runtime, the computer and the credentials live in the vendor's cloud and you reach it through a browser. The difference is not the feature list, it is where the trust boundary sits. In a hosted platform the vendor holds the transcripts and the tool credentials. In OpenMausBot the README states the harness server on 127.0.0.1 owns every agent process and that transcripts, keys and events live in ~/.openmausbot, with the container image preserving that boundary by binding loopback internally and putting Caddy in the same network namespace.
A second alternative is wiring the CLI agents together yourself: a shell script per agent, a terminal multiplexer, and whatever approval logic you write. That keeps you on the same engines with no Electron layer, and it is genuinely lighter if you only need one or two agents. What you give up is the parts that are tedious to build: the per-bot model picker with provider availability, the approval cards, the Composio app marketplace, and the live screen preview of a running desktop. OpenMausBot is a packaging choice more than a capability choice, and it should be judged that way.
Maintenance, licensing and upgrade cost
The repository is not archived. The last push was on 2026-09-16, and releases v0.1.80, v0.1.81 and v0.1.82 all landed between 2026-09-15 and 2026-09-16, so release cadence is currently dense. Version numbers in the 0.1.x range mean the project makes no stability promise, and the README's own issue reference for Wayland shows that user-visible gaps are still open. Budget for reading release notes before upgrading a working install, especially if you pin a custom engine binary under Settings, Engines.
Licensing needs care rather than a summary. package.json declares Apache-2.0, and the repository carries LICENSE, LICENSING.md, NOTICE and a CLA.md. The presence of a separate LICENSING.md and a NOTICE file alongside a third_party/ directory and an enterprise/ directory means the licence story is not uniform across the tree. Read those files yourself before redistributing or embedding anything. Nothing here is legal advice.
The README also carries an explicit statement that the project has no token and is not affiliated with any cryptocurrency using the OpenMausBot, Maus or SupaMaus names. That is worth knowing before you search for the project and land somewhere else.
Editorial conclusion
Adopt OpenMausBot if you already pay for Claude or Codex CLI access and want several long-lived agents with separate personalities, models and machines, while the harness server, transcripts and keys stay under ~/.openmausbot. Do not adopt it if you need Linux Wayland host control, since the README states that path remains disabled while issue #345 is open, or if you want a browser-only tool with no per-machine install. Before trusting it with real work, verify on your own machine that the permission broker really surfaces shell commands and file edits as Allow/Deny cards, and read LICENSING.md and NOTICE rather than assuming the Apache-2.0 label covers every directory in the repository.
Frequently asked questions
What is OpenMausBot used for?
It is a local-first chat app for running a team of AI agents, where each bot in the sidebar is a real agent with its own personality, model, cloud computer and connected apps. The agents run on the claude, codex and grok CLIs installed on your own machine.
What are examples of bots in OpenMausBot?
The README describes bots as contacts in a messaging app: each one runs Claude or Codex locally under the hood, keeps its own thread memory, and can be given a cloud Linux desktop, an isolated Local VM, or your own computer where host control is certified. Bots can also reach apps such as Gmail, Slack, GitHub, Notion and Linear through the Composio marketplace.
Is OpenMausBot an alternative to Grok Bot?
The README calls it an independent, open-source project inspired by Grok Bot that keeps the idea of AI as a messaging app and rebuilds it local-first on the agents you already have. It states explicitly that it is not affiliated with xAI.
How do I install OpenMausBot?
The README links prebuilt installers: signed and notarized .dmg files for Apple silicon and Intel Macs, an x64 Windows installer, and an Ubuntu 24.04 x64 .deb with an AppImage listed as beta. Building from source requires Node 24 and pnpm 10.33.0, and a server deployment uses the repository's compose.yaml.
Community notes