OpenClaw updates | Friends of the Crustacean 🦞🤝 | Page 1

spark vigil Apr 14, 2026, 8:41 PM

#

I think I broke my OpenClaw configuration. I'm in the following situation:
Clear situation:

Running: 2026.4.8 (system, /usr/local/bin/)
Installed: 2026.4.14 (in /data/.npm-global/) ← even newer!
Symlink: still points to the old one, it wasn't updated

It's out of sync. The symlink needs root to be changed, and without elevated privileges I can't do that from here.
To fix it once and for all: enable elevated in openclaw.json by adding it inside "tools":
I don't know if I should follow this recommendation, and it's limiting me from moving forward with my project. What should I do?

I´m using Hostinger/VPS

short sunBOT Apr 14, 2026, 8:44 PM

#

Short version, no, I would not enable tools.elevated just for this.

That setting is for letting a sandboxed agent run host commands outside the sandbox. It does not fix a stale openclaw symlink/PATH setup, and on a VPS it is a pretty big permission expansion.

What you have sounds like binary drift:

old binary: /usr/local/bin/openclaw
newer binary: /data/.npm-global/bin/openclaw

So the fix is to make your shell and service use one canonical binary, not to turn on elevated mode.

Recommended path

Confirm what resolves right now

which -a openclaw

#

openclaw --version
/data/.npm-global/bin/openclaw --version

Prefer the newer user-writable install in PATH

echo 'export PATH="/data/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
hash -r
which -a openclaw
openclaw --version

Rewrite the gateway service from the correct binary

#

/data/.npm-global/bin/openclaw gateway install --force
/data/.npm-global/bin/openclaw gateway restart
/data/.npm-global/bin/openclaw status

That usually avoids needing /usr/local/bin at all, especially if you're using the default systemd user service.

Only if you want the system symlink fixed

Do this once with sudo:

sudo ln -sf /data/.npm-global/bin/openclaw /usr/local/bin/openclaw

Important

If you want updates “once and for all”, use the normal updater or auto-update config:

#

openclaw update
update.auto.enabled in config

Not tools.elevated.

Docs:

If you paste these 4 outputs, I can tell you the exact safest next step:

which -a openclaw
openclaw --version

#

/data/.npm-global/bin/openclaw --version
openclaw gateway status --deep

spark vigil Apr 14, 2026, 8:48 PM

#

Where should I run these 4 recommended path? chat openclaw? terminal or windows powershell ssh user?

short sunBOT Apr 14, 2026, 8:49 PM

#

Run them in a terminal on the VPS, not in OpenClaw chat.

If you're on Windows, the easiest way is:

ssh your-user@your-vps-ip

Then run the commands inside that SSH session.

So, valid places:

SSH terminal from Windows PowerShell ✅
Hostinger VPS web console / terminal ✅
Local Windows PowerShell, without SSHing into the VPS ❌
OpenClaw chat ❌

Important

#

Run them as the same Linux user that runs OpenClaw.

You can paste this first:

whoami
which -a openclaw
openclaw --version
/data/.npm-global/bin/openclaw --version
openclaw gateway status --deep

If you paste the output here, I’ll tell you the exact next command.

spark vigil Apr 14, 2026, 8:56 PM

#

openclaw: command not found
-bash: /data/.npm-global/bin/openclaw: No such file or directory
openclaw: command not found

short sunBOT Apr 14, 2026, 8:57 PM

#

That helps. Right now the issue is even simpler: this shell cannot see any openclaw binary at all, and /data/.npm-global/bin/openclaw is apparently not the real path from this login.

So, don’t change tools.elevated yet. First we need to find where OpenClaw is actually installed.

Run these in the same SSH session on the VPS and paste the output:

whoami
echo "$HOME"
echo "$PATH"
command -v node
command -v npm
npm prefix -g
ls -la /usr/local/bin/openclaw ~/.local/bin/openclaw 2>/dev/null
find "$HOME" /usr/local /data -maxdepth 4 \( -type f -o -type l \) -name 'openclaw*' 2>/dev/null | sort

#

What this will tell us:

different user than the install user → common on VPS
PATH issue → binary exists, shell just can’t see it
wrong install path → /data/.npm-global was not the actual prefix
binary really missing → needs reinstall/update path cleanup

If you want the fast guess, my bet is you are logged in as a different Linux user than the one that installed OpenClaw.

spark vigil Apr 14, 2026, 8:58 PM

#

I am not using the root ssh user

short sunBOT Apr 14, 2026, 8:59 PM

#

Yep, that is very likely the problem.

On Linux/VPS, OpenClaw is usually managed as a per-user install/service. If it was installed or updated as root (or another user), your current SSH user will not necessarily see the same binary, npm prefix, or gateway service.

Best next step

If you have sudo, run this:

sudo -i
which -a openclaw
npm prefix -g
openclaw --version
openclaw gateway status --deep

Then paste the output here.

#

If `sudo -i` works

That means OpenClaw is probably owned/installed under root, and the real fix is:

pick one user to own the install
stop mixing root + non-root updates
then repair PATH/service from that same user

If you do not have sudo

Then you need to SSH as the same Linux user that originally installed OpenClaw, or reinstall it cleanly under your current user.

So, short version:

No, don’t enable tools.elevated
Yes, user mismatch is probably the real issue
Next check is sudo -i (or the original install user)

If you want, after the sudo -i output I can tell you whether it’s better to:

#

keep it under root, or
reinstall it cleanly under your normal VPS user.

spark vigil Apr 14, 2026, 9:06 PM

#

I dont have sudo I have windows powershell with a ssh user different then the root

short sunBOT Apr 14, 2026, 9:07 PM

#

Then you’ve hit a real Linux permission boundary.

From a non-root SSH user with no sudo, you cannot fix a root-owned OpenClaw install.
And tools.elevated will not bypass that. It does not magically grant OS root privileges.

What this means

If the old install/symlink/service was created by root (or another user), your current SSH user cannot:

change /usr/local/bin/openclaw
repair a root-owned system service
update another user’s npm/global install

Best options

1. Recommended: get root access once, or ask whoever has it to do the fix
This is the cleanest path.

#

2. Alternative: reinstall OpenClaw under your current SSH user
But if the old root-owned service is still running on the same port, you’ll still need root/admin to disable it first.

My recommendation

On a VPS, I’d stop mixing root + non-root installs and do one clean owner model:

either root owns it
or your normal SSH user owns it
but not both

So the honest answer

Right now, you are blocked until you have either:

root login, or
sudo, or
help from the person who installed it

#

If you want, I can write you the exact one-time command list to send to the VPS admin/root user, either for:

repairing the existing install, or
moving everything cleanly to your normal SSH user.

I’d recommend option 2 if this is your personal VPS.

spark vigil Apr 14, 2026, 9:12 PM

#

ok Now Iam using the root user How can I fix it? what is the first step?

short sunBOT Apr 14, 2026, 9:12 PM

#

Good, now you can fix the current root-owned install directly.

First step

Confirm the real new binary path as root:

which -a openclaw
npm prefix -g
ls -la /usr/local/bin/openclaw
ls -la "$(npm prefix -g)/bin/openclaw"
openclaw --version
"$(npm prefix -g)/bin/openclaw" --version

If that last path exists and shows the newer version

Repoint the symlink, then refresh the gateway service:

#

ln -sf "$(npm prefix -g)/bin/openclaw" /usr/local/bin/openclaw
hash -r
openclaw --version
openclaw gateway install --force
openclaw gateway restart
openclaw status

What this does

points /usr/local/bin/openclaw at the newer install
updates service metadata to use the current binary
restarts the gateway cleanly

If any one of those commands fails, paste the output before going further and I’ll help you with the next exact step.

Also, since you’re root now, you do not need tools.elevated for this fix.

spark vigil Apr 14, 2026, 9:14 PM

#

I am in a vps docker please confirm the commands

short sunBOT Apr 14, 2026, 9:15 PM

#

Ah, important correction: if this is Docker on a Hostinger VPS, do not run the symlink commands I gave earlier.

Those commands were for a native host install. In Docker, changing /usr/local/bin/openclaw inside the container is not the real fix and usually won’t persist after the container is recreated.

Correct first step

Figure out which Docker setup you have:

A) Hostinger Docker Manager / OpenClaw on VPS

Use hPanel → Docker Manager for:

Update
Restart
Logs

That is the supported path for Hostinger VPS Docker installs.
Docs: https://docs.openclaw.ai/install/hostinger

#

B) Your own Docker Compose setup

Run this on the VPS host, in the directory with your docker-compose.yml:

git pull
docker compose build
docker compose up -d

Docs: https://docs.openclaw.ai/install/docker-vm-runtime#updates

If you are not sure which one you have

Run this on the VPS host and paste the output:

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

#OpenClaw updates

Recommended path

Only if you want the system symlink fixed

Important

So, valid places:

Important

Best next step

If sudo -i works

If you do not have sudo

What this means

Best options

My recommendation

So the honest answer

First step

If that last path exists and shows the newer version

What this does

Correct first step

A) Hostinger Docker Manager / OpenClaw on VPS

B) Your own Docker Compose setup

If you are not sure which one you have

If `sudo -i` works