OpenClaw GitHub Stars Growth

OpenClaw·Moltbook·Claude·VPS·Docker

The Viral Moment Nobody Expected

Peter Steinberger built OpenClaw over a weekend. By Wednesday, it had 100,000 GitHub stars. By Friday, security researchers were hunting vulnerabilities. By Sunday, attackers had published malware impersonating it.

This isn’t a typical open-source story. This is what happens when a genuinely useful tool meets pent-up demand for autonomous AI—and the security community pays attention.

Steinberger isn’t an unknown developer. He built PSPDFKit, the iOS PDF framework used by thousands of apps. When he released an AI agent that runs locally, connects to your existing chat apps, and actually does things without constant prompting, people noticed.

The name changed three times in a week—Clawd, then MoltBot, then OpenClaw—partly because Anthropic’s lawyers came knocking (trademark similarity), partly because the project kept evolving. Each rename came with a blog post explaining the reasoning. This transparency is part of why the project gained trust so quickly.

What OpenClaw Actually Does (And Why It Matters)

Most AI chatbots wait for you. OpenClaw keeps running.

It sits on your laptop, VPS, or Mac Mini, connects to WhatsApp or Slack or Discord, and handles tasks autonomously. It can read files, execute commands, send messages, and maintain context across conversations. You give it API keys for Claude or OpenAI, and it uses those models to decide what to do.

The pitch is compelling: your data stays on your hardware, you control the infrastructure, no SaaS vendor can change terms or disappear.

This matters because the alternative—platform-dependent AI tools—keeps showing fragility. Anthropic’s January 2026 enforcement against third-party clients broke popular tools like OpenCode overnight. When platforms control access, they can revoke it. OpenClaw sidesteps this entirely.

But “local-first” shifts the security burden from vendor to user. And that’s where things got interesting.

The January Incidents: A Compressed Timeline

OpenClaw’s first week included more security drama than most projects see in years:

DateWhat Happened
Jan 27Fake “ClawdBot Agent” VS Code extension published. It worked—actually controlled agents—while also installing ScreenConnect remote access software. Aikido Security confirmed the payload.
Jan 30-31Security researchers found exposed OpenClaw gateways all over the internet. Default configurations bound to all interfaces. Pillar Security documented real attack traffic.
Jan 31Moltbook—an agent-only social network built on OpenClaw—suffered a database breach. 32,000 agent credentials exposed through a Supabase misconfiguration.

Three incidents. Three different attack vectors. One week.

This isn’t FUD. These are documented, verified incidents with technical analysis from security vendors. They happened because OpenClaw’s architecture creates genuine security challenges—and because its viral growth outpaced security guidance.

The Core Tension

OpenClaw is powerful because it has access: to your files, your chat apps, your API keys, potentially your command line. That access is the point. An agent that can’t do anything isn’t useful.

But access without isolation is dangerous. The incidents of January 2026 proved that attackers recognized this immediately.

The supply chain problem: OpenClaw extends via “skills”—downloadable instruction bundles. Installing a skill is functionally running arbitrary code. The fake VS Code extension showed that attackers will impersonate official channels within days.

The exposure problem: Running a web dashboard on your local machine sounds safe, but default configurations often bind to all network interfaces. Researchers found gateways exposed to the internet with weak or bypassed authentication.

The platform problem: Moltbook’s “fetch-and-follow” architecture means agents periodically download and execute instructions from the internet. When Moltbook’s database was exposed, attackers could have influenced any connected agent’s behavior.

These aren’t implementation bugs. They’re architectural tradeoffs. OpenClaw’s documentation acknowledges many of them openly—prompt injection is described as “unsolved,” skills come with warnings about arbitrary code execution.

What We Learned Running It

We’ve been testing OpenClaw internally with aggressive isolation:

  • Dedicated VPS, no access to production systems
  • Container with read-only filesystem
  • Separate “burner” agent for Moltbook experimentation
  • Custom logging wrapper tracking every decision

The honest assessment: It’s genuinely useful for prototyping and experimentation. The ability to connect an agent to existing chat infrastructure, give it file access, and let it run scheduled tasks—this is what many developers have been trying to build.

But we wouldn’t run it on production systems. Not yet. The risk surface is too broad, the mitigation tooling too immature, and the incident timeline too compressed to trust for anything critical.

The Economic Context

There’s a reason OpenClaw exploded. Anthropic’s $200/month Max subscription provides unlimited Claude Code usage. The equivalent API consumption would cost heavy users $1,000+ per month.

When Anthropic blocked third-party harnesses in January 2026, demand didn’t disappear. It shifted to self-hosted alternatives that use direct API access—removing the platform tax entirely.

OpenClaw is free (MIT license). You pay only for API usage and infrastructure. But “free” doesn’t mean “no cost.” The security overhead is real: isolation, monitoring, approval workflows, ongoing vigilance against supply-chain risks.

Where This Goes

OpenClaw represents something important: proof that local-first, user-controlled AI agents are possible and desirable. The viral growth proves demand. The security incidents prove that demand is outpacing safety practices.

The question isn’t whether tools like OpenClaw will exist. They will. The question is whether the ecosystem develops security practices fast enough to match the capability growth.

What would help:

  • Deterministic prompt injection defenses (currently probabilistic)
  • Cryptographically signed skills with verification
  • Built-in approval workflows for high-risk operations
  • Comprehensive audit logging by default
  • Independent security audits of the codebase

What’s happening now: The project is iterating fast. The community is engaged. Security researchers are finding and reporting issues. This is how open-source security improves—publicly, messily, but ultimately effectively.

Our Take

Use OpenClaw for experimentation. Use it in isolated environments. Use it to learn how autonomous agents behave, to prototype workflows, to understand the future of AI infrastructure.

Don’t use it for production systems. Don’t use it for sensitive data. Don’t use it anywhere that unauthorized messages or file modifications would cause real harm.

The tool is powerful. The risks are real. The gap between those two facts is where thoughtful deployment decisions live.

Sources

Primary sources:

  • OpenClaw announcement and documentation (openclaw.ai, docs.openclaw.ai)
  • Creator statements and blog posts

Security analysis:

  • Aikido Security: Fake VS Code extension malware analysis
  • Pillar Security: Gateway exposure findings
  • 404 Media: Moltbook database breach reporting

Technical commentary:

  • Simon Willison: Fetch-and-follow pattern analysis
  • OWASP Top 10 for LLM Applications

Last updated: February 1, 2026. This analysis reflects verified incidents and documented architecture. We’ll update as the project evolves.