#Constant "Doctor" fixes since GPT 5.4 update

1 messages · Page 1 of 1 (latest)

honest fox
#

I'm having a rough time trying to fix other personal items I'm working on (right now, trying to re-establish a cron board dashboard inside the gateway dashboard).

It seems like since the GPT 5.4 update over the weekend, I've had to use the doctor to fix OC over a dozen times now for what feels like minor updates and fixes It's working on in the background. I've noticed it's a constant gateway issue. I am getting this error, but I'm not sure what it "means."

Gateway service uses Node from a version manager; it can break after upgrades. │
│ (/Users/XXXXX/.nvm/versions/node/v22.22.0/bin/node)

This is on a M4 Mac Mini (base).

kindred brambleBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

urban hatchBOT
#

That message is doctor explaining a very specific failure mode on macOS:

  • Your Gateway is running as a launchd service (background daemon).
  • The service is wired to a specific node binary path.
  • If that node comes from a version manager (like nvm), then upgrading/removing Node versions can leave the service pointing at a path that no longer exists (or an “old” Node install), so the Gateway starts flaking out and doctor keeps having to “repair” it.

So it’s not “GPT-5.4 broke the gateway” so much as: something changed on the machine (Node/OpenClaw install path), and the service didn’t follow.

The quick fix (usually stops the repeated doctor loop)

From the same shell where your intended Node is active:

openclaw --version
which node && node -v
openclaw gateway status
openclaw gateway install --force
#
openclaw gateway restart

Docs runbook mentions the same “reinstall service metadata” move here:
https://docs.openclaw.ai/gateway/troubleshooting#if-you-upgraded-and-something-suddenly-broke

The “make it stop happening” fix (recommended)

Use a stable Node install for the launchd service (e.g. Homebrew Node at /opt/homebrew/bin/node) instead of an nvm-managed version that you might uninstall/rotate.

If you want, paste the output of:

  • openclaw --version
  • openclaw gateway status --deep (or just openclaw gateway status if that’s all you have)
  • and the exact snippet doctor prints

…and I can tell you which side is drifting: Node path, OpenClaw binary path, or service-vs-cli config mismatch.

honest fox
#

jbgibbs@JBs-Mac-mini ~ % openclaw --version
OpenClaw 2026.3.8 (3caab92)
jbgibbs@JBs-Mac-mini ~ % openclaw gateway status --deep

🦞 OpenClaw 2026.3.8 (3caab92) — Half butler, half debugger, full crustacean.

│
â—‡
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Command: /Users/jbgibbs/.nvm/versions/node/v22.22.0/bin/node /Users/jbgibbs/.nvm/versions/node/v22.22.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/Users/jbgibbs/.nvm/versions/node/v22.22.0/bin/node)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 12691, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

urban hatchBOT
#

Your gateway status --deep output is actually good news:

  • Runtime: running + RPC probe: ok ⇒ the Gateway is healthy right now.
  • The “issue” it’s complaining about is not a current failure, it’s a fragility warning about how the macOS LaunchAgent was installed.

What it means:

  • Your LaunchAgent is hardwired to this exact Node path:

    /Users/jbgibbs/.nvm/versions/node/v22.22.0/bin/node

  • That’s fine until you do something like nvm uninstall 22.22.0, nvm prune, or otherwise rotate Node versions. Then the LaunchAgent points to a dead path and the service won’t start (or starts with a different global openclaw), and doctor has to keep repairing it.

So if you’ve been “doctor’ing” a ton lately, the usual pattern is:

  • Node version changed / old version removed (or openclaw got installed under a different Node),
  • service still points at the old one,
  • doctor detects the drift and tries to put things back.
#

How to stop the repeated breakage (pick one)

Option A (minimal, keep nvm):

  1. Decide “OpenClaw runs on Node v22.22.0”
  2. Never uninstall that Node version in nvm.
  3. If you do switch Node versions, immediately re-pin the service by running (from the Node you want OpenClaw to use):
openclaw gateway install --force
openclaw gateway restart

Option B (recommended, make it boring/stable):
Install Node in a non-version-manager way (Homebrew or official installer) so the service uses a stable path like /opt/homebrew/bin/node, then reinstall the service (openclaw gateway install --force + restart). That’s the easiest way to stop this warning and stop future “Node path vanished” breakages.

Key point

You do not need to run doctor just because this warning exists. If gateway status shows RPC probe ok, you can ignore it unless you’re actively upgrading/removing Node versions.

#

If you paste the last “doctor had to fix it again” output (just the section it says it repaired), I can tell whether it’s only this nvm warning or if there’s a second real underlying issue causing the repeated repairs.

honest fox
#

Walk me through step by step Option B

Option B (recommended, make it boring/stable):
Install Node in a non-version-manager way (Homebrew or official installer) so the service uses a stable path like /opt/homebrew/bin/node, then reinstall the service (openclaw gateway install --force + restart). That’s the easiest way to stop this warning and stop future “Node path vanished” breakages.

urban hatchBOT
#

Here’s Option B on an M4 Mac mini, step-by-step, with “sanity check” commands after each stage so you can see you’re on the right track.

Goal: get the LaunchAgent to run with a stable Node path (Homebrew / official installer), not ~/.nvm/....


0) Confirm what you have now (baseline)

Run:

which node && node -v
which openclaw && openclaw --version
openclaw gateway status --deep | sed -n '1,30p'

You should currently see node and openclaw coming from ~/.nvm/... (as in your output).

#

1) Install a stable Node (Homebrew)

First, make sure Homebrew is there:

brew --version

Then install Node 22 LTS via Homebrew:

brew install node@22

If Homebrew says node@22 isn’t available for some reason, do this instead (and just verify it’s >=22):

#
brew install node

2) Make this terminal use the Homebrew Node (not nvm)

This is the key part. For node@22, Homebrew usually does not take precedence automatically.

Run:

export PATH="$(brew --prefix node@22)/bin:$PATH"
hash -r

Now verify you’re on the Homebrew Node:

#
which node
node -v

Expected:

  • which node is something like /opt/homebrew/opt/node@22/bin/node (or similar)
  • node -v is v22.x.x (or higher, if you installed node)

3) Install OpenClaw under this stable Node

Now that this shell is using the Homebrew Node, install OpenClaw globally:

npm install -g openclaw pnpm
#

Verify this openclaw is not the nvm one:

which openclaw
openclaw --version

You want which openclaw to be under /opt/homebrew/... (not ~/.nvm/...).


4) Reinstall the Gateway LaunchAgent to use the stable Node/OpenClaw

Now rewrite the service to use the current node + current openclaw:

openclaw gateway install --force
#
openclaw gateway restart

5) Confirm the service command is no longer using nvm

This is the “done” check:

openclaw gateway status --deep

Look at the Command: line. You want it to reference something like:

  • /opt/homebrew/.../bin/node ... /opt/homebrew/.../lib/node_modules/openclaw/...

…and not ~/.nvm/versions/node/....

#

Optional cleanup (prevents confusion later)

Right now you may have two OpenClaw installs (one under nvm, one under Homebrew). That can cause “CLI vs service” weirdness later if your shell still defaults to nvm.

Once you’ve confirmed the service is stable, you can remove the nvm-installed OpenClaw:

# (only if you want to clean up)
nvm use 22.22.0
npm uninstall -g openclaw

If you get stuck at any step, paste:

  • which node && node -v
#
  • which openclaw && openclaw --version
  • the Command: line from openclaw gateway status --deep

…and I’ll tell you exactly where it diverged.

honest fox
#

After step 3 the output doesn't seem to match what you suggested for being inside of homebrew:

jbgibbs@JBs-Mac-mini ~ % which openclaw
openclaw --version
/Users/jbgibbs/.nvm/versions/node/v22.22.0/bin/openclaw
OpenClaw 2026.3.8 (3caab92)

urban hatchBOT
#

Yep — that output means your shell is still resolving openclaw from nvm, either because:

  1. you accidentally ran the nvm npm when you did npm install -g openclaw, or
  2. Homebrew’s global bin dir isn’t ahead of ~/.nvm/.../bin in your PATH (so even if Homebrew installed an openclaw, it’s “behind” nvm).

Let’s make it deterministic by pinning the exact Node/npm we use, and then calling the Homebrew-installed openclaw by absolute path (so PATH can’t trick us).

Do this exactly (copy/paste)

# 1) Force this terminal to use Homebrew's node@22 (not nvm)
export PATH="$(brew --prefix node@22)/bin:$PATH"
hash -r

# 2) Confirm node + npm are NOT from nvm
which node
#
which npm
node -v
npm -v

# 3) Install OpenClaw using THIS npm
npm install -g openclaw pnpm

# 4) Run the just-installed openclaw via absolute path
OPENCLAW_BIN="$(npm bin -g)/openclaw"
echo "$OPENCLAW_BIN"
ls -la "$OPENCLAW_BIN"
"$OPENCLAW_BIN" --version

# 5) Reinstall the LaunchAgent using that openclaw
"$OPENCLAW_BIN" gateway install --force
#
"$OPENCLAW_BIN" gateway restart
"$OPENCLAW_BIN" gateway status --deep

What you should see at the end

In gateway status --deep, the Command: line should now reference something under /opt/homebrew/... (or $(brew --prefix node@22)), not ~/.nvm/....


If step (2) still shows nvm

Paste just this and I’ll tell you exactly what’s overriding what:

which node
which npm
#
echo "$PATH" | tr ':' '\n' | head -20
brew --prefix node@22

Once we get the service reinstalled with the Homebrew Node path, that “version manager can break after upgrades” warning should go away.

honest fox
#

Just to verify before going to step 3, step 2 is working as you suggested, correct?

jbgibbs@JBs-Mac-mini ~ % export PATH="$(brew --prefix node@22)/bin:$PATH"
hash -r
jbgibbs@JBs-Mac-mini ~ % which node
/opt/homebrew/opt/node@22/bin/node
jbgibbs@JBs-Mac-mini ~ % which npm

/opt/homebrew/opt/node@22/bin/npm
jbgibbs@JBs-Mac-mini ~ %
node -v

v22.22.1
jbgibbs@JBs-Mac-mini ~ % npm -v
10.9.4
jbgibbs@JBs-Mac-mini ~ %

urban hatchBOT
#

Yes — that’s exactly what we want before step 3.

You’re now running:

  • node from /opt/homebrew/opt/node@22/bin/node
  • npm from /opt/homebrew/opt/node@22/bin/npm
  • Node v22.22.1 (meets the Node >= 22 requirement)

Now stay in this same terminal and proceed to step 3:

npm install -g openclaw pnpm

OPENCLAW_BIN="$(npm bin -g)/openclaw"
echo "$OPENCLAW_BIN"
"$OPENCLAW_BIN" --version
#

Then do the service rewrite:

"$OPENCLAW_BIN" gateway install --force
"$OPENCLAW_BIN" gateway restart
"$OPENCLAW_BIN" gateway status --deep

If which openclaw still shows the nvm one afterwards, that’s just PATH precedence — the important check is that gateway status --deep shows the LaunchAgent Command: using the /opt/homebrew/... node path.

honest fox
#

jbgibbs@JBs-Mac-mini ~ % npm install -g openclaw pnpm

OPENCLAW_BIN="$(npm bin -g)/openclaw"
echo "$OPENCLAW_BIN"
"$OPENCLAW_BIN" --version
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead
npm warn deprecated glob@10.5.0: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me

added 6 packages, and changed 664 packages in 21s

130 packages are looking for funding
run npm fund for details
Unknown command: "bin"

To see a list of supported npm commands, run:
npm help/openclaw
zsh: no such file or directory: Unknown command: "bin"\n\nTo see a list of supported npm commands, run:\n npm help/openclaw
jbgibbs@JBs-Mac-mini ~ % ~"$OPENCLAW_BIN" gateway install --force
"$OPENCLAW_BIN" gateway restart
"$OPENCLAW_BIN" gateway status --deep
zsh: no such file or directory: ~Unknown command: "bin"\n\nTo see a list of supported npm commands, run:\n npm help/openclaw
zsh: no such file or directory: Unknown command: "bin"\n\nTo see a list of supported npm commands, run:\n npm help/openclaw
zsh: no such file or directory: Unknown command: "bin"\n\nTo see a list of supported npm commands, run:\n npm help/openclaw
jbgibbs@JBs-Mac-mini ~ %

urban hatchBOT
#

You didn’t do anything “wrong” with OpenClaw there — the problem is this bit:

npm bin -g

On your npm (10.9.4), npm bin is not available, so it printed:

Unknown command: "bin"

…and that error text got captured into OPENCLAW_BIN, which is why zsh then tried to execute a nonsense path like Unknown command: "bin"....

Fix: use npm prefix -g (works on npm 10)

Run this (same terminal where which node is Homebrew):

#
PREFIX="$(npm prefix -g)"
OPENCLAW_BIN="$PREFIX/bin/openclaw"

echo "$PREFIX"
ls -la "$OPENCLAW_BIN"
"$OPENCLAW_BIN" --version

Then reinstall the service using that absolute openclaw:

"$OPENCLAW_BIN" gateway install --force
"$OPENCLAW_BIN" gateway restart
"$OPENCLAW_BIN" gateway status --deep
#

Notes

  • Don’t do ~"$OPENCLAW_BIN" — the ~ there breaks the path expansion. Always just do "$OPENCLAW_BIN" ....
  • If ls -la "$OPENCLAW_BIN" says “no such file”, paste:
    npm prefix -g
    npm config get prefix
    ls -la "$PREFIX/bin" | head -50
    
    and I’ll tell you where npm actually put the global binaries on your setup.

Once gateway status --deep shows the Command using /opt/homebrew/.../node instead of ~/.nvm/.../node, you’ve achieved Option B.