OpenMausBot: A Team of AI Bots Inside a Chat App

By Indie Kings | October 30, 2026

Updated October 30, 2026: milind-soni/OpenMausBot, an open-source alternative to Grok Bot that runs a roster of AI agents inside a messaging-style desktop app, reports 7,932 stars, 1,150 forks and 160 contributors. The repository is Apache-2.0 licensed, was created on August 11, 2026, carries the v0.1.134 release from October 30, and lists 570 open issues and pull requests.

A vintage tin toy robot standing on a plain surface

Image: a toy robot, a low tech stand in for a desktop full of agents, via Wikimedia Commons.

Bots as contacts, agents as processes

The premise is that one assistant in one window is the wrong shape for agent work. OpenMausBot borrows the interface of a messaging app and gives every contact its own agent process. Each bot has a personality, a model, a thread of memory, a working folder and, if you pay for the service, its own cloud computer. You talk to them the way you talk to colleagues, and you can watch them work, interrupt them and approve what they want to do.

Under the interface are two processes with a clean split. The app is React and Tailwind CSS, and it holds no transports of its own. It sends typed commands over HTTP to a harness server on 127.0.0.1:8799 and folds a single server sent event stream back into state. The harness owns every agent process and normalizes each provider's native protocol, stream JSON, JSON RPC or the Agent Client Protocol, into one canonical event stream logged per thread as newline delimited JSON. That separation is why the app can stay a chat shell while the server does the difficult work of supervising subprocesses.

The agents are the command line tools you already have. Claude, Codex and Grok run through their local CLIs using your existing logins and subscriptions, with no proxy in the middle. A driver registry maps provider configurations to live instances, and an unknown driver degrades to unavailable rather than crashing the fleet. If you want a provider the project does not ship, the driver interface is deliberately small, and any ACP speaking CLI or OpenAI compatible endpoint can be plugged in through configuration without writing code.

Channels add structure without cloning bots. Work, Personal and each project can live in separate channels, each with its own transcript, shared instructions, working folder, responder rules and editable roster. A room set to Auto uses a decision model to pick which bot should answer an unmentioned message, falling back to the room's lead when the decision model is off or unsure. The project calls the fast path Jev and supports a TypeSafe Jev key or an OpenRouter key with a chosen model. It is a small feature with a large effect on whether a group chat of agents feels organized or noisy.

Approvals, computers and connected apps

The permission broker is the safety story. Shell commands, file edits and questions surface as inline cards with Allow, Deny and an answer box, for cloud and local computers alike. Every risky action becomes a decision the user makes rather than a log line they discover later. The same broker handles the local machine, where native computer use runs through the Cua Driver, and the remote machine, where each bot can get an isolated Linux desktop and terminal from Boat.

Connected apps come through Composio Sessions. A marketplace offers Gmail, Slack, GitHub, Notion, Linear and hundreds of others, with OAuth handled once and every bot able to use the connection as a tool. Credentials live in App Settings and are write only: the interface only sees configured flags, and the provider fleet hot reloads when a key changes. That is a better design than pasting keys into each bot's profile, and it keeps the blast radius of a leaked screen small.

Teams are portable. A complete team can be installed from one Markdown file with YAML frontmatter, either from the BotMRR directory, a local file or a public GitHub URL. The app opens a review screen before creating the bots, the Chief of Staff, channels, playbooks, a connector checklist and suggested routines. Connections stay off until approved, routines arrive paused, and packages never carry credentials, conversations, permissions, memory or computer access. Sharing a department works the same way in reverse: bots, group chats, routines, shared instructions and connection slots go into one file, while chat history, keys, model choices and computers stay out, and anything that looks like a secret is stripped from the text.

Triggers turn the app from a chat window into a scheduler. A bot can create a routine that runs once, on selected weekdays or every 5 to 1,440 minutes, aligned to its chosen start time and skipping an occurrence if the previous run is still active. Webhooks arrive through a dedicated receiver on 127.0.0.1:8800 by default, exposing only a health endpoint and secret hook paths, with bearer authentication recommended. App events extend the same idea to connected services: a Gmail message from a specific sender can start a bot, with Gmail polled every 15 minutes and push apps arriving immediately. The desktop keeps up to 500 events a day, and events queue while the app is closed.

There is a headless mode for people who do not want a window at all. The openmausbot command applies a team from YAML, gives a bot one job, waits until it and every teammate it asked are done, and exports the output, with a JSON document and scriptable exit codes. A stdio MCP server exposes a bounded control plane for external clients such as Claude Desktop and Cursor: inspect bots and channels, read compact transcripts, create and configure bots, send work, wait for completion, switch models and interrupt turns. It deliberately does not expose approval grants, deletion, arbitrary settings, credentials or computer lifecycle.

Voice is optional and layered. Any reply can be read aloud through ElevenLabs, Fish Audio, Grok from xAI, built in Mac voices or a local Chatterbox server, and calls are available on macOS, riding the same on device dictation as the composer microphone. The README is careful to say that microphone transcription is unchanged and that call support is macOS only for now. The project also states plainly that it has no token, is not affiliated with xAI, Meta, OpenAI or Manus, and that any coin using its name is unaffiliated. In a scene where brand confusion is common, that paragraph is a useful piece of housekeeping.

Linux beta and the Wayland gate

Released builds exist for macOS on Apple silicon and Intel, Windows x64 and Ubuntu 24.04 x64. The Mac builds are signed and notarized. The Windows installer is not code signed yet, so SmartScreen shows an unknown publisher warning and the README tells users to choose More info and then Run anyway. The Ubuntu build is a beta with a deb and an AppImage, and GNOME is the supported desktop. From source, the requirements are Node 24 or newer, pnpm and at least one agent CLI installed and logged in.

The capability table is unusually honest about platform gaps. Packaged app, embedded harness and local agent CLIs are supported on macOS and beta on both Ubuntu Xorg and Wayland. Explicit preview only local screen capture is the same. Bot control of this computer is supported on macOS, beta with explicit opt in on Xorg, and disabled on Wayland because of a safety gate. Native on device dictation is planned for Linux. On Wayland the app never starts the automation runtime and clears legacy opt ins while the real seat safety issue remains unresolved, which is the correct default even though it means the feature is unavailable.

The Linux packaging is documented in more detail than most projects bother with. The packager downloads only a tag pinned upstream archive during the build, verifies its size, SHA-256 hash, a complete member allowlist and inner executable hashes, then packages only the CLI and cursor theme sidecar. The installed app never downloads or self updates native automation code. Cua's MIT notice, the Inter font license, a generated third party license report and a CycloneDX inventory ship with the runtime. That is supply chain work, not marketing, and it is the kind of thing that decides whether a security team allows an agent tool on a corporate laptop.

The status section is candid about maturity. The loop works end to end: message, agent, streamed reply, tools, approvals, computer use. Hosted and mobile connectivity is still being built, and webhook triggers currently rely on the local receiver rather than an always on hosted relay, so the app must be running to accept a delivery. With 570 open issues and pull requests against 160 contributors, the project is clearly moving faster than it is polishing, and the version number, 0.1.134, says the same thing. For a repository created in August 2026, that pace is the story as much as the feature list.

Project card

ItemDetail
Repositorymilind-soni/OpenMausBot on GitHub
PurposeMessaging style desktop app for a team of local AI agents
StackElectron, React 19, TypeScript, Vite, Tailwind CSS, Node 24 or newer
AgentsClaude, Codex and Grok through their local CLIs, plus custom ACP or OpenAI compatible engines
ArchitectureApp on port 5199, harness server on 127.0.0.1:8799, HTTP commands and one SSE stream
SafetyPermission broker with inline approval cards, write only credentials
PlatformsmacOS signed and notarized, Windows x64, Ubuntu 24.04 beta
ExtrasComposio apps, Boat cloud computers, triggers, team files, MCP server, headless CLI
Latest releasev0.1.134, October 30, 2026
LicenseApache-2.0
Scale7,932 stars, 1,150 forks, 160 contributors, 570 open items

FAQ

What is OpenMausBot?
An open-source desktop app that presents a roster of AI agents as contacts in a chat interface, with each bot running on a local agent CLI.

Does it include model access?
No. It uses the Claude, Codex or Grok CLI you already have installed and logged in, so your existing subscription or API access applies.

Which platforms are supported?
macOS on Apple silicon and Intel, Windows x64, and Ubuntu 24.04 x64 as a beta. Linux bot control of the local desktop is disabled on Wayland.

Is it free?
The app is Apache-2.0. Optional services such as Boat cloud computers and hosted voices are third party products with their own accounts and charges.

Can bots act without permission?
Risky actions surface as approval cards for shell commands, file edits and questions. The broker covers cloud and local computers.

Is it affiliated with xAI or Grok?
No. The README states it is an independent project inspired by Grok Bot and not affiliated with xAI, Meta, OpenAI or Manus, and that it has no token.

Bottom Line

OpenMausBot is the most complete open take on the agent-as-contact idea, and the engineering behind the chat shell is more serious than the screenshots suggest. A harness that normalizes three provider protocols into one event stream, a permission broker that treats every risky action as a decision, and supply chain verification for the Linux runtime are the parts that matter. The breadth is also the risk: cloud computers, connected apps, triggers, voice, team files and an MCP server in a 0.1.x release means many surfaces and 570 open items. The Wayland safety gate is the right call, and the Windows unsigned installer is a caveat rather than a flaw. Try it with one bot and one channel before building a department.

Sources

  • GitHub milind-soni/OpenMausBot README, architecture, features, platform table, triggers and status, accessed October 30, 2026
  • GitHub API metadata for milind-soni/OpenMausBot, stars, forks, contributors, issues, size and latest push, accessed October 30, 2026
  • GitHub releases for milind-soni/OpenMausBot, v0.1.134 published October 30, 2026

Related: DeepTutor: An Agent-Native Learning Workspace Hits v1.7.0 | Every App: A Prompt That Replaces Your SaaS With Open Source

Share