This week has been the week of the lobster. The red crustacean avatar cropping up in screenshots of people controlling their computers via WhatsApp, automating their inboxes, and generally making AI do their bidding has become impossible to ignore.
When I first saw the demos, I was sceptical. “Another AI wrapper,” I thought. “Probably impressive for about ten minutes before you hit the rough edges.” Then I actually dug into it; tried to install it on an older machine, read through the GitHub repo, pored over the security write-ups—and my opinion shifted slightly. Not to uncritical enthusiasm, but to genuine interest.
Clawdbot (now officially Moltbot after Anthropic’s lawyers presumably had a word) isn’t just another chatbot with delusions of grandeur. It’s a fundamentally different approach to personal AI assistants. And whether that’s exciting or terrifying probably says more about your relationship with computers than about the product itself.
One important note before we go further: Moltbot is explicitly independent and not affiliated with Anthropic. [1][4] The rename happened, but the architecture is its own thing entirely.
What follows is my attempt to cut through the hype and give you a practical sense of what this thing actually is, what it can genuinely do, and—crucially—where it might bite you if you’re not careful. [1][2][3][4][8]
Table of contents
Open Table of contents
- Why everyone’s talking about this lobster
- How it actually works (the architecture bit)
- What actually delivers value versus what’s mostly hype
- My experience on older hardware (and what you’ll probably hit too)
- The gotchas that’ll actually bite you
- How Moltbot differs from just giving other AI models access to your accounts
- My verdict: worth exploring, but treat it like infrastructure
- Over to you
- References
Why everyone’s talking about this lobster
At the marketing layer, Moltbot pitches itself as “the AI that actually does things”: clears inboxes, sends emails, manages calendars, checks you in for flights—through chat apps you already use. [1]
But, what actually makes it interesting (and why I think it went viral): it’s an always-on, self-hosted assistant runtime that you control via WhatsApp, Telegram, Discord, Slack, Signal, iMessage, or a web dashboard. [1][3]
Two things stand out:
First, the interaction model is genuinely clever. You don’t need to remember to go open the AI app. You just message your assistant in the same place you message actual humans. Wired describes users routing requests through WhatsApp and Telegram and automating everything from schedules to invoices—framing it as an assistant that runs constantly and handles a much wider range of tasks than mainstream assistants. [2]
Second, this isn’t trying to be a polished consumer product. It’s openly infrastructure for power users. The GitHub README positions the “Gateway” as a control plane, not just a chatbot interface. [3]
That blend—consumer-simple interface, developer-grade authority—is also why security folks are nervous. The same capabilities that make it feel like Jarvis also make it trivially easy to misconfigure into a disaster. [4][7][8]
For context on the “viral” claim: as of 29th of January 2026, the GitHub repository shows roughly 92,500 stars and 12,700 forks. [3] That’s not nothing.
How it actually works (the architecture bit)
If you strip away the lobster branding, the key design choice is architectural: a single long-running Gateway process acts as the system’s control plane, coordinating chat channels, tools, UI, and device nodes. [3][5]
The official README includes a short architecture diagram that’s surprisingly revealing: chat surfaces flow into the Gateway, which then coordinates runs via the Pi agent runtime, CLI, WebChat UI, companion apps, and mobile nodes. [3]
Here’s a simplified representation, derived from the official repo and protocol docs:
The important bit: Moltbot isn’t a single agent. It’s a control plane plus multiple clients, all speaking the same Gateway WebSocket protocol. The protocol docs describe the Gateway WS protocol as the single control plane and node transport, with clients declaring role and scope at handshake time. [5]
The UIs are more important than people think
Moltbot has two distinct UIs that change how usable it feels day to day:
The Control UI is a browser SPA served directly by the Gateway (Vite + Lit), typically on http://<host>:18789/, speaking to the Gateway WebSocket on the same port. [5]
In practice, it’s a live operations console. The docs list what it can do: chat, view streaming tool output, manage channels (including QR login flows), sessions, cron jobs, skills, nodes, exec approvals, config editing with schema-based forms, log tailing, and even running updates. [5]
That’s not nice-to-have. It’s how you keep the system safe and predictable once you start adding channels and tools.
Then there’s WebChat, which is essentially the Gateway chat UI operating over the same WebSocket methods (chat.history, chat.send, chat.inject). The docs emphasise deterministic routing: replies go back to WebChat, and it becomes read-only when the Gateway is unreachable. [5]
If you only use WhatsApp or Telegram, you can ignore both. But if you’re trying to run this like dependable infrastructure (especially with cron and skills), the Control UI becomes your cockpit.
Capabilities depend on tools, not vibes
A recurring misconception in the social hype is that Moltbot is “one model with magic integrations.” It’s actually more modular than that.
Moltbot exposes first-class typed tools (browser, canvas, nodes, cron, gateway operations, session tools, and more) and explicitly positions these as replacements for older shell-based skills. [3][5]
That distinction matters: the product is moving toward typed, policy-controlled invocation rather than “just run bash and hope.” (It still has shell execution; it’s just not the sole abstraction.) [5]
What actually delivers value versus what’s mostly hype
The official site’s “What It Does” section compresses several deep ideas into six tiles: runs on your machine, works in chat apps, persistent memory, browser control, full system access (or sandboxed), and skills/plugins. [1]
Let me unpack where it consistently delivers value when configured well.
The “remote control for your computer” bit is genuinely useful. Moltbot turns your machine (or server) into a remote-executable personal operations layer, reachable from your phone. That’s why people describe “building websites from bed,” running coding loops, or automating inbox triage while walking the dog. [1][4]
This isn’t because the LLM is uniquely brilliant. It’s because the Gateway + tools model removes the last mile between suggestion and execution. Wired’s reporting is blunt: normal assistants are constrained; Moltbot can do a near-limitless range of tasks because it can coordinate apps, code, and web activity through your own machine. [2]
Persistent, user-controlled state is the second real capability. The system stores “who it is” and “how it behaves” in files (the Wired piece mentions a persona stored in Soul.md; the official README also treats workspace prompt files and skills as on-disk artefacts). [2][3]
MacStories makes the same point with a metaphor engineers will appreciate: it’s like a local-first app where the cloud is just the model provider; the controllable state lives on disk and can be edited directly or via the assistant. [6]
The third real capability is orchestration. Sessions, routing, and multi-agent patterns. The repo and docs describe a session model (main vs group isolation), multi-agent routing, and explicit session tools for cross-session coordination. [3][5]
In practice, this is what makes it feel less like “a chatbot with plugins” and more like “a system you can delegate to.”
The hype part is mostly about autonomy. Some users do run it in high-agency mode (scheduling, purchases, inbox automation), and Wired documents people giving it high-stakes access like credit cards—followed by the predictable “that’s cool and terrifying” whiplash. [2]
But autonomy isn’t binary. Moltbot has real mechanisms that let you dial this in: DM pairing policies, allowlists, tool allow/deny, tool profiles, sandboxing modes, and exec approvals. [3][5]
If you ignore these and run “YOLO agent on the open internet,” you’re not using Moltbot incorrectly—you’re using it exactly as attackers hope you will.
My experience on older hardware (and what you’ll probably hit too)
I tried Clawdbot on an older machine, and I suspect my experience maps to what most people encounter. The failure modes cluster tightly enough that it’s worth walking through.
The official happy path is:
Install → run onboarding wizard → start Gateway → open dashboard → connect a chat surface → approve pairing → iterate. [3]
What tends to make older hardware painful isn’t model inference (since most people route LLM calls to Anthropic, OpenAI, or similar), but the “real computer” parts: Node runtime, browser automation, image/audio handling, sandboxes/containers, and always-on processes.
Installation friction comes first. Moltbot’s official requirements start at Node 22 or higher, and the docs strongly recommend Windows via WSL2 rather than native Windows due to tool compatibility issues. [3] If your device is old enough that upgrades are brittle (older Linux distros, older macOS, locked-down corporate endpoints), you feel this immediately.
Then you hit the PATH problems. The install docs explicitly call out the “CLI installed but command not found” issue as a PATH problem with global npm binaries. [3] On older machines, you also see more native dependency friction. The installer docs mention sharp installation issues and explicitly default to SHARP_IGNORE_GLOBAL_LIBVIPS=1 to avoid linking against a system libvips. [3]
That’s a strong signal: even the official scripts anticipate native build problems.
Once it’s running, performance issues show up in three places:
The Gateway and channels stack. Running WhatsApp/Telegram connectors reliably is one reason the docs warn against Bun in those cases and recommend running the Gateway with Node for those channels. [3]
Browser control. Browser automation is inherently heavier than API calls. Moltbot supports dedicated browser control and can do form filling and extraction, but anything browser-heavy will amplify weakness in CPU/RAM/disk and is less forgiving on underpowered boxes. [3][5]
Costs and latency. The other “performance” bottleneck isn’t your CPU—it’s the LLM provider. MacStories documented burning an extreme number of tokens while experimenting, and both Wired and Prompt Security note that users can run up high bills while the agent reasons, loops, and does background work. [2][6][9]
On older hardware, that pain doubles: slower local steps stretch agent loops, which can inflate token usage because the system spends longer in “think → tool → analyse → tool” cycles.
If you want Moltbot on older hardware and you want it to feel fast, the most pragmatic pattern is to treat the older box as a dedicated Gateway host and keep your high-agency work constrained to explicit tools and sessions. The official docs explicitly support running the Gateway on a small Linux instance and connecting clients over Tailscale or SSH tunnelling; device nodes handle device-local actions when needed. [3][5]
The gotchas that’ll actually bite you
The list below is intentionally short and operational. These are the failure modes that most often turn “it’s magical” into “why is this fighting me?”
Status date: 29th January 2026.
| Gotcha | What you’ll see | Why it happens | What to do |
|---|---|---|---|
| Node version mismatch | Install works, but runtime errors or tool incompatibilities | Moltbot requires Node 22+ and tools assume modern Node behaviour [3] | Upgrade Node; on Windows follow WSL2 guidance [3] |
moltbot not found | New terminal can’t find the command | npm global bin directory not on PATH [3] | Add the npm prefix bin path to your shell PATH [3] |
| Linux npm EACCES | Global install fails with permission errors | npm global prefix points to root-owned directories [3] | Use the installer (it can switch npm prefix to ~/.npm-global) [3] |
sharp / libvips friction | Native build failures during install | sharp tries to link against system libvips; toolchain mismatch is common [3] | Use SHARP_IGNORE_GLOBAL_LIBVIPS=1 (default in installer) [3] |
| Bun with WhatsApp/Telegram | Channels flake or fail in non-obvious ways | Docs warn Bun has known issues with these connectors [3] | Run the Gateway with Node for those channels [3] |
| Bot doesn’t reply in DMs | You DM it; silence | Default DM safety: unknown senders are gated via pairing codes [3] | Approve pairing via CLI and keep allowlists tight [3] |
| Control UI won’t auth over HTTP | Dashboard loads but can’t establish session | Insecure HTTP contexts block WebCrypto [5] | Use local 127.0.0.1, or HTTPS via Tailscale Serve [5] |
| Accidental public exposure | You expose ports; you now have an attack surface | Misconfigurations are common; security firms flagged exposures in the wild [7][9] | Prefer tailnet-only exposure + token/password auth; run moltbot security audit --deep [3][5] |
| Skills supply chain risk | A “helpful” community skill becomes a Trojan | Skill folders are trusted code; hijack risks are real [5][7] | Treat skills as code: audit, pin sources, sandbox non-main sessions [3][5] |
| Plain-text state on disk | Secrets and transcripts accumulate in predictable locations | Official security docs note this; 1Password stresses the problem [5][8] | Harden filesystem permissions, isolate the host, use dedicated accounts/vaults [5][8] |
If you only internalise one thing: Moltbot’s real setup hurdle isn’t installation. It’s safe deployment. Prompt Security makes this exact distinction and argues that many guides stop at “it runs” rather than “it’s constrained.” [9]
How Moltbot differs from just giving other AI models access to your accounts
This is the key comparison, and it’s where the “it’s just a wrapper” critiques miss the point.
Yes, you can give other models account access—often more easily. OpenAI’s GPT Actions support OAuth-based authenticated calls to third-party APIs, abstracting authentication so end users can request actions in natural language while the system performs API calls using configured auth. [10]
Google’s Gemini can use Workspace content across Gmail, Calendar, Docs, Drive, Keep, and Tasks, subject to admin and user controls. [11]
Anthropic has also moved toward connectors (including Microsoft 365) via MCP-style integration patterns.
But Moltbot is meaningfully different on four dimensions that matter in real operations: where execution happens, how state is represented, how control is enforced, and what you can audit.
| Dimension | Moltbot | ”Model with account access” assistants |
|---|---|---|
| Primary execution surface | Your machine/server via Gateway tools, with optional device nodes for local actions [3][5] | Provider-hosted execution via API calls/connectors; limited to what the provider supports [10][11] |
| Interface | Any chat app + Control UI; feels like messaging a colleague [1][5] | Usually a single first-party app/web UI, plus selected integrations [10][11] |
| State and personalisation | File-backed workspace + configurable prompts/skills; transparent and editable; persistent sessions on disk [3][5][6] | Vendor-defined memory and data access patterns; typically less transparent and harder to audit [10][11] |
| Control model | Identity gating, tool allow/deny/profiles, sandboxing modes, exec approvals, web exposure controls [3][5] | OAuth scopes and product permission systems; powerful but often coarse and vulnerable to indirect prompt injection [4][10][12] |
| Auditability | You can inspect config, logs, skills, and session history locally; Control UI supports log tailing and config forms [5] | Depends on vendor; logs and decision traces are often limited or unavailable [10][11] |
| Failure mode if compromised | Potentially catastrophic—shell/filesystem/browser privileges [4][5][8] | Potentially catastrophic—may exfiltrate connected account data or take authenticated actions; indirect prompt injection is a known risk [4][12] |
The cleanest way to summarise the difference:
Account-connected assistants are typically API-first: they do what the integration permits, in the environment the vendor provides.
Moltbot is environment-first: it’s an orchestration layer that can act inside your environment (files, shell, browser, devices) and can also talk to APIs. [3][5][6]
Security isn’t “better”, it’s more steerable
A common narrative is: “It runs locally, so it’s private and secure.” The official site does say “private by default—your data stays yours,” but the reality is more nuanced. [1]
Moltbot’s own security docs are unusually honest: the threat model includes arbitrary shell execution, file read/write, network access, and the fact that untrusted people can message you and try to trick the agent. The docs frame the philosophy as “access control before intelligence” and assume models can be manipulated, so you must limit blast radius. [5]
That’s the right framing—and it’s also why security professionals are alarmed. The Verge quotes Rachel Tobac warning that prompt injection becomes a practical hijack vector when an agent has admin access and can be reached via DMs. [4]
1Password’s analysis adds a very concrete risk: if your machine is compromised, Moltbot’s plain-text, predictable on-disk state (tokens, transcripts, context) can be exfiltrated quickly, and the context makes downstream impersonation and targeted attacks worse. [5][8]
The Register and Netskope both document real-world exposure and misconfiguration patterns (including internet-accessible instances and skill supply-chain concerns), reinforcing that “works locally” doesn’t mean “safe by default in the real world.” [7][9]
The forward-looking takeaway isn’t “don’t do this.” It’s that we’re watching the birth of a new security category: identity-bearing, always-on agents. Moltbot is early, but the shape is likely durable.
My verdict: worth exploring, but treat it like infrastructure
If you want a neat conclusion: Moltbot isn’t a better chatbot. It’s a new control surface for your digital life. And it goes viral because that’s exactly what people have been waiting for.
If you’re deciding whether it’s worth adopting, I’d frame it like this:
Moltbot is worth serious experimentation if you want an assistant that can (a) live where you already communicate, (b) hold persistent context you can inspect and shape, and (c) actually execute work through tools rather than stopping at advice. [1][3][5][6]
It is not worth running casually on a primary machine or anywhere near sensitive environments unless you’re willing to treat it like infrastructure: explicit identity controls, least-privilege tool policies, sandboxing where appropriate, safe remote exposure patterns, and ongoing audits. [3][5][8][9]
The most sensible mental model I’ve encountered is also the healthiest: provision it like a new hire. Dedicated machine or isolated environment, dedicated accounts, auditable permissions, and a clear boundary between “my identity” and “my agent’s identity.” [2][8]
Over to you
I’m genuinely curious whether anyone else has been experimenting with Moltbot—or any of the other personal AI assistants that are cropping up. The architecture here feels genuinely novel, and I suspect we’re going to see a lot more systems that blur the line between “chat interface” and “control plane.”
If you’ve tried it, I’d love to hear what worked, what broke, and whether the security concerns have put you off or just made you more careful. Drop me a message on LinkedIn if you’ve got a good story.
And if you’re still on the fence: the gotchas table above is probably the most honest assessment I can give. It’s a powerful tool, but it’s not a toy. Treat it accordingly.
References
- Moltbot — Personal AI Assistant — clawd.bot
- Moltbot Is Taking Over Silicon Valley — WIRED
- GitHub - moltbot/moltbot: Your own personal AI assistant — GitHub
- Moltbot, the AI agent that “actually does things,” is tech’s new obsession — The Verge
- Protocol - Moltbot (Gateway protocol / WebSocket) — docs.molt.bot
- Moltbot (Formerly Clawdbot) Showed Me What the Future of Personal AI Assistants Looks Like — MacStories
- Clawdbot becomes Moltbot, but can’t shed security concerns — The Register
- It’s incredible. It’s terrifying. It’s MoltBot. — 1Password Blog
- What Moltbot’s (Clawdbot) Virality Reveals About the Risks of Agentic AI — Prompt Security
- GPT Actions (Introduction) — OpenAI API Docs
- Turn Google apps in Gemini on or off — Google Support
- Compromised Google Calendar invites can hijack ChatGPT’s Gmail connector and leak emails — Tom’s Hardware
