Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · November 5, 2026 · repo

OpenMausBotmulti-agentclaude-codecodexagent-securityai-skills

OpenMausBot Turns Claude Code and Codex Into a Team of Chat Bots. Check Its Schedules First

An open-source chat app that turns your Claude Code, Codex and Grok logins into a team of bots, and the one screen to check before you leave it running

Personal agent products keep converging on the same shape. Not one assistant in a box, but a roster of bots in a messaging app, each with its own job, its own model and its own computer to work on. The closed versions of that idea keep the model, the machine and your data on the vendor's side.

OpenMausBot is an open-source version, and it is drawing attention. It sat at #13 on Trendshift's daily board this afternoon, it shows roughly 13k stars, and v0.1.141 shipped this morning. The pitch, from its README: "The open-source Grok Bot alternative: your own team of AI bots, in a chat app."

The safety story is the part most people will notice first. Bots ask before they act, through Allow and Deny cards in the chat. But one thing a bot can do without asking is create its own schedule. And a schedule is what turns a bot you supervise into a bot that runs while you sleep.

What OpenMausBot is

Think of it as Telegram where every contact is a coding agent.

Each bot in the sidebar runs on a command-line agent you already have: Anthropic's claude (Claude Code), OpenAI's codex, or xAI's grok. The README says bots use "your existing logins and subscriptions, no new accounts, no proxy in the middle." You pick a model per bot and can switch mid-conversation.

Under the chat sits a small background program the README calls a harness server, listening only on your own machine (127.0.0.1), which "owns every agent process." Transcripts, keys and events live in a ~/.openmausbot folder rather than a cloud.

Bots also get "hands." Each one can work on a cloud Linux desktop, an isolated local virtual machine, or your own computer where the README calls the safety boundary "currently certified." Host control (a bot driving your actual desktop) is opt-in, available on macOS and some Ubuntu setups. Connected apps such as Gmail, GitHub, Slack and Notion come through Composio, a third-party service that handles the app sign-ins.

The license is Apache-2.0, with one exception: an enterprise/ folder is source-available under its own license. Delete that folder, the README says, and what remains is the open-source edition.

The approval model, and the gap in it

Here is how the README describes the guardrail: shell commands, file edits and questions surface as inline cards in the chat, where you choose Allow, Deny, or answer in chat. A "permission broker" turns every risky action into a decision you make, on cloud and local computers alike.

That covers the moment-to-moment work. Now look at the triggers section.

A trigger is "when something happens, a bot does something." Tell a bot "every weekday at 9, send me a summary of my inbox," and it sets the trigger up in that same turn with its trigger tool. The README's own wording: "no confirmation; the chat shows a live card with Edit, Pause and Undo."

So the bot does not ask. It acts and shows you a card you can reverse.

Three details make that matter more than it first sounds:

  • Schedules can be frequent. A routine can run once, on chosen weekdays, or every 5 to 1,440 minutes.
  • There is no default time limit. An optional Advanced run limit can stop stuck work, but per the README "no timeout is imposed unless one is chosen."
  • Triggers can fire on outside events. Webhooks (a web address another service calls to start a bot) listen on a local port (127.0.0.1:8800 by default), and app events start a bot when something lands in a connected app ("whenever I get an email from Acme, draft a reply"). Those app events pass through OpenMausBot's connected-apps service, which queues them until your desktop collects them.

The project clearly knows schedules deserve care. When you import a shared team or department, "new bots on Ask, skills switched off and routines paused." Imported routines arrive off until you turn them on. Routines a bot creates in chat start live.

Put plainly, there are two kinds of permission here. Action permission is "may the bot run this command now?", and OpenMausBot asks every time. Time permission is "may the bot decide to come back and work later, on its own?", and a bot grants itself that one by default, leaving a card you can undo.

That is the idea worth taking from this repo, and it applies to every agent tool with a scheduler. An approval card protects you while you are looking at the chat. A schedule is designed to run when you are not.

Server admins learned this lesson decades ago. Nobody audits a box by reading its shell history alone; they read the crontab (the list of scheduled jobs on a Unix server), because that is where something set up last week keeps running today. Agent tools with schedulers have the same property, and OpenMausBot puts its schedule list one click away from the chat rather than in front of you.

What I could not confirm

The README does not say what happens when a scheduled run hits a risky action. Two possibilities, and they lead to different problems:

  • If the scheduled run still waits for an approval card, an overnight job may simply stall until you wake up and tap Allow.
  • If it does not wait, the routine is doing unattended work under rules you approved for supervised work.

The README also mentions bots that "ask for approvals out loud" in voice calls, which suggests approvals can reach you outside the chat window. It does not settle the scheduled case. Test it yourself before you rely on either behavior (steps below).

Put this into practice

1. Install it. The quickest route needs Node 24 or newer and at least one agent CLI installed and logged in (claude, codex or grok):

npx openmausbot

First launch walks you through choosing AI access, signing in or pasting an API key, picking a model and optionally connecting a phone. There are also signed macOS builds, a Windows installer (unsigned, so SmartScreen will warn) and Ubuntu 24.04 packages on the releases page. To build from source, the README uses pnpm install, then pnpm dev:server (harness on port 8799), pnpm dev (app on port 5199) and, for the desktop shell, pnpm dev:desktop with the other two still running.

2. Start local. Local chat works without any extra keys. The cloud computers come from Boat, which the README lists as the project's sponsor; it needs your own Boat API key, and "Boat is a paid service after its trial, and using a cloud computer may incur charges." Composio needs its own key too. Skip both until you know you want them.

3. Run the trigger test with something harmless. In a test bot, ask: "Every 5 minutes, list the files in this folder and tell me how many there are." Then:

  • Watch for the trigger card in the chat. That is your only notice.
  • Open Triggers (first item in the sidebar). It lists every schedule and webhook, with a calendar and run history.
  • Let it run once while you watch. Did it ask before running the command? Note the answer.
  • Pause or delete it from the Triggers page.

Now you know how scheduled runs behave on your setup, instead of guessing.

4. Make the Triggers page a habit. Check it the way you would check a crontab on a server you share. Anything you do not remember asking for gets paused. Set an Advanced run limit on any routine that touches a shell or a connected app, since nothing stops a stuck run otherwise.

5. Mind where keys live. If you set up through the terminal with API keys, the README is upfront: keys are "saved as plaintext, not encrypted, in private config.json (0600 on Unix)." That file permission keeps other users on the machine out, not software running as you. Prefer the CLI logins you already have.

6. Decide on analytics. Usage analytics are optional and, per the README, anonymous counts that never include keys or conversations. Turn them off in Settings, General, Usage analytics if you prefer.

Honest limitations

The project calls itself "Early but real," and that is fair. Hosted and mobile connectivity are still being built. Webhook triggers need the app running to receive anything. Ubuntu support is beta, and Windows own-computer control is not in its capability table.

The stars and the attention are fresh. A young repo drawing this much attention has had little time for outside security review, and a version number like v0.1.141 tells you how fast it is changing. Pin a version you have tested.

Running real agent CLIs means real agent risks. Each bot can do what Claude Code, Codex or Grok can do on the computer you give it. The approval cards help, but they are the project's own guardrail on top of three different vendors' tools, each with its own permission model.

The business layer is visible if you look. Boat is a sponsor and the paid default for cloud computers. The enterprise/ folder has a different license. The v0.1.141 release notes mention paid Cloud and Starter plans, with Starter capped at five bots, and a Full access cap of 25 connected-app messages a day. Read the separate enterprise/LICENSE before touching that folder. None of that is hidden, and none of it is required for local use, but it is worth knowing which parts are free before your bots depend on them.

And the main point of this piece rests on README wording I could read, not a test I could run. The trigger behavior is exactly as documented: created without confirmation, shown as an undoable card. What scheduled runs do with risky actions is the open question, which is why step 3 exists.

The choice

You can treat OpenMausBot like a chat app: open it, talk to bots, close it. In that mode the approval cards do their job, because you are there to tap them.

Or you can treat it like what it also is: a scheduler that can start agent processes on your machine and in the cloud, created by the agents themselves. In that mode the screen that matters is not the chat. It is the Triggers page.

Open it once a day. It takes ten seconds.

Sources: OpenMausBot README at commit dd64479 (reviewed November 5, 2026, latest release v0.1.141); OpenMausBot releases; LICENSE; Trendshift daily board, read about 15:15 ET.