#Update Errors

21 messages · Page 1 of 1 (latest)

gaunt merlin
#

Device: Mac Mini
Openclaw Installed Version: 2026.4.12

Attempting to update to the new 2026.4.14 via the terminal by typing openclaw update and getting this output

    npm error code EEXIST
    npm error syscall rename
    npm error path /Users/office/.npm/_cacache/tmp/cefa7ec3
    npm error dest /Users/office/.npm/_cacache/content-v2/sha512/e0/f3/123decdbd500e167c0ef8c0d2903a4ea8bf81a3b9fe4d6f01231b40661ec71c0a0bdfc4ff0df4c5044c0c0a8c0183be1c16579001b2a8b5e60096f95b59e
    npm error errno EEXIST
    npm error Invalid response body while trying to fetch https://registry.npmjs.org/@jimp%2fplugin-blit: EACCES: permission denied, rename '/Users/office/.npm/_cacache/tmp/cefa7ec3' -> '/Users/office/.npm/_cacache/content-v2/sha512/e0/f3/123decdbd500e167c0ef8c0d2903a4ea8bf81a3b9fe4d6f01231b40661ec71c0a0bdfc4ff0df4c5044c0c0a8c0183be1c16579001b2a8b5e60096f95b59e'
    npm error File exists: /Users/office/.npm/_cacache/content-v2/sha512/e0/f3/123decdbd500e167c0ef8c0d2903a4ea8bf81a3b9fe4d6f01231b40661ec71c0a0bdfc4ff0df4c5044c0c0a8c0183be1c16579001b2a8b5e60096f95b59e
    npm error Remove the existing file and try again, or run npm
    npm error with --force to overwrite files recklessly.
    npm error A complete log of this run can be found in: /Users/office/.npm/_logs/2026-04-15T07_11_17_227Z-debug-0.log
│
◇  ✓ Running doctor checks (7.59s)

Update Result: ERROR
  Root: /usr/local/lib/node_modules/openclaw
  Reason: global update
  Before: 2026.4.2
  After: 2026.4.2

Recovery hints:
  - Detected permission failure (EACCES). Re-run with a writable global prefix or sudo (for system-managed Node installs).
  - Example: npm config set prefix ~/.local && npm i -g openclaw@latest

Total time: 15.62s

The gateway is now unreachable. Attemping the update via the gateway GUI banner doesn't work either.

elder templeBOT
#

That looks like npm cache permissions/ownership drift, not a bad 2026.4.14 release.

Two clues:

  1. EACCES is coming from ~/.npm/_cacache
  2. the updater says the install under /usr/local/lib/node_modules/openclaw is 2026.4.2, which does not match the 2026.4.12 you mentioned, so there may also be multiple installs / service path drift

Try these first, in this order:

openclaw --version
which -a openclaw
openclaw gateway status --deep
ls -ld ~/.npm ~/.npm/_cacache

If ~/.npm is owned by root, fix that first:

# 
sudo chown -R "$(whoami)" ~/.npm
npm cache verify

Then retry the install. Since your current install root is /usr/local/..., the simplest path is:

sudo npm i -g openclaw@2026.4.14
openclaw doctor
openclaw gateway restart
openclaw gateway status
openclaw status --all

If the gateway is still unreachable after reinstall, the service may still be pointing at the wrong entrypoint. In that case run:

gaunt merlin
#

ok, the odd thing is it does look like it updated to 2026.4.14judging by the outputs from those 4 commands.

OpenClaw 2026.4.14 (323493f)```

```~ ❯ which -a openclaw
/usr/local/bin/openclaw```

```~ ❯ openclaw gateway status --deep

🦞 OpenClaw 2026.4.14 (323493f) — I've seen your commit messages. We'll work on that together.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-15.log
Command: /usr/local/opt/node/bin/node /usr/local/lib/node_modules/openclaw/dist/entry.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

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 63365)
RPC probe: ok

Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):
- com.odin.openclaw.gateway-watchdog (user, plist: /Users/odin/Library/LaunchAgents/com.odin.openclaw.gateway-watchdog.plist)
Cleanup hint: launchctl bootout gui/$UID/ai.openclaw.gateway
Cleanup hint: rm ~/Library/LaunchAgents/ai.openclaw.gateway.plist

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).```
elder templeBOT
#

Yep, this is the funny kind of failure: it looks like the update actually landed, and the gateway is healthy now.

The important bits in your output are:

  • openclaw --version → 2026.4.14
  • service command points at /usr/local/lib/node_modules/openclaw/dist/entry.js
  • RPC probe: ok
  • Listening: 127.0.0.1:18789

So at this point I would treat the original update error as an npm cache/permission false-negative, not a broken install.

What I’d do next:

  1. Close the old dashboard/control UI tab
  2. Re-open it fresh with:
# 
openclaw dashboard

or open:

http://127.0.0.1:18789/

on the same Mac

If it asks for auth, use the current gateway token/password locally, but don’t paste it here.

For the noisy npm issue, I’d still fix the cache before the next update:

# 
ls -ld ~/.npm ~/.npm/_cacache

If those are root-owned:

sudo chown -R "$(whoami)" ~/.npm
npm cache verify

I also would not run the cleanup hints from gateway status yet. Your current gateway is up, so that extra watchdog entry is only worth chasing if you keep seeing flapping/restarts.

If the dashboard still says unreachable after opening a fresh tab, paste these next:

gaunt merlin
#

even though I'm on a Mac Mini running openclaw dashboard is telling me that there's no GUI detected No GUI detected. Open from your computer

elder templeBOT
#

Ah, that message is usually not “the dashboard is broken”, it just means the CLI can’t launch a browser from that shell session.

On a Mac Mini that often happens if you’re:

  • SSH’d into it
  • in a headless/sessionless shell
  • using a terminal context without a local GUI session

Since your gateway status shows:

  • RPC probe: ok
  • Listening: 127.0.0.1:18789

the gateway itself looks fine.

If you are on the Mac Mini directly

Just open this manually in Safari/Chrome on that same Mac:

# 
http://127.0.0.1:18789/

If you are connecting to the Mac Mini remotely

That gateway is loopback-only, so open an SSH tunnel first from your computer:

ssh -N -L 18789:127.0.0.1:18789 user@your-mac-mini

Then open this on your computer:

http://127.0.0.1:18789/
#

If the UI asks for auth, paste the gateway token/password locally, but don’t post it here.

openclaw dashboard --no-open is also fine here, it just prints the URL without trying to launch a browser.

Docs:
https://docs.openclaw.ai/web/dashboard
https://docs.openclaw.ai/help/faq

So, short version: “No GUI detected” is expected in a headless/remote shell. Your gateway looks up. Open the URL manually, or tunnel if remote.

gaunt merlin
#

Openig the gateway manually works. Logging into the Mac via screen share and running the terminal command openclaw dashboard locally still gives the GUI not detected issue. Not a deal breaker because it loads manually but the command isn't working as epected from the terminal.

All other flagged concerns from the failed update are now resolved.

elder templeBOT
#

Nice, glad the real outage is gone. And yeah, this last bit does look like a real bug.

I checked the dashboard open logic, and it bails out as “no GUI” if these are set:

  • SSH_CLIENT
  • SSH_TTY
  • SSH_CONNECTION

and there’s no DISPLAY/WAYLAND_DISPLAY.

On macOS that can false-positive pretty easily, because DISPLAY is usually empty anyway. So if your local shell inherited old SSH_* vars, for example via tmux/screen/session restore, openclaw dashboard can think it’s headless even when it isn’t.

Quick check:

env | grep '^SSH_'
#

If those are present, that’s probably the cause.

Workarounds

Open it directly:

open http://127.0.0.1:18789/

Or run dashboard with the SSH vars cleared:

env -u SSH_CLIENT -u SSH_TTY -u SSH_CONNECTION openclaw dashboard

If that fixes it, I’d call this a legit bug and file it here:

#

https://github.com/openclaw/openclaw/issues

Useful repro note:

  • macOS / Mac Mini
  • gateway healthy
  • openclaw dashboard says No GUI detected
  • manual open http://127.0.0.1:18789/ works
  • clearing SSH_* env vars makes openclaw dashboard behave

That should give maintainers a very sharp starting point. If you want, I can help you turn that into a clean issue report text.

gaunt merlin
#

the env | grep '^SSH_' command does indeed have entries present

  • SSH_CLIENT=tailscale ip details
  • SSH_CONNECTION= tailscale ips (ssh port)
  • SSH_TTY=/dev/ttys001
elder templeBOT
#

Yep, that confirms it. openclaw dashboard is keying off the lingering SSH_* vars, so your Tailscale SSH session is being treated as headless. That also explains why screen sharing into that same shell still shows the false “No GUI detected”.

Workarounds for now:

env -u SSH_CLIENT -u SSH_CONNECTION -u SSH_TTY openclaw dashboard

or just:

open http://127.0.0.1:18789/

If you open a fresh local Terminal/iTerm window that did not inherit the old Tailscale SSH env, it may also behave normally.

This is worth filing as a bug:

#

https://github.com/openclaw/openclaw/issues

A good short title would be:

openclaw dashboard falsely reports “No GUI detected” on macOS when SSH_* env vars are present (for example Tailscale SSH / reused shell)

Glad we found the actual cause, this one would’ve been annoyingly easy to misdiagnose 🦐

If this solved the thread, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

gaunt merlin
#

unable to mark solution as resolved. Error message The application did not respond