Openclaw renames to clawdbot, ships 2026.1.5 through four hotfix bumps
January 4 was the name-change day. The public-facing product had been “openclaw” through the end of 2025, but the bot identity inside the daemon had already drifted toward “clawdbot” in support tickets and issue threads. Today I pulled the commit stream in line with where the users were already calling it. A rename mid-cadence is always messier than it looks on paper, and the chase-tail hotfix sequence that followed proved the point.
Signal
Project rename: openclaw -> clawdbot in the commit stream, with version references refreshed repo-wide Four appcast bumps in one day: 2026.1.5, 2026.1.5-1, 2026.1.5-2, 2026.1.5-3, meaning four hotfixes chained off one release Mac packaging now defaults to notarize, which is the right polarity once you ship to non-developer users
Evidence
openclaw (170 commits, +34,962 / -21,409): project rename to clawdbot, 2026.1.5 release bump, appcast hotfixes 1/2/3 Packaging: default mac notarize ON, homebrew added to sandbox image, pkg-config + libasound2-dev for Linux sandbox Protocol regens: Swift models refreshed, GatewayModels regenerated, module cache ignored Settings UI: sidebar layout adopted, toolbar overflow fix, custom editor formatted
170 commits with +34,962 / -21,409 tells you the rename touched surface area far beyond “find-and-replace.” Version strings live in a dozen places that don’t grep cleanly: embedded Swift constants, appcast XML, CI configuration, changelog frontmatter, docs cross-links. The Swift model regen commits are a tell that the rename reached down into the protocol layer, which is where you don’t want a half-applied rename to linger.
The four appcast bumps in one day are the part I’d rather not have shipped but am glad I did ship. 2026.1.5 went out, then 2026.1.5-1 a few hours later when a platform-specific packaging bug surfaced. Then -2 when the auto-updater refused to recognize the hyphenated version on a fraction of mac builds. Then -3 to fix a changelog entry that was wrong. Each of those is a release-engineering papercut, and each of them is the kind of thing that makes a runbook more honest. I updated the runbook in place; next rename won’t have a four-bump tail.
Defaulting mac to notarize is the long-lead fix. Without notarization Gatekeeper shows a terrifying modal to every new user on first launch, and the only people who click through it are developers who already trust the repo. That’s everyone currently. It’s not going to be everyone soon. Flipping notarize to the default before the user surface grows means the next wave of installs gets the right experience from the first click.
So What
This is what a name change looks like when it lands mid-cadence. You bump once, discover four bugs in the next 12 hours, and ship again Defaulting mac to notarize pre-empts the “it runs on my box” TCC nightmare. Correct call, right before public visibility hits
The sandbox image progress is the quiet part that’s going to matter most in two weeks. Homebrew in the sandbox image means the daemon can install CLI tools at runtime without escaping the sandbox. pkg-config and libasound2-dev on Linux mean audio-aware workflows actually work when a user says “build something that uses sound.” These are the additions that unlock user stories I haven’t gotten to yet but expect to hit by mid-month.
What’s Next
Four appcast bumps on day three is either a confidence-regression or a test-gap. Is the release runbook catching crashes in CI or in user downloads? If it’s user downloads, the next priority is getting a smoke-test bench that actually exercises the auto-updater on each target platform before the appcast goes live. Cheaper than the hotfix tail every time.
Log
- Sessions: 0 (bloomnet.db lag, evidence from live git)
- Top repos: openclaw (170)
- Commits: 170 across 1 repo (+34,962 / -21,409)
- Notable: project rename to clawdbot, mac notarize default, 4x hotfix chain
- Cost: not tracked (pre-bloomnet-ingest window)