What happened
OpenMausBot’s supplied release material describes two closely sequenced releases: 0.1.136 on October 31, 2026, and 0.1.137 on November 1. The earlier release adds the ability to share bots with teammates one bot at a time. The material names three permission levels: view, chat, and edit. It also says people can request access from within the application. It does not define what each permission permits beyond its label, nor does it describe the approval process.
The same 0.1.136 release adds MausBot Cloud with a Team mode for shared bots. It includes localized notices about runs and routines for each person, and it says initial answers in long conversations arrive faster. These are product-facing changes: collaboration becomes an explicit part of the workspace rather than an implied use case for an individual desktop agent. But the available material does not quantify the speed improvement, identify a supported team size, or state the conditions for using the hosted service.
Version 0.1.137 addresses a visible compatibility failure introduced after the prior update. A window could show only the rail of places and an otherwise empty page when the desktop application had updated to 0.1.136 while its Cloud page had not. The release says the application now retains a piece that older Cloud pages still request, so those pages can open normally regardless of which Cloud version is active. This is a practical repair for version skew between a client and a hosted component.
The 0.1.137 notes also change several operating behaviors. A failed update check now counts once, and its notice stays visible during quiet hourly checks. A one-on-one goal whose turn repeatedly loses its slot now ends as blocked at the wait cap instead of retrying indefinitely. MausBot notification tools now refuse to operate in any shared workspace, rather than only in a Team Cloud workspace. The release also moves the Mac build to macOS 15 and retries stapling up to six times; the notes cite GitHub’s retirement of macOS 14 on November 2 as the reason for the runner change.
Taken together, the releases do not merely add a sharing control. They combine a new collaborative surface, a hosted team mode, restrictions on a tool category in shared contexts, and a follow-up compatibility repair. The source establishes those shipped changes, but not their adoption, performance, or commercial terms.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This release modestly supports Agent-ready software exposes capabilities. Sharing an individual bot under named permission levels makes a product boundary observable, while refusing notification tools in shared workspaces makes one behavioral limit explicit. The evidence is narrow: it is one project’s release note, not proof that this model has become standard practice or that its controls are sufficient.
Why now
The timing is explained by the release sequence. The sharing and Team mode changes arrived in 0.1.136, then 0.1.137 followed the next day to repair a blank-window failure caused by an app-and-Cloud version mismatch. Separately, the Mac build moved to macOS 15 because GitHub was retiring the macOS 14 runner on November 2. The source does not state a broader market reason for the Cloud launch.
Why it matters
Teams building agent products often discover that “shared” is not a single feature. Someone may need to inspect a bot without changing it, converse with it without editing its configuration, or administer it without exposing every tool action in a collaborative context. OpenMausBot’s view, chat, and edit labels make that decomposition visible, even though the release does not document the complete enforcement model behind them.
The change to notification tools is equally instructive. Once a workspace becomes shared, a tool that sends notices can affect more people than its initiating user. Refusing that class of tool in shared workspaces is a product decision about safe defaults, not merely a UI preference. Builders should identify which agent capabilities change meaning when ownership, visibility, and responsibility are distributed across a team.
The blank-window fix is a second, less glamorous lesson. A desktop agent and a hosted service can update independently, and collaboration features will not help users if an older web surface cannot render after a client update. Compatibility across those boundaries belongs in the product contract.
What happens next
- OpenMausBot will add or clarify further shared-workspace controls as Team mode matures (6 months, 55%). Watch for: release notes naming additional roles, approval settings, or workspace policies.
- The project will continue shipping compatibility fixes for independently updated desktop and Cloud components (3 months, 65%). Watch for: releases that mention Cloud-version handling, migration, or rendering compatibility.
Limits and uncertainty
The release notes do not provide pricing, usage limits, supported team sizes, or a general-availability statement for MausBot Cloud Team mode. They do not explain whether access requests require an administrator, whether roles are customizable, or how permissions interact with a bot’s tools and virtual machine. The claim of faster first answers has no measurement, test method, or baseline. The source also does not say how many users encountered the blank-window problem, whether every client-and-Cloud version pairing is covered, or whether notification-tool refusal applies to all future shared workspace types.
Skill to build now
Map one agent in your own product into discrete collaboration capabilities this week. Write down who can view its state, send it work, edit its configuration, and trigger outward-facing tools such as notifications. Then test an intentionally mismatched client and backend version, if your architecture permits independent deployment. The point is not to copy OpenMausBot’s exact roles; it is to expose the permissions and compatibility assumptions that otherwise remain implicit until a team begins sharing agents.
Reader takeaway
OpenMausBot’s paired releases show the practical cost of making an agent workspace collaborative. Per-bot roles, explicit restrictions for tools in shared contexts, and tolerance for Cloud-client version skew are all part of the same product problem. The source demonstrates implementation choices, not that they are complete or broadly validated.