Shell and managed Gateway use different Node installations

Troubleshooting
, , , ,
1

Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from September 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

Every update warns that my interactive shell uses a Homebrew Node installation while the managed Gateway service uses an NVM Node installation. I want one existing install to own updates without creating more copies.

2

The warning identifies two runtime paths. It can be harmless when both point to compatible OpenClaw versions, but updates become risky when the shell, package manager, and service resolve different installations.

Inspect before changing anything:

command -v node
command -v npm
which -a openclaw
npm prefix -g
openclaw gateway status --deep

Choose either the NVM installation or the Homebrew installation as the canonical runtime. Avoid gateway install --force until that choice is clear.

3

I would prefer to keep the NVM version already used by the service. How do I run updates through that copy?

4

Load the same NVM environment in your shell, then confirm both Node and OpenClaw resolve beneath it before updating:

. "$HOME/.nvm/nvm.sh"
nvm use 24
hash -r
command -v node
command -v openclaw
openclaw --version
openclaw update --dry-run

Do not hard-code another user’s paths. The exact supported Node version should come from the current release and your existing NVM installation.

5

The update still stopped during Doctor. It reported stale plugin state, and later checks showed some commands were still resolving the Homebrew copy while the service pointed into NVM.

6

That is a split-brain installation, not just a cosmetic Node warning. Stop using unqualified OpenClaw commands until command -v openclaw, npm prefix -g, and the Gateway service all point to the chosen package root.

Once one runtime is authoritative, update that copy and let Doctor repair supported state:

openclaw update --dry-run
openclaw update
openclaw doctor --fix
openclaw gateway status --deep

Only if the status still shows service metadata pointing to the other installation should you regenerate the managed service, then verify it again:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

Preserve the state databases until the canonical installation is healthy.

7

At this point I would rather do a fresh install while keeping my memory and workspace.

8

Preserve the complete workspace, not only MEMORY.md, and keep the old state directory intact until the replacement is proven. Start with a verified backup to an existing private directory:

openclaw backup create --output EXISTING_BACKUP_DIRECTORY --verify

Then follow the current installer with one chosen Node/package-manager environment. Restore workspace files selectively after onboarding. Do not copy the old config, credentials, plugins, or databases into the fresh state unless you have separately validated that migration.