Gateway not reachable | Friends of the Crustacean 🦞🤝 | Page 1

glossy stream Apr 28, 2026, 3:21 PM

#

Updated openclaw to 2026.4.26, did a restart to the machine and since then logs say Gateway not reachable. Is it running and accessible?
Running openclaw doctor --fix doesnt fix it.

here is the openclaw gateway status --deep output:


│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-28.log
Command: /Users/jlipman/.local/share/fnm/node-versions/v24.13.0/installation/bin/node /Users/jlipman/.local/share/fnm/node-versions/v24.13.0/installation/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Working dir: ~/.openclaw
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 1025, state active)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
  timeout
Capability: unknown

Port 18789 is already in use.
- pid 1025 jlipman: openclaw-gateway (127.0.0.1:18789)
- Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

~ took 15s```

tawny mossBOT Apr 28, 2026, 3:21 PM

#

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

rocky fossilBOT Apr 28, 2026, 3:23 PM

#

That output means the LaunchAgent is running and listening. The “Port 18789 is already in use” line is just the gateway process itself, not necessarily a second conflict.

The real problem is:

Connectivity probe: failed
timeout

So I’d treat this as “gateway bound the port, but isn’t answering the WS probe.”

Try this first:

openclaw gateway restart
sleep 10

#

openclaw gateway status --deep --require-rpc --timeout 30000

If it still times out, please paste:

curl -sS -m 5 -i http://127.0.0.1:18789/healthz
curl -sS -m 5 -i http://127.0.0.1:18789/readyz
tail -n 200 /tmp/openclaw/openclaw-2026-04-28.log

If /healthz also hangs, the gateway event loop is likely wedged during startup. If /healthz works but the WS probe times out, that narrows it to the gateway connect/RPC path.

Also worth trying after that:

#

openclaw gateway install --force
openclaw gateway restart

Docs refs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

glossy stream Apr 28, 2026, 3:29 PM

#

healthz and readyz returned 200
I tried the install --force and restart and still getting:


🦞 OpenClaw 2026.4.26 (be8c246) — Your personal assistant, minus the passive-aggressive calendar reminders.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-28.log
Command: /Users/jlipman/.local/share/fnm/node-versions/v24.13.0/installation/bin/node /Users/jlipman/.local/share/fnm/node-versions/v24.13.0/installation/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Working dir: ~/.openclaw
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 2696, state active)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
  timeout
Capability: unknown

Port 18789 is already in use.
- pid 2696 jlipman: openclaw-gateway (127.0.0.1:18789)
- Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting```

rocky fossilBOT Apr 28, 2026, 3:31 PM

#

Nice, that narrows it down: HTTP liveness/readiness is fine, but the WebSocket gateway handshake is not completing. So this isn’t a port conflict or LaunchAgent install issue anymore.

Can you run this tiny raw WS probe?

node - <<'NODE'
const ws = new WebSocket('ws://127.0.0.1:18789');
const t = setTimeout(() => {
  console.error('timeout waiting for connect.challenge');
  ws.close();
  process.exit(2);
}, 5000);

ws.onopen = () => console.log('ws open');
ws.onmessage = (e) => {
  console.log('message:', e.data);

#

  clearTimeout(t);
  ws.close();
};
ws.onerror = (e) => console.error('ws error:', e.message || e);
ws.onclose = (e) => console.log('ws close:', e.code, e.reason);
NODE

Expected first message should be a connect.challenge.

Also please paste this, since openclaw logs may fail through the same WS path:

tail -n 250 /tmp/openclaw/openclaw-2026-04-28.log

#

If that raw WS probe gets the challenge, the gateway is probably okay and the CLI probe/auth path is the weird bit. If it times out too, this looks like a 2026.4.26 gateway WS bug/hang even though /healthz and /readyz are green.

glossy stream Apr 28, 2026, 3:41 PM

#

probe result:

message: {"type":"event","event":"connect.challenge","payload":{"nonce":"04176070-aa98-4236-a17f-0cacf17f634f","ts":1777390826808}}
ws close: 1005```

rocky fossilBOT Apr 28, 2026, 3:43 PM

#

Perfect — that proves the WS upgrade itself is alive. The timeout is happening on the actual connect request after the challenge, not on the port/listener.

Please run this next probe — it sends a minimal connect after receiving connect.challenge:

node - <<'NODE'
const crypto = require('crypto');
const ws = new WebSocket('ws://127.0.0.1:18789');
const id = crypto.randomUUID();

const t = setTimeout(() => {
  console.error('timeout waiting for connect response');
  ws.close();
  process.exit(2);
}, 8000);

#

ws.onopen = () => console.log('ws open');
ws.onmessage = (e) => {
  console.log('message:', e.data);
  const msg = JSON.parse(e.data);

  if (msg.type === 'event' && msg.event === 'connect.challenge') {
    ws.send(JSON.stringify({
      type: 'req',
      id,
      method: 'connect',
      params: {
        minProtocol: 3,
        maxProtocol: 3,
        client: {
          id: 'openclaw-probe',

#

          version: 'manual',
          platform: process.platform,
          mode: 'probe',
          instanceId: crypto.randomUUID()
        },
        role: 'operator',
        scopes: ['operator.read'],
        caps: []
      }
    }));
  } else if (msg.type === 'res' && msg.id === id) {
    clearTimeout(t);
    ws.close();
  }
};

#


ws.onerror = (e) => console.error('ws error:', e.message || e);
ws.onclose = (e) => console.log('ws close:', e.code, e.reason);
NODE

Also grab the matching log lines:

grep -Ei "gateway.ws|connect failed|auth|device token|pairing|required|unauthorized|preauth|error conn" /tmp/openclaw/openclaw-2026-04-28.log | tail -n 120

If the manual connect returns an auth error quickly, we’re likely looking at stale token/device auth state. If it also hangs, then the gateway’s connect handler is wedged even though /healthz and /readyz are green.

glossy stream Apr 28, 2026, 3:51 PM

#

probe:

message: {"type":"event","event":"connect.challenge","payload":{"nonce":"fcb5a131-efba-4403-a364-8bfffbca0af5","ts":1777391169419}}
message: {"type":"res","id":"0ced46a1-d658-4b47-8078-8ec89e71ff50","ok":false,"error":{"code":"NOT_PAIRED","message":"device identity required","details":{"code":"DEVICE_IDENTITY_REQUIRED"}}}
ws close: 1008 device identity required```

and the grep output is too long for me to post here

rocky fossilBOT Apr 28, 2026, 3:53 PM

#

That probe is useful: the gateway is answering normally. The device identity required response is expected because the manual probe didn’t send a device identity/token.

This now looks like CLI/device-token auth drift, possibly hidden as a timeout in 2026.4.26.

Try this recoverable reset of the CLI’s cached device token:

mkdir -p ~/.openclaw/identity/backup
mv ~/.openclaw/identity/device-auth.json ~/.openclaw/identity/backup/device-auth.json.$(date +%s) 2>/dev/null || true

Then trigger a fresh CLI pairing request:

openclaw health --json

#

It may fail with pairing/device required — that’s okay. Then:

openclaw devices list
openclaw devices approve <requestId>
openclaw gateway status --deep --require-rpc

Use the exact requestId from devices list — don’t use --latest to approve.

If devices list can’t show pending requests, paste only this shorter output:

openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw devices list

glossy stream Apr 28, 2026, 3:58 PM

#

tried to approve device, got:

Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/jlipman/.openclaw/openclaw.json
Bind: loopback
    at Timeout.<anonymous> (file:///Users/jlipman/.local/share/fnm/node-versions/v24.13.0/installation/lib/node_modules/openclaw/dist/call-CP7A3sdw.js:286:9)
    at listOnTimeout (node:internal/timers:605:17)
    at process.processTimers (node:internal/timers:541:7)```

rocky fossilBOT Apr 28, 2026, 3:59 PM

#

That’s a CLI auth deadlock, not a dead gateway.

Use a temporary/shared gateway token to break out of device-pairing auth:

TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw gateway restart

Then approve using that token explicitly:

openclaw devices list --token "$TOKEN"
openclaw devices approve <requestId> --token "$TOKEN"

#Gateway not reachable