Clawdbot, known today as OpenClaw

Clawdbot, known today as OpenClaw

If you are looking for Clawdbot, the project still exists under a different name. In January 2026 it became Moltbot first and, three days later, OpenClaw. It is the same thing: a personal assistant running on your own hardware that does more than answer, it carries out tasks.

Why two renames in one week

The first rename came from a trademark concern. Anthropic pointed to the phonetic similarity of the name and to a mascot evoking associations with their product, and the project's author renamed it Moltbot on 27 January 2026.

The second rename followed three days later, on 30 January, purely because the author found that the name Moltbot never quite rolled off the tongue. The name OpenClaw stresses the project's openness and keeps a nod to its original theme, while closing the run of renames. The project then moved under an independent foundation, which means development led by the community rather than one person.

Knowing this helps when hunting for material. Plenty of guides and posts describe the old name, and installation commands from that period usually no longer work. For troubleshooting, search under the current name and treat older material as a description of the idea rather than an instruction.

What this assistant actually is

The difference from an ordinary chat is that the tool acts. It will read a message, check a calendar, draft a reply, look something up, run a command on your machine. You usually talk to it through a messenger you already use rather than a separate browser tab.

The second difference is where it runs. The assistant starts on your computer or server, so message contents and files do not travel through somebody else's infrastructure beyond the model calls you cannot avoid anyway. For some use cases that is the only acceptable arrangement.

The third is the pace of adoption. The project gathered over a hundred thousand GitHub stars within weeks, and by August 2026 it holds more than three hundred and eighty thousand, placing it among the fastest growing open source efforts around. That popularity cuts both ways: plenty of material and plugins, and plenty of low quality guides and impersonation scams.

How it works in practice

A typical scenario runs like this: you message the assistant, it does the task and replies when finished. The tasks are the kind nobody wants to do by hand and that are too small to justify building an automation.

Going through an inbox and listing what needs a reply. Checking tomorrow's calendar for conflicts. Looking something up and returning a summary instead of ten links. Running a script on a server and reporting the result. Filing a note where you will actually look for it later.

The language model handles understanding the request and choosing an action, the tools handle execution. You can attach your own functions, so the scope is bounded by what you can describe rather than by a list of prebuilt integrations.

How you phrase a request matters too. A specific instruction naming the scope and the expected result produces a predictable outcome, while a vague "sort out my inbox" leaves the assistant to decide what the task even covers. With a tool that actually performs actions, that difference weighs more than in an ordinary chat, since misreading intent ends in a completed action rather than merely an off target answer.

Set expectations. This is a tool for supporting tasks, not for processes where an error is expensive. The assistant sometimes misreads a request, and with broad permissions such a mistake has real consequences.

Security, the most important part of this setup

This section matters more than configuration, because we are talking about a tool with access to your messages and the ability to run commands. The project's visibility also drew attention from people looking for easy targets.

First rule: do not expose an instance on a public address without authentication. An agent with shell access and an open port is not a vulnerability, it is an invitation.

Second: keep permissions minimal. A separate system account, access only to named directories, no keys to services the task does not need. An agent that can read email does not also need access to repositories and a wallet.

Third: beware of external content. A message, a web page, or a document can carry instructions aimed at the model rather than at you. That is a real class of attack against agents reading somebody else's correspondence, so treat everything read as data rather than as a command.

Fourth: download only from the official source. Impersonating packages and pages have appeared around the project, and installing a tool with these permissions from a random source ends badly.

Fifth: start in read only mode. Let the assistant read and propose first, and grant it the right to act only after a few days. That is the cheapest way to see how it interprets your requests.

Installation and configuration

Installation needs a runtime, a model key, and a configured communication channel. The project gives two routes: a package from the npm registry or an install script from the project site.

npm install -g openclaw@latest

Since the name and the commands changed within a short window, take the remaining commands from the project's current documentation rather than from articles describing earlier versions. That applies especially to an install script fetched from the network: running one unread is exactly the habit the previous section warns about.

curl -fsSL https://openclaw.ai/install.sh -o install.sh
less install.sh
bash install.sh

A sensible order runs like this. Start the assistant locally first and talk to it with no tools attached, to check it works at all. Then connect one communication channel, ideally the one you use most. After that, add tools one at a time, checking after each whether the assistant uses it as you intended.

Store keys in environment variables or a secret manager, never in a configuration file that reaches a repository. That rule applies everywhere, but it carries extra weight here, because the assistant reads files in the directory it works in.

sudo useradd --system --create-home --shell /usr/sbin/nologin assistant
sudo install -o assistant -g assistant -m 600 /dev/null /home/assistant/.env

printf 'ANTHROPIC_API_KEY=%s\n' "$KEY" | sudo -u assistant tee /home/assistant/.env >/dev/null

A separate system account with no login shell is cheaper here than any later repair. An assistant running under your account has access to everything you do, including repository keys and saved browser sessions.

Turn on a record of what the assistant does from the start, and store it separately from the tool itself. A log listing completed actions answers why something happened, and with a tool working in the background there is nothing but guesswork without it. While you are at it, decide how long you keep those logs, since they hold request text and therefore fragments of your correspondence.

When running it on a home server, consider a container. Process isolation limits the blast radius of a mistake and makes removing the whole thing easy once the tool is no longer needed.

docker run -d --name assistant \
  --read-only \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  --tmpfs /tmp \
  -v /srv/assistant/data:/data \
  --env-file /home/assistant/.env \
  assistant-image:pinned-version

The first four switches do most of the work here. A read only filesystem, dropped kernel capabilities, and blocked privilege escalation mean that even a successful entry into the process yields little. The only writable directory is the one you named yourself.

What it costs

The project itself is open source and free. You pay for the language model, and the bill depends on how often you talk to the assistant and how long the contexts you pass are.

The order of magnitude for daily use on supporting tasks is a few to fifteen dollars a month on a mid tier model. The bill grows quickly on two things: a long conversation history passed on every call, and multi step tasks where each step is a separate call.

Two things cut cost most effectively. Routing simple requests to a cheaper model, since a meeting reminder does not need the strongest one available. And limiting the history the assistant receives with each question to what is genuinely needed.

Add hardware to the bill if you run this on a separate machine. A small server suffices, because model computation happens at the provider anyway, unless you choose a local model through Ollama, which turns the bill into a hardware cost.

What this story teaches beyond the rename itself

This case makes a good study for anyone considering building a process on a young open source project, and three lessons come out of it.

A name is not guaranteed. A project leaning on association with somebody else's brand can be forced to change, and along with the name go package addresses, installation commands, and configuration directory names. If you wire such a tool into an automation, pin a specific version and decide who reviews changes before an upgrade.

Popularity attracts fraud. Around a project gaining tens of thousands of stars a week, packages with deceptively similar names appear, along with pages whose instructions lead to modified code and tutorial videos that install something extra on the side. The rule is simple: take the repository address from one known source and do not click links from comments.

A change of steward is a signal rather than a problem. Moving under a foundation usually means steadier development and less risk of the project vanishing along with one person's interest. What is worth checking is how the release process works, since that decides whether upgrades stay predictable.

With tools holding permissions this broad, one more rule applies: a new version means new permissions. An upgrade can add an integration or widen access, so reading the change list before installing is more justified here than with an ordinary library.

OpenClaw against the alternatives

These tools do not exclude each other. A common arrangement pairs a flow handling the repeatable part of a process with an assistant invoked where the request comes from a person and reads differently every time.

The split runs along the question of repeatability. Tasks you perform the same way every week are cheaper and safer described as a flow. Tasks phrased differently each time suit an assistant that understands a request in natural language.

Common mistakes

The first is granting full permissions immediately. An agent with access to everything on first run is the simplest route to an expensive lesson.

The second is installing from a random source. After the renames, plenty of packages and guides circulating online pretend to be the original.

The third is treating external content as commands. A message from an unknown sender can carry an instruction aimed at the model, and an agent reading mail will execute it unless something stops it.

The fourth is having no logs. Without a record of what the assistant did and why, diagnosing odd behaviour comes down to guessing.

The fifth is leaving the assistant without a spending cap. A task stuck looping on an error can call the model endlessly, and you will see the result on the invoice. A limit set at the model provider is the simplest safeguard here.

The sixth is relying on it for anything with a deadline. The assistant can misread a request or stall on an error, so a reminder about a doctor's appointment belongs in a calendar as well.

FAQ

Does Clawdbot still exist?

Yes, as OpenClaw. The project was renamed twice in January 2026: first to Moltbot after a trademark concern, then to OpenClaw to end the confusion. The code and the idea stayed the same, and an independent foundation took over stewardship.

Is it free?

The code is open source with no licence fees. You pay for language model calls, usually a few to fifteen dollars a month with daily use, plus optionally hardware if you run it on a separate server.

Does my data leave my machine?

The assistant runs on your hardware, so files and messages do not pass through somebody else's infrastructure. What does leave are the fragments sent to the language model, since that is where request understanding happens. Full locality requires a model running on your own machine.

Is it safe?

That depends on configuration. A tool with shell access and access to your messages is exactly as safe as you set it up to be. The minimum is no public access without authentication, restricted permissions, an official installation source, and treating external content as data rather than commands.

Is it suitable for work?

For supporting tasks yes, for business critical processes carefully. With customer data and compliance requirements, first consider whether agent access to that data is permissible at all, and for repeatable processes check whether a flow in n8n would be cheaper and more predictable.

The current code and documentation sit in the project repository, and the rename history is described in the Wikipedia article.