1-Minute Migration Guide: How to Update Your Moltbot Repository to OpenClaw

The Problem

If you cloned the repository before January 30, 2026, your local Git remote still points to the old URL:

# Your current remote might look like this:
origin  https://github.com/moltbot/moltbot.git (fetch)
# or
origin  https://github.com/clawdbot/clawdbot.git (fetch)

This means you cannot pull the latest updates until you update the remote URL.

The Fix (30 Seconds)

Step 1: Update the Remote URL

Run this single command in your project directory:

git remote set-url origin https://github.com/openclaw/openclaw.git

Step 2: Verify the Change

Confirm the remote was updated:

git remote -v

You should see:

origin  https://github.com/openclaw/openclaw.git (fetch)
origin  https://github.com/openclaw/openclaw.git (push)

Step 3: Pull Latest Changes

Now you can fetch the newest code:

git pull origin main

Done! You're now on the latest OpenClaw codebase.

Configuration Files

Do I Need to Update My Config?

Mostly no. The configuration format is backward compatible.

However, we recommend:

1. Backup your current config:

   cp ~/.openclaw/config.json ~/.openclaw/config.json.backup
   

2. Compare with the latest template:

   openclaw config --show-template
   

3. Optional: Update to new structure New features may require additional config fields. The CLI will warn you if any are missing.

Config File Location Changes

The CLI automatically migrates your config on first run. No manual action needed.

Docker Users

If you're running via Docker, update your image reference:

Old:

image: ghcr.io/moltbot/moltbot:latest
# or
image: ghcr.io/clawdbot/clawdbot:latest

New:

image: ghcr.io/openclaw/openclaw:latest

Then pull the new image:

docker pull ghcr.io/openclaw/openclaw:latest
docker-compose up -d

NPM/CLI Users

If you installed via npm:

# Remove old package
npm uninstall -g moltbot

# Install new package
npm install -g openclaw

Or use the official installer:

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

Command Compatibility

Good news: all old commands still work.

The old commands are aliased internally. They'll continue working indefinitely, but we recommend switching to openclaw for new scripts.

Troubleshooting

"Permission denied" when pulling

If you have SSH key issues:

# Switch to HTTPS
git remote set-url origin https://github.com/openclaw/openclaw.git

"Repository not found"

Make sure you're using the correct URL. The old repositories redirect, but direct URL access may fail:

# Correct URL
https://github.com/openclaw/openclaw.git

# These no longer work directly
https://github.com/moltbot/moltbot.git  # ❌
https://github.com/clawdbot/clawdbot.git  # ❌

Config not migrating automatically

If your config didn't auto-migrate:

# Manual migration
mkdir -p ~/.openclaw
cp ~/.moltbot/* ~/.openclaw/
# or
cp ~/.clawdbot/* ~/.openclaw/

Common migration questions

When is changing the remote not enough

If you are not just failing on git pull, but also seeing these issues, the migration is broader than swapping the repository URL:

• local scripts still reference the moltbot image or old package name
• CI or deployment scripts still point at the legacy repository
• production config paths still live under ~/.moltbot/ or ~/.clawdbot/
• team docs still onboard new operators with old commands

In that case, split the migration into four checkpoints: repository remote, runtime image, CLI install, and config path.

Who should read this guide first

This page is most useful for high-intent operators who are:

• unable to pull the latest code before or after openclaw install
• upgrading an old Moltbot or Clawdbot environment into OpenClaw
• still referencing old Docker image tags during upgrade
• debugging why new docs and local commands no longer match

If you arrived from the 2026.3.13 release note or CLI regression page

GA4 for 2026-05-12 shows this migration guide and /zh/news/openclaw-2026-3-13 both appearing among the stronger Chinese entrances. Use this page to decide whether you still have an unfinished migration problem before blaming the release note or the CLI regression.

• From the 2026.3.13 release note: first confirm repo commands, package names, config paths, and startup flow have moved from Moltbot to OpenClaw, then return to the 2026.3.13 release note to judge it as a team baseline.
• From the CLI 20-40 second hang triage: if old commands, directories, or environment variables are still mixed in, finish this migration cleanup first; if migration is clean, use the CLI regression triage.
• From the homepage: treat this page as the first routing checkpoint. Finish migration if it is incomplete; if everything is already OpenClaw-native, move to install validation or release selection.

This reduces wasted paths between legacy project residue, release evaluation, and true CLI regression triage.

If you arrived from the homepage or the Mac install guide

GA4 now places the Chinese homepage, the Mac install guide, and this migration guide in the same small high-intent discovery path. Do not collapse “install OpenClaw” and “remove Moltbot residue” into one task. Split the intent first:

• New visitor from the homepage: if OpenClaw is not installed yet, start with the Mac quick install guide, then return here to check old commands and paths.
• Install works, but the machine still behaves like an old Moltbot setup: stay on this page and inspect command names, image tags, config directories, and remote URLs.
• CLI works but commands are slow: use the CLI performance regression triage instead of treating runtime latency as migration residue.

This routing reduces reinstall loops: installation belongs on the install guide, old-environment residue belongs here, and slow runtime commands belong on the performance regression page.

Five-minute validation checklist after migration

If you landed here from a direct link or the homepage, the easy mistake is to stop after git pull works. Use this quick validation order before treating the migration as complete:

1. git remote -v points only to openclaw/openclaw, and CI/CD has the same repository update.
2. Local scripts and deployment scripts prefer the openclaw command instead of relying on legacy moltbot or clawdbot aliases.
3. Docker image names, npm package names, and config directories have all moved to OpenClaw.
4. openclaw gateway status returns the expected gateway state, proving the migration is not only a repository rename.
5. One real agent task runs through the high-frequency paths you use most: channel, provider, browser, or exec.

This turns the migration page from a rename checklist into a recovery path. If all five checks pass, move on to release selection. If one fails, switch to the matching install or troubleshooting page.

Capture old-name search demand after the migration

A clean rename is not enough if users still search for Moltbot, Clawdbot, or old install commands. After the one-minute migration, add these follow-up checks:

1. Keep an old-name landing path: make sure at least one page still says Moltbot to OpenClaw migration in plain language.
2. Map old commands to new commands: show the exact replacement command instead of only saying the old name is deprecated.
3. Route unresolved errors: if the rename exposes a provider, session, or channel failure, send users to the specific troubleshooting page rather than back to the homepage.
4. Verify analytics continuity: watch whether old-name traffic lands on the migration guide, a release note, or a 404, then add internal links from the winning entry page.

This protects high-intent search traffic during the rebrand window while still moving users toward current OpenClaw setup and diagnostics.

FAQ: the repository name is fixed, but traffic and usage still feel flat

If you already moved from Moltbot to OpenClaw but traffic or real usage did not improve, the usual gap is not the rename itself. It is that the migration page has not yet handed users to the next high-intent path: install validation, troubleshooting, or the shortest old-name search answer.

First, make the post-migration next step explicit. Many visitors who land here are not reading a brand story; they want to know how to get back to a working OpenClaw setup. If the environment is newly migrated but unstable, continue with the complete OpenClaw installation guide. If commands run but feel slow after hooks load, jump to the CLI performance regression triage.

Second, validate that migration produced a usable runtime, not just a renamed repository. Check that old scripts, aliases, and internal docs no longer point at Moltbot; openclaw --version and openclaw gateway status both return sensible output; and one real agent task succeeds through the path you rely on most.

Third, route unresolved failures away from this migration page. If the remaining issue is provider auth, Gateway recovery, browser access, permissions, or tool execution, move to the OpenClaw Agents troubleshooting guide instead of rereading the rename checklist. That keeps old-name search demand connected to pages that can actually solve the operator’s next problem.

Exact searches this migration page should answer next

Use this section when the reader is not asking for a generic rebrand story, but is already trying to finish a Moltbot to OpenClaw migration without losing working automation.

• moltbot to openclaw migration remote url: update the Git remote first, then pull and verify the repository origin before touching config files.
• moltbot config path openclaw config path: check whether the old config directory still owns credentials, then migrate or copy only the files the new OpenClaw install actually reads.
• openclaw migration commands still using moltbot: remove stale CLI packages, shell aliases, Docker image names, and scripts that still call the old name.

Related reading

• OpenClaw compaction stuck recovery guide
• Goodbye Moltbot, Hello OpenClaw
• Safety and cost

Summary

Total time: Under 1 minute.

For the full story behind the rebrand, see Goodbye Moltbot, Hello OpenClaw.