upgrade clawdbot

[mortal seal]

On a VPS, the cleanest “Clawdbot → OpenClaw” upgrade is basically: update the install in place, run Doctor (it handles migrations), restart the gateway, verify.

1) SSH into the VPS + grab your current version

clawdbot --version || true
openclaw --version || true

2) (Recommended) Re-run the installer (upgrades in place)

This is the preferred upgrade path and it will detect existing installs:

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

(If you actually want the “hackable” git install instead, re-run with --install-method git.)

3) Run migrations/repairs + restart

openclaw doctor
openclaw gateway restart

4) Verify it’s healthy

openclaw status --all
openclaw logs --follow

Notes

• Your state/config/workspace typically live under ~/.openclaw/ now; Doctor handles legacy migrations it recognizes.
• clawdbot still exists as a compatibility shim, but once upgraded you should start using the openclaw command day-to-day.

Docs (worth following exactly):

• Updating: https://docs.openclaw.ai/install/updating

• Doctor (migrations/repairs): https://docs.openclaw.ai/gateway/doctor

If you paste openclaw status --all here (it redacts tokens), I can tell you if anything looks off after the upgrade.

[quasi olive]

1. i got 2026.1.24-3 for clawdbot and 2026.2.2-3 for open claw

[mortal seal]

Cool — that basically means OpenClaw is already installed on the VPS, and clawdbot is either an older install or just the legacy shim.

What I’d do next is just make sure your running Gateway service + config/state are on OpenClaw:

1. Check which binary your service is using + whether you accidentally have two gateways:

openclaw gateway status
openclaw doctor --deep

2. Run the migration/repair pass + restart:

openclaw doctor
openclaw gateway restart

3. Verify everything is healthy:

openclaw status --all
openclaw logs --follow

If after that everything works, you can either:

• ignore the clawdbot command (it’s kept around for compatibility), or
• remove the old CLI install so you don’t get confused by versions (only after confirming OpenClaw is running fine):

npm rm -g clawdbot # or pnpm remove -g clawdbot

If you paste openclaw gateway status + the top of openclaw status --all here, I can sanity-check that you’re fully on OpenClaw.

[quasi olive]

i ran openclaw gateway status
and got "🦞 OpenClaw 2026.2.2-3 (9c5941b) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-02-06.log

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH is not set; the daemon should use a minimal PATH.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json
"

i ran openclaw status --all and got

│ Version │ 2026.2.2-3 │
│ OS │ linux 6.8.0-88-generic (x64) │
│ Node │ 22.22.0 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://xxxxxxxx │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm update 2026.2.3-1 │
│ Gateway │ local · ws://xxxx (local loopback) · reachable 55ms · auth token │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ srv8322348 (11.1.1.1.1) app unknown linux 6.8.0-88-generic │
│ Gateway service │ systemd not installed │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 0 bootstrapping · 1 active · 14 sessions │
└─────────────────┴────────────────────────────────────────────────────────

[mortal seal]

That output is actually good news: you’re already on OpenClaw 2026.2.2-3, and both the CLI + service are reading the same config (~/.openclaw/openclaw.json).

What it’s complaining about is just the systemd user service being disabled and having an old/non-standard unit file (missing a minimal PATH).

Do this on the VPS as the same user that should run the gateway:

openclaw doctor --repair
openclaw gateway restart
openclaw gateway status

If Doctor doesn’t rewrite the unit cleanly, force a full service rewrite:

openclaw gateway install --force

openclaw gateway restart
openclaw gateway status

After that, openclaw gateway status should no longer say the PATH warning, and ideally it won’t show systemd (disabled) anymore.

(And yep: clawdbot showing an older version is normal—it's basically a legacy shim now. Once you confirm everything runs, you can uninstall the old clawdbot global package if you want to avoid confusion.)

That openclaw status --all looks healthy (gateway reachable, Node 22, config in ~/.openclaw/openclaw.json). The only “problem” is: you’re currently not running it as a systemd service, so it won’t reliably stay up 24/7 after logout/reboot.

On the VPS, run:

openclaw doctor --repair
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

If you want to double-check systemd actually sees it:

systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

If systemctl --user … errors with something like “Failed to connect to bus”, tell me the exact message — some VPS/container setups don’t have user-systemd the normal way, and then we either:

• enable lingering (loginctl enable-linger $USER), or
• run a system service instead (gateway runbook shows the unit).

Also: your status says an update is available (2026.2.3-1). Once the service is sorted, the easiest upgrade is still:

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

[quasi olive]

ok i ran openclaw gateway status and didnt get path error now what?

[mortal seal]

Nice — if the PATH warning is gone, Doctor (or reinstall) fixed the unit file.

Now you basically just want to confirm it’s running as a service (so it survives logout/reboot) and that you don’t have a “second gateway” lurking.

1. Paste the new output of:

openclaw gateway status

Specifically the lines around Service: (it’ll say something like installed/enabled/running/disabled).

2. If it still shows systemd disabled, enable it:

systemctl --user enable --now openclaw-gateway.service
openclaw gateway status

3. On many VPSes you also need “linger” so user services keep running after you SSH out:

loginctl enable-linger $USER

4. Final sanity check:

openclaw status --all
openclaw gateway probe

If gateway status already shows the service enabled + running, then you’re basically done — optional next step is updating to the newer version your status mentioned (2026.2.3-1) via:

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

[quasi olive]

Service: systemd (enabled)

[mortal seal]

Perfect — that means you’re fully migrated and the Gateway will come back up automatically.

What I’d do next (quick checklist):

1. Make sure it’s actually running + reachable:

openclaw gateway status
openclaw status --all

2. If you haven’t yet, enable linger so it stays up after you log out of SSH (common VPS gotcha):

loginctl enable-linger $USER

3. Optional but recommended: you’re one patch behind (status --all showed 2026.2.3-1 available). Update in place:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
openclaw doctor
openclaw gateway restart

After that you can ignore/remove the old clawdbot CLI if you want, but functionally you’re done.

[quasi olive]

i ran status and got :
Runtime: stopped (state activating, sub auto-restart, last exit 1, reason 1)
RPC probe: ok

[mortal seal]

That combo is a little contradictory:

• Runtime: stopped (…auto-restart, last exit 1) = systemd thinks the service process is crash-looping / not staying up.
• RPC probe: ok = the CLI can still reach a gateway on that URL/port.

Most common cause: you have 2 gateways (e.g. one already running in the foreground / old service), so the systemd one exits with code 1 (often EADDRINUSE), while the probe is talking to the other one.

Can you paste the output of these?

openclaw gateway status
openclaw gateway probe
systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

While we wait, quick port-collision check (safe, read-only):

ss -lptn | grep 18789 || true

If the journal shows EADDRINUSE / “address already in use”, we’ll stop the extra instance and restart cleanly.

[quasi olive]

the top one outputted the weird "Feb 06 14:05:18 srv8308 systemd[80530]: openclaw-gateway.service: Failed with result 'exit-code'."

Feb 06 14:07:43 srv830448 node[1121153]: 2026-02-06T22:07:43.563Z Gateway failed to start: another gateway instance is already listening on ws://127.0

[mortal seal]

That line is the generic systemd “it exited non‑zero” message — the useful bit is a few lines above it (what actually caused exit code 1).

Can you run these and paste the output?

systemctl --user status openclaw-gateway.service --no-pager -n 80
journalctl --user -u openclaw-gateway.service --no-pager -n 200

Also do a quick port collision check (most common cause when RPC still says “ok”):

ss -lptn | grep 18789 || true

And grab the app log tail (it usually contains the real stacktrace like EADDRINUSE, bad config, missing permission, etc.):

tail -n 120 /tmp/openclaw/openclaw-2026-02-06.log

Once we see whether it’s EADDRINUSE (two gateways) vs something else, I’ll tell you the exact fix.

[quasi olive]

Feb 06 14:07:43 srv830448 node[1121153]: 2026-02-06T22:07:43.563Z Gateway failed to start: another gateway instance is already listening on ws://127.0

[mortal seal]

Yep — that log line is the smoking gun:

“another gateway instance is already listening on ws://127.0.0.1:18789”

So the systemd service can’t start because something else is already running on port 18789 (and your “RPC probe: ok” is talking to that other running gateway).

Fix (recommended): stop the “other” gateway, then let systemd own it

1. Find what’s holding the port:

ss -lptn | grep 18789 || true

You’ll see a pid=#### in there.

2. See what that PID is:

ps -fp <PID>

3. Stop it:

• If it’s an old service/unit, stop that unit.
• If it’s just a stray process, do:

kill -TERM <PID>

4. Then restart the OpenClaw service:

openclaw gateway restart
openclaw gateway status

If you paste these two outputs, I’ll tell you exactly what to stop (and whether it’s an old clawdbot service):

ss -lptn | grep 18789 || true

ps -fp <PID>

Yep, that’s the same error — the systemd service is failing because something else is already bound to 127.0.0.1:18789. We need to find and stop that “other” gateway.

Run these on the VPS and paste the output:

ss -lptn | grep 18789 || true
ps -fp <PID>

(Replace <PID> with the pid you see in the ss line, e.g. pid=12345.)

Common outcomes + what to do:

• It’s a foreground openclaw gateway you started manually → go to that terminal and Ctrl+C it (or kill -TERM <PID>).
• It’s an old service (maybe clawdbot or another openclaw profile/unit) → we stop/disable that unit, then restart the real one.

To quickly list any user services that might be running:

systemctl --user list-units --type=service | grep -i -E "openclaw|clawdbot" || true

Once the port is free:

systemctl --user restart openclaw-gateway.service
openclaw gateway status

[quasi olive]

this is what my clawdbot says the issue is

Issue: Port conflict

Both gateways fighting over port 18789:

• clawdbot-gateway (pid 1068946) — running, owns the port
• openclaw-gateway — keeps trying to start, fails, auto-restarts (47 times and counting)
Not a config problem — just both services enabled simultaneously.

To fix (when ready to migrate):

1. Stop clawdbot: systemctl --user stop clawdbot-gateway && systemctl --user disable clawdbot-gateway
2. OpenClaw will grab the port on next restart
   Or to stop the crash loop for now:
   systemctl --user stop openclaw-gateway && systemctl --user disable openclaw-gateway

The config migration is still needed before OpenClaw will work properly, but the crash itself is just the port fight.

?

[mortal seal]

Yep, that diagnosis is correct: both services are enabled and fighting for 18789. Fix is just “pick one.”

If you’re migrating to OpenClaw, do this:

# stop the crash loop first (optional but nice)
systemctl --user stop openclaw-gateway
systemctl --user reset-failed openclaw-gateway

# stop + disable the old clawdbot gateway (this frees 18789)
systemctl --user stop clawdbot-gateway
systemctl --user disable clawdbot-gateway

# start OpenClaw
systemctl --user enable --now openclaw-gateway
openclaw gateway status

Then run migrations/health once (safe even if already done):

openclaw doctor
openclaw status --all

If you wanted to keep both running, the alternative is to move one of them to a different port — but for a straight upgrade, disabling clawdbot-gateway is the right move.

Did you run the stop/disable commands yet, and did anything error?

If you run these and paste the output, we can finish it in one shot:

systemctl --user list-units --type=service | grep -i -E "openclaw|clawdbot" || true
openclaw gateway status

Goal state should be:

• clawdbot-gateway = disabled/inactive
• openclaw-gateway = enabled + running
• openclaw gateway status = no “another gateway instance…” error

If OpenClaw is still stuck in a failed loop, do:

systemctl --user reset-failed openclaw-gateway
systemctl --user restart openclaw-gateway

[quasi olive]

all working, do i need to uninstall calwdbot?

[mortal seal]

You don’t need to uninstall clawdbot as long as:

• the clawdbot-gateway systemd service is disabled (so it won’t steal port 18789 again), and
• you’re happy using openclaw going forward.

That said, I usually recommend removing it to avoid confusion later:

1. Confirm the old service is disabled:

systemctl --user is-enabled clawdbot-gateway || true
systemctl --user status clawdbot-gateway --no-pager || true

2. Uninstall the old CLI package (pick the one you used to install it):

npm rm -g clawdbot

# or
pnpm remove -g clawdbot

OpenClaw will keep working either way — uninstalling just reduces “which command/version am I running?” headaches.

[quasi olive]

and no file confusion?

[mortal seal]

If everything is now running as OpenClaw, uninstalling the clawdbot CLI package won’t mess with your files.

OpenClaw’s “real stuff” lives here (and you’re already using it):

• Config/state: ~/.openclaw/ (incl ~/.openclaw/openclaw.json)
• Credentials: ~/.openclaw/credentials/
• Sessions/memory/workspace: under ~/.openclaw/...

Uninstalling clawdbot via npm rm -g clawdbot / pnpm remove -g clawdbot just removes the old command, not your state directory.

The only “file confusion” scenario is if you accidentally still have:

• clawdbot-gateway service enabled, or
• multiple state dirs/profiles (like ~/.openclaw-something)

Quick sanity check:

openclaw gateway status