Five Companies Put Agents in Their Cloud. This Repo Puts Them on Your Disk.

Somewhere in the first months of 2026, the personal-agent category stopped being a rumor and became a shipping schedule. xAI’s Grok Bot put a roster of bots on one shared cloud computer. Meta’s Muse put a single personal agent in a Meta cloud VM, for the US and Canada. OpenAI’s dots embedded an always-on agent inside ChatGPT. Manus’s Cue gave invite-only agents their own phone, email, and wallet. Spear Street’s Instinct went further and let an agent hold your passwords on a cloud machine. Five products, one shape: AI as a thing you chat with, running on infrastructure that belongs to someone else.

OpenMausBot is the counter-move. It keeps the shape — a messaging app where every entry in the sidebar is a real agent with its own personality, model, computer, and connected apps — and rebuilds it open, local-first, and on top of the agents you already have. Apache 2.0, transcripts and keys in ~/.openmausbot on your own disk, and no new account with anyone. The project’s own framing is blunt about the market it’s answering: if you searched for an open Muse, an open dots, or an open-source Grok Bot, this is the repository.

The idea: agents as contacts

The user-facing conceit is the part worth taking seriously, because it’s not cosmetic. Every bot in the sidebar behaves like a contact in a chat app — pin it, mark it unread, duplicate it, hide it, delete it. Each has its own thread memory, its own model, its own working computer, and its own OAuth connections to Gmail, Slack, GitHub, Notion, and a few hundred other apps through Composio. Channels keep Work, Personal, and per-project contexts separate without cloning bots.

Why does the messaging-app metaphor matter technically? Because it solves the supervision problem that terminal-based multi-agent work creates. As the opensourcealternatives.to breakdown puts it, running multiple agents in parallel is a coordination problem: switching between terminal sessions loses context, re-authorizing tools per session adds overhead, and there is no standard way to pause a running agent or approve a shell command before it executes. Wrapping all of that in a chat UI — where approvals arrive as inline cards and replies stream with tool-run activity chips — turns agent supervision from a terminal-watching chore into something closer to managing a small team over messages. The metaphor is the oversight layer.

The boring part: one harness, one event stream

Under the chat shell, the architecture is almost aggressively simple, and that simplicity is the point. Two processes. The app — React, Tailwind, Electron on the desktop — holds no transports of its own; it sends typed commands over HTTP and folds a single SSE event stream into state. A small harness server bound to 127.0.0.1 owns every agent process and normalizes each provider’s native protocol into one canonical runtime event stream, logged per-thread as NDJSON.

The load-bearing piece is the driver layer. One driver per provider — Claude, Codex, and Grok, each speaking its own native protocol over its local CLI — plus a cloud-computer agent. The driver SPI is deliberately small: adding a provider is one file plus a one-line registration, and unknown drivers degrade to “unavailable” in the model picker instead of crashing the fleet. Any ACP-speaking CLI or OpenAI-compatible endpoint plugs in through config with no code at all, which is how OpenRouter, Fireworks, DeepSeek, and friends get in.

This is the genuinely clever move, and it’s a business-model observation dressed up as an architecture. The big personal-agent products are vertically integrated: their model, their computer, their data. OpenMausBot is a horizontal shim over the agent CLIs — claude, codex, grok — that developers already have installed and logged into. Your existing subscriptions, no proxy in the middle, no second subscription stacked on top of the AI fees you already pay. The project is, in the kindest sense, glue code — but glue over a seam that five billion-dollar companies are deliberately trying to close.

Agents with hands, and the safety story

Chat is the interface; the computer is the payload. Each bot can get a cloud Linux desktop (via Boat) that spins up on demand with a live screen preview, an isolated local VM, or — where the platform safety boundary is certified — control of your actual machine through the Cua Driver. The permission broker applies to all of them: shell commands, file edits, and questions surface as Allow/Deny cards in the thread, and nothing risky runs silently.

This is where OpenMausBot intersects the loudest argument in the agent world right now: what computer does an agent get, and how isolated is it? Manus runs its agents on E2B’s Firecracker microVMs because Docker was too slow and containers aren’t a full OS. LangChain’s sandboxing argument is that containers share a kernel with the host and that model-generated code needs hardware-level separation. Sajal Sharma’s sandboxing writeup frames the stakes via Simon Willison’s “lethal trifecta”: an agent with access to private data, exposure to untrusted content, and a way to send data out is one hidden instruction away from turning its access against you.

OpenMausBot’s answer is unusual in that it’s visibly conservative rather than maximal. Host control — a bot driving your actual computer — is opt-in on macOS and Ubuntu Xorg, and on Ubuntu Wayland it is simply disabled, fail-closed, while a real-seat safety issue (tracked publicly as issue #345) remains unresolved. The Linux packager downloads only a tag-pinned upstream archive, verifies size, SHA-256, a complete member allowlist, and inner executable hashes, and the installed app never downloads or self-updates native automation code. A CycloneDX SBOM and a reviewed provenance record ship with the runtime. This is more supply-chain hygiene than most agent projects bother with, and the README documents the gaps rather than papering over them — a good sign in a category where the default posture is to ask forgiveness.

The portability play

Two features suggest the project is aiming past “nice local chat app” toward something like an ecosystem. The first is team packages: a whole team — bots, instructions, channels, routines, connection slots — serializes to one Markdown file with structured YAML frontmatter, importable in one click from a public repository or a marketplace. The format is deliberately portable: OpenMausBot reads the frontmatter for reliable installs, while Grok, Claude, ChatGPT, and humans can follow the plain Markdown playbook. Credentials, conversations, permissions, and computer access never travel in the file; connections arrive off and routines arrive paused.

The second is an MCP server that exposes a bounded control plane — inspect bots, read transcripts, send work, wait for completion, switch models, interrupt — to external clients like Claude Desktop and Cursor, while explicitly refusing to expose approval grants, deletion, credentials, or computer lifecycle. That boundary-drawing is the right instinct: the moment an orchestration surface can also grant itself permissions, it stops being a control plane and starts being a liability.

What it doesn’t do yet

The honest limits are mostly about always-on-ness. Webhook triggers use a local receiver on a dedicated port; the app must be running to accept a delivery, so unattended 24/7 automation needs a relay or a self-hosted arrangement on top. Hosted and mobile connectivity is still being built. The current build runs per-user on individual machines rather than as a shared service — fine for solo developers and loose teams, wrong for anyone who needs SSO and audit logs today (an enterprise tier exists, in a source-available enterprise/ folder under its own license, which is a small asterisk on the “Apache 2.0, no feature tiers” story). Voice calls are macOS-only. The Windows installer isn’t code-signed. API keys are saved as plaintext in a private config file — disclosed plainly, but plaintext. And the broader-agent world’s direction of travel, per IBM’s agent-use-case survey and Google Cloud’s 1,302-entry customer catalog, is toward centrally governed agentic teams inside enterprises — a shape this per-machine, bring-your-own-login design only partially overlaps.

There’s also a fair question about how much of the value is the project’s own. The agents are Anthropic’s, OpenAI’s, and xAI’s. The cloud computers are Boat’s. The app connections are Composio’s. The voices are ElevenLabs’, Fish Audio’s, or Apple’s. OpenMausBot’s contribution is the harness, the permission broker, the normalization layer, and the interface — the unglamorous integration work that, as the E2B/Manus story illustrates, would otherwise take a dedicated infra team months to rebuild. Glue code over a strategic seam is still a real contribution. It’s just worth being clear about which kind.

Why now

The timing is the whole story. The personal-agent category consolidated in a matter of weeks, and every entrant made the same three choices: their model, their computer, your data on their side of the line. OpenMausBot is the first project to take that product shape seriously enough to clone it faithfully — roster, personalities, computers, connected apps, voice — while inverting every one of those choices. It’s early, the README says so itself, and the loop that works end to end is the one that matters: message, agent, streamed reply, tools, approvals, computer use.

Whether it stays ahead of the closed products depends on the parts that are hardest to volunteer for: always-on hosting, mobile, and the enterprise governance layer. But as a proof that the category’s shape and its business model are separable — that you can have the chat-app agent team without the vendor’s cloud underneath it — it’s already done the interesting work.