#gateway does not start after recent update

1 messages · Page 1 of 1 (latest)

night harbor
#

after recent update on my MacOs installation, gateway does not start: ilkeraktuna@ilkers-Mac-mini ~ % openclaw gateway install

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Your terminal just grew claws—type something and let the bot pinch the busywork.

Gateway install failed: Error: launchctl bootstrap failed: Bootstrap failed: 125: Domain does not support specified action
LaunchAgent openclaw gateway install --force requires a logged-in macOS GUI session for this user (gui/501).
This usually means you are running from SSH/headless context or as the wrong user (including sudo).
Fix: sign in to the macOS desktop as the target user and rerun openclaw gateway install --force.
Headless deployments should use a dedicated logged-in user session or a custom LaunchDaemon (not shipped): https://docs.openclaw.ai/gateway
u0m% ilkeraktuna@ilkers-Mac-mini ~ % openclaw gateway start

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Greetings, Professor Falken

Gateway start failed: Error: launchctl kickstart failed: Could not kickstart service "ai.openclaw.gateway": 125: Domain does not support specified action
Tip: openclaw gateway install
Tip: openclaw gateway
Tip: launchctl bootstrap gui/$UID ~/Library/LaunchAgents/ai.openclaw.gateway.plist
u0m% ilkeraktuna@ilkers-Mac-mini ~ %

lusty tendonBOT
#

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

eager gustBOT
#

That error is launchd saying there is no active macOS GUI login session for that user (gui/501). It usually happens when running from SSH/headless, sudo, or a different user than the one logged into the Mac desktop.

Try this from the Mac’s actual desktop session / Screen Sharing session, as the same user, not sudo:

openclaw --version
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

If you’re intentionally running the Mac mini headless over SSH only, the shipped macOS service path is a per-user LaunchAgent, so it needs a logged-in GUI session. For a temporary SSH/manual run you can use:

openclaw gateway
night harbor
#

I need a headless setup and before this update , I had installed ai.openclaw.gateway.plist file at
/Library/LaunchDaemons/ai.openclaw.gateway.plist and it was running the server headless. now it does not start. how shall I troubleshoot ?

eager gustBOT
#

For a custom LaunchDaemon, don’t use openclaw gateway install/start — those manage the built-in per-user LaunchAgent (gui/$UID) and will fail headless.

Troubleshoot the daemon directly:

openclaw --version
openclaw gateway status --deep
sudo plutil -lint /Library/LaunchDaemons/ai.openclaw.gateway.plist
sudo launchctl print system/ai.openclaw.gateway

Then check the daemon’s stdout/stderr paths from the plist. Common defaults may be:

tail -200 ~/.openclaw/logs/gateway.log
tail -200 ~/.openclaw/logs/gateway.err.log
#

Big things to verify in /Library/LaunchDaemons/ai.openclaw.gateway.plist:

  1. ProgramArguments should run the foreground gateway, not the service manager:

    • good: openclaw gateway --port 18789
    • bad: openclaw gateway start / openclaw gateway install

  2. Use absolute paths. LaunchDaemons have a tiny PATH. If openclaw moved after update, this often breaks:

    command -v openclaw

  3. If you want it to use your user config/state, set UserName, HOME, and ideally:

    OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw

    Otherwise it may run as root and look in /var/root/.openclaw.

#
  1. Fix plist ownership/permissions if needed:
    sudo chown root:wheel /Library/LaunchDaemons/ai.openclaw.gateway.plist
sudo chmod 644 /Library/LaunchDaemons/ai.openclaw.gateway.plist

After edits:

sudo launchctl bootout system /Library/LaunchDaemons/ai.openclaw.gateway.plist 2>/dev/null || true
sudo launchctl bootstrap system /Library/LaunchDaemons/ai.openclaw.gateway.plist
sudo launchctl kickstart -k system/ai.openclaw.gateway
openclaw gateway status --deep

If you paste the plist contents with secrets removed plus the launchctl print output, we can spot the exact break. Docs: https://docs.openclaw.ai/gateway

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % openclaw --version
OpenClaw 2026.4.24 (cbcfdf6)
ilkeraktuna@ilkers-Mac-mini ~ % openclaw gateway status --deep

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

|
o
Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.254.170:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: unknown (Could not print domain: 125: Domain does not support specified action)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
ilkeraktuna@ilkers-Mac-mini ~ % sudo plutil -lint /Library/LaunchDaemons/ai.openclaw.gateway.plist
Password:
/Library/LaunchDaemons/ai.openclaw.gateway.plist: OK
ilkeraktuna@ilkers-Mac-mini ~ % sudo launchctl print system/ai.openclaw.gateway
Bad request.
Could not find service "ai.openclaw.gateway" in domain for system
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

Your output shows the custom LaunchDaemon is not loaded at all:

Could not find service "ai.openclaw.gateway" in domain for system

plutil -lint only proves the plist is valid XML; it doesn’t mean launchd accepted/loaded it.

Next run:

sudo launchctl bootstrap system /Library/LaunchDaemons/ai.openclaw.gateway.plist
sudo launchctl print system/ai.openclaw.gateway
sudo launchctl kickstart -k system/ai.openclaw.gateway

If bootstrap fails, get the actual launchd reason:

# 
sudo launchctl bootstrap system /Library/LaunchDaemons/ai.openclaw.gateway.plist 2>&1
sudo plutil -p /Library/LaunchDaemons/ai.openclaw.gateway.plist
log show --last 10m --predicate 'eventMessage CONTAINS "ai.openclaw.gateway" OR eventMessage CONTAINS "openclaw"'

One important thing: openclaw gateway status --deep is currently seeing the per-user LaunchAgent at:

~/Library/LaunchAgents/ai.openclaw.gateway.plist

That’s separate from your custom system daemon at:

/Library/LaunchDaemons/ai.openclaw.gateway.plist
#

So for headless mode, ignore openclaw gateway install/start for now and manage the system/ai.openclaw.gateway daemon directly.

Also verify the daemon plist uses absolute paths and foreground mode, e.g. not gateway start:

/opt/homebrew/opt/node@22/bin/node
/opt/homebrew/lib/node_modules/openclaw/dist/index.js
gateway
--port
18789

If you paste the plutil -p output, redact tokens/secrets, I can sanity-check the plist shape.

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % cat /Library/LaunchDaemons/ai.openclaw.gateway.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>ai.openclaw.gateway</string>
<key>UserName</key>
<string>ilkeraktuna</string>

<key>Comment</key>
<string>OpenClaw Gateway (v2026.4.5)</string>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>ThrottleInterval</key>
<integer>1</integer>
<key>Umask</key>
<integer>63</integer>
<key>ProgramArguments</key>
<array>
  <string>/opt/homebrew/opt/node@22/bin/node</string>
  <string>/opt/homebrew/lib/node_modules/openclaw/dist/index.js</string>
  <string>gateway</string>
  <string>--port</string>
  <string>18789</string>
</array>

<key>StandardOutPath</key>
<string>/Users/ilkeraktuna/.openclaw/logs/gateway.log</string>
<key>StandardErrorPath</key>
<string>/Users/ilkeraktuna/.openclaw/logs/gateway.err.log</string>
<key>EnvironmentVariables</key>
<dict>
<key>HOME</key>
<string>/Users/ilkeraktuna</string>
<key>TMPDIR</key>
<string>/var/folders/l5/hfr07zwj34qb4l8_5sq6dk440000gn/T/</string>
<key>NODE_EXTRA_CA_CERTS</key>
<string>/etc/ssl/cert.pem</string>
<key>NODE_USE_SYSTEM_CA</key>
<string>1</string>
<key>PATH</key>
%
eager gustBOT
#

That plist shape mostly looks right. Two things jump out:

  • Comment v2026.4.5 is stale but harmless.
  • The paste cuts off at PATH; since plutil said OK, I assume the real file has the rest. If it literally ends there, launchd won’t load it.

Next best checks:

sudo mkdir -p /Users/ilkeraktuna/.openclaw/logs
sudo chown -R ilkeraktuna:staff /Users/ilkeraktuna/.openclaw/logs

sudo chown root:wheel /Library/LaunchDaemons/ai.openclaw.gateway.plist
sudo chmod 644 /Library/LaunchDaemons/ai.openclaw.gateway.plist

sudo launchctl bootstrap system /Library/LaunchDaemons/ai.openclaw.gateway.plist 2>&1
sudo launchctl print system/ai.openclaw.gateway
#

If bootstrap succeeds but it immediately exits:

tail -200 /Users/ilkeraktuna/.openclaw/logs/gateway.log
tail -200 /Users/ilkeraktuna/.openclaw/logs/gateway.err.log

Also test the exact daemon command outside launchd:

sudo -u ilkeraktuna env \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
# 
  gateway --port 18789 --verbose

If that fails, the problem is OpenClaw/config/env. If that works, the problem is launchd/plist.

I’d also add this to EnvironmentVariables to remove ambiguity:

<key>OPENCLAW_STATE_DIR</key>
<string>/Users/ilkeraktuna/.openclaw</string>
<key>OPENCLAW_GATEWAY_PORT</key>
<string>18789</string>

And I’d remove or change the hardcoded TMPDIR to /tmp; /var/folders/... can be session-specific and annoying for headless boot.

#

Paste the output of the bootstrap ... 2>&1 line + the last 50 lines of gateway.err.log and we’ll know the exact failure.

night harbor
#

command works but webUI says "disconnected (1006): no reason" : ilkeraktuna@ilkers-Mac-mini ~ % sudo -u ilkeraktuna env \
HOME=/Users/ilkeraktuna
OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw
PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
/opt/homebrew/opt/node@22/bin/node
/opt/homebrew/lib/node_modules/openclaw/dist/index.js
gateway --port 18789 --verbose

🦞 OpenClaw 2026.4.24 (cbcfdf6) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

|
o
21:37:01 [gateway] loading configuration…
21:37:01 [gateway] resolving authentication…
21:37:01 [gateway] starting...
21:37:01 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search (/Users/ilkeraktuna/.openclaw/extensions/openclaw-web-search/index.ts). Set plugins.allow to explicit trusted ids.

eager gustBOT
#

Good — that means the OpenClaw command/config itself starts. The 1006 is now a Control UI/WebSocket auth/security/connectivity issue, not the LaunchDaemon issue.

While that foreground gateway is running, open a second SSH terminal and check:

openclaw gateway status --require-rpc
openclaw status
openclaw dashboard --no-open

For the Web UI: if you’re opening http://192.168.254.170:18789/ directly over LAN, that can fail now because plain HTTP on a non-localhost IP is treated as an insecure browser context. Prefer an SSH tunnel:

ssh -N -L 18789:127.0.0.1:18789 ilkeraktuna@192.168.254.170

Then open this on your laptop/browser:

# 
http://127.0.0.1:18789/

Use the URL/token from:

openclaw dashboard --no-open

or paste the gateway token in the UI under Overview → Gateway Access. Don’t paste the token here publicly.

If openclaw dashboard --no-open doesn’t give you a usable token, run:

openclaw doctor --generate-gateway-token
night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % openclaw gateway status --require-rpc

🦞 OpenClaw 2026.4.24 (cbcfdf6) — I don't judge, but your missing API keys are absolutely judging you.

|
o
Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.254.170:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: unknown (Could not print domain: 125: Domain does not support specified action)
Read probe: failed
Probe target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /Users/ilkeraktuna/.openclaw/openclaw.json
Possible causes:

  • Gateway not yet ready to accept connections (retry after a moment)
  • TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
  • Gateway crashed or was terminated unexpectedly
    Run openclaw doctor for diagnostics.

Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
u0m% ilkeraktuna@ilkers-Mac-mini ~ % openclaw status

🦞 OpenClaw 2026.4.24 (cbcfdf6) — Your .zshrc wishes it could do what I do.

|
o Checking for updates… ------- stucks here.

eager gustBOT
#

Okay, this narrows it down: the gateway process starts, but RPC/WebSocket closes abnormally (1006). That usually means the foreground gateway either crashed, hung during startup, or rejected/closed before the normal auth close frame.

The suspicious line is this:

[plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search

As a quick isolation test, temporarily disable that extension and restart the foreground gateway:

mv ~/.openclaw/extensions/openclaw-web-search ~/.openclaw/extensions/openclaw-web-search.disabled

Then rerun:

# 
sudo -u ilkeraktuna env \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose

In another terminal:

openclaw gateway status --require-rpc --json

Also: after you run the RPC check, look back at the foreground gateway terminal. If it prints a stack trace or exits, that’s the real clue.

#

For openclaw status hanging at “Checking for updates…”, try:

openclaw status --json --timeout 5000

If disabling openclaw-web-search fixes RPC, the plugin is likely incompatible after the update. If not, paste the foreground gateway logs immediately after the failed RPC probe.

#

Yep — that SSH tunnel error means nothing is actually listening on 127.0.0.1:18789 on the Mac mini. So the gateway command is probably hanging/crashing before it reaches “listening”.

In the foreground gateway terminal, you should normally see more after:

[gateway] starting...

Let’s check whether the process is alive and what port is bound:

lsof -nP -iTCP:18789 -sTCP:LISTEN
ps aux | grep '[o]penclaw\\|[n]ode'
tail -200 /Users/ilkeraktuna/.openclaw/logs/gateway.err.log
tail -200 /Users/ilkeraktuna/.openclaw/logs/gateway.log
#

Also run this isolation test — it’s the most likely culprit from your log:

mv ~/.openclaw/extensions/openclaw-web-search ~/.openclaw/extensions/openclaw-web-search.disabled

Then start again:

sudo -u ilkeraktuna env \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose
#

If it still stops at [plugins]..., try a clean no-channel startup to see if a channel/plugin init is blocking bind:

OPENCLAW_SKIP_CHANNELS=1 sudo -u ilkeraktuna env \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose

Then check:

lsof -nP -iTCP:18789 -sTCP:LISTEN
#

Small shell nuance: put OPENCLAW_SKIP_CHANNELS=1 inside the env if the first form complains.

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % lsof -nP -iTCP:18789 -sTCP:LISTEN
ps aux | grep '[o]penclaw\|[n]ode'
ilkeraktuna@ilkers-Mac-mini ~ % tail -20 /Users/ilkeraktuna/.openclaw/logs/gateway.err.log
2026-04-29T21:30:59.877+03:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search (/Users/ilkeraktuna/.openclaw/extensions/openclaw-web-search/index.ts). Set plugins.allow to explicit trusted ids.
2026-04-29T21:35:45.791+03:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search (/Users/ilkeraktuna/.openclaw/extensions/openclaw-web-search/index.ts). Set plugins.allow to explicit trusted ids.
2026-04-29T21:47:38.926+03:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search (/Users/ilkeraktuna/.openclaw/extensions/openclaw-web-search/index.ts). Set plugins.allow to explicit trusted ids.
2026-04-29T21:47:51.299+03:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search (/Users/ilkeraktuna/.openclaw/extensions/openclaw-web-search/index.ts). Set plugins.allow to explicit trusted ids.
ilkeraktuna@ilkers-Mac-mini ~ % tail -5 /Users/ilkeraktuna/.openclaw/logs/gateway.log
2026-04-29T21:30:59.084+03:00 [gateway] resolving authentication…
2026-04-29T21:30:59.085+03:00 [gateway] starting...
2026-04-29T21:35:44.963+03:00 [gateway] loading configuration…
2026-04-29T21:35:44.996+03:00 [gateway] resolving authentication…
2026-04-29T21:35:44.997+03:00 [gateway] starting...
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

No listener + no running node process means the gateway is exiting during startup, right after:

[gateway] starting...
[plugins] ... openclaw-web-search ...

So next isolate that extension. This is reversible:

mv ~/.openclaw/extensions/openclaw-web-search ~/.openclaw/extensions/openclaw-web-search.disabled

Then run the gateway with exit-code capture:

# 
sudo -u ilkeraktuna env \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  OPENCLAW_SKIP_CHANNELS=1 \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose ; echo "EXIT:$?"

Then in another terminal:

lsof -nP -iTCP:18789 -sTCP:LISTEN
openclaw gateway status --require-rpc --json
#

If it starts with OPENCLAW_SKIP_CHANNELS=1, then a channel init is killing startup. If it starts only after disabling openclaw-web-search, the extension is the problem.

Also grab a wider log slice after that run:

tail -100 ~/.openclaw/logs/gateway.log
tail -100 ~/.openclaw/logs/gateway.err.log

One more thing: don’t re-enable the LaunchDaemon until the foreground gateway reliably reaches LISTEN. Right now launchd would just keep restarting a process that exits immediately.

night harbor
#

lsof -nP -iTCP:18789 -sTCP:LISTEN
openclaw gateway status --require-rpc --json
|
o
{
"logFile": "/tmp/openclaw/openclaw-2026-04-29.log",
"service": {
"label": "LaunchAgent",
"loaded": false,
"loadedText": "loaded", ---------- this is a very long output. which part do you need ? also ilkeraktuna@ilkers-Mac-mini ~ % tail -2 ~/.openclaw/logs/gateway.log
2026-04-29T21:48:33.691+03:00 [gateway] resolving authentication…
2026-04-29T21:48:33.692+03:00 [gateway] starting...
ilkeraktuna@ilkers-Mac-mini ~ % tail -2 ~/.openclaw/logs/gateway.err.log
2026-04-29T21:48:27.521+03:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search (/Users/ilkeraktuna/.openclaw/extensions/openclaw-web-search/index.ts). Set plugins.allow to explicit trusted ids.
2026-04-29T21:48:34.491+03:00 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: openclaw-web-search (/Users/ilkeraktuna/.openclaw/extensions/openclaw-web-search/index.ts). Set plugins.allow to explicit trusted ids.
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

For the long JSON, just this slice is enough — no secrets:

openclaw gateway status --require-rpc --json \
  | sed -n '/^{/,$p' \
  | jq '{service:{loaded:.service.loaded,runtime:.service.runtime,command:.service.command.programArguments}, gateway:.gateway, port:.port, portCli:.portCli, rpc:.rpc, health:.health, lastError:.lastError, extraServices:.extraServices}'

If jq isn’t installed, paste only these top-level sections:

  • service.runtime
  • gateway
  • port / portCli
  • rpc
  • health
  • lastError
  • extraServices
#

But more importantly: your latest gateway.err.log still shows openclaw-web-search, so it looks like that extension was not disabled yet. Please run:

mv ~/.openclaw/extensions/openclaw-web-search ~/.openclaw/extensions/openclaw-web-search.disabled

Then retry the foreground command with exit capture:

sudo -u ilkeraktuna env \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  OPENCLAW_SKIP_CHANNELS=1 \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
# 
  gateway --port 18789 --verbose ; echo "EXIT:$?"

Then paste:

lsof -nP -iTCP:18789 -sTCP:LISTEN
tail -40 ~/.openclaw/logs/gateway.log
tail -40 ~/.openclaw/logs/gateway.err.log

If the gateway exits, the EXIT: value is very useful. If it stays running and lsof shows LISTEN, we’ve found the blocker.

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % openclaw gateway status --require-rpc --json
| sed -n '/^{/,$p'
| jq '{service:{loaded:.service.loaded,runtime:.service.runtime,command:.service.command.programArguments}, gateway:.gateway, port:.port, portCli:.portCli, rpc:.rpc, health:.health, lastError:.lastError, extraServices:.extraServices}'
ilkeraktuna@ilkers-Mac-mini ~ % lsof -nP -iTCP:18789 -sTCP:LISTEN
ilkeraktuna@ilkers-Mac-mini ~ % ---------- I already sent you last 2 lines of each log. They are repeating. Don't ask me for long outputs because discord does not allow me to send long text

eager gustBOT
#

You’re right — sorry, let’s stop with long output requests. We can do this with tiny yes/no checks.

First, please run exactly this:

test -d ~/.openclaw/extensions/openclaw-web-search && echo WEBSEARCH_PRESENT || echo WEBSEARCH_DISABLED

If it says WEBSEARCH_PRESENT, disable it:

mv ~/.openclaw/extensions/openclaw-web-search ~/.openclaw/extensions/openclaw-web-search.disabled

Then run the gateway again. If it returns to the shell, paste only the EXIT: line:

# 
sudo -u ilkeraktuna env HOME=/Users/ilkeraktuna OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw OPENCLAW_SKIP_CHANNELS=1 PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789 --verbose ; echo EXIT:$?

While that command is still running, in another terminal:

lsof -nP -iTCP:18789 -sTCP:LISTEN || echo NO_LISTENER

Paste only:

  • WEBSEARCH_PRESENT / WEBSEARCH_DISABLED
  • EXIT:<number> if it exits
  • NO_LISTENER or the one lsof line

No logs needed unless this still doesn’t isolate it.

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % test -d ~/.openclaw/extensions/openclaw-web-search && echo WEBSEARCH_PRESENT || echo WEBSEARCH_DISABLED
WEBSEARCH_DISABLED
ilkeraktuna@ilkers-Mac-mini ~ % sudo -u ilkeraktuna env HOME=/Users/ilkeraktuna OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw OPENCLAW_SKIP_CHANNELS=1 PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789 --verbose ; echo EXIT:$?
Config warnings:

  • plugins.entries.openclaw-web-search: plugin not found: openclaw-web-search (stale config entry ignored; remove it from plugins config)

🦞 OpenClaw 2026.4.24 (cbcfdf6) — I'll butter your workflow like a lobster roll: messy, delicious, effective.

|
o Config warnings ---------------------------------------------------------------------+
| |
| - plugins.entries.openclaw-web-search: plugin not found: openclaw-web-search (stale |
| config entry ignored; remove it from plugins config) |
| |
+---------------------------------------------------------------------------------------+
|
o
22:09:05 [gateway] loading configuration…
22:09:05 [gateway] resolving authentication…
22:09:05 [gateway] starting... ---------- stucks here , does not return to shell , and "lsof -nP -iTCP:18789 -sTCP:LISTEN || echo NO_LISTENER
" output is empty

#

ilkeraktuna@ilkers-Mac-mini ~ % lsof -nP -iTCP:18789 -sTCP:LISTEN || echo NO_LISTENER

NO_LISTENER

eager gustBOT
#

Got it. Since WEBSEARCH_DISABLED + OPENCLAW_SKIP_CHANNELS=1 still hangs before LISTEN, the next useful thing is a startup trace, not more log spam.

Run this single diagnostic; it captures 10 seconds, prints only the last startup trace lines, then stops the stuck gateway:

OPENCLAW_GATEWAY_STARTUP_TRACE=1 sudo -u ilkeraktuna env \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  OPENCLAW_SKIP_CHANNELS=1 \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-gateway.pid

sleep 10
grep 'startup trace' /tmp/oc-gateway-start.log | tail -8
# 
lsof -nP -iTCP:18789 -sTCP:LISTEN || echo NO_LISTENER
kill "$(cat /tmp/oc-gateway.pid)" 2>/dev/null

Paste only those startup trace lines plus NO_LISTENER/listener result.

Also clean the stale plugin config entry when convenient:

openclaw config unset plugins.entries.openclaw-web-search

The key now is: which startup trace span is last. That tells us exactly what it’s hanging on before the HTTP server binds.

#

NO_LISTENER confirms it’s hanging before the HTTP/WebSocket bind.

I still need the startup trace lines from that diagnostic — just the grep output, not logs. Run/paste this small bit:

grep 'startup trace' /tmp/oc-gateway-start.log | tail -8

If that file doesn’t exist yet, run the full trace command from my previous message, then paste only:

grep 'startup trace' /tmp/oc-gateway-start.log | tail -8

Also quick correction: put the trace env inside env so it definitely reaches the sudo -u process:

# 
sudo -u ilkeraktuna env \
  OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  OPENCLAW_SKIP_CHANNELS=1 \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-gateway.pid
sleep 10
grep 'startup trace' /tmp/oc-gateway-start.log | tail -8
kill "$(cat /tmp/oc-gateway.pid)" 2>/dev/null

That should tell us the exact phase it’s stuck in.

night harbor
#

grep 'startup trace' /tmp/oc-gateway-start.log | tail -8
kill "$(cat /tmp/oc-gateway.pid)" 2>/dev/null
[2] 10431
[gateway] startup trace: cli.server-import 0.4ms total=0.4ms
2026-04-29T22:14:16.635+03:00 [gateway] startup trace: cli.config-load 7.7ms total=14.8ms
2026-04-29T22:14:16.642+03:00 [gateway] startup trace: cli.config-snapshot 6.3ms total=21.8ms
2026-04-29T22:14:16.643+03:00 [gateway] startup trace: cli.auth-resolve 0.1ms total=23.3ms
2026-04-29T22:14:16.644+03:00 [gateway] startup trace: cli.gateway-loop 0.8ms total=24.1ms
2026-04-29T22:14:17.376+03:00 [gateway] startup trace: config.snapshot 67.9ms total=67.9ms
2026-04-29T22:14:17.378+03:00 [gateway] startup trace: config.auth 1.3ms total=70.7ms
2026-04-29T22:14:17.379+03:00 [gateway] startup trace: control-ui.seed 0.0ms total=71.4ms
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

Perfect — that trace is useful. It gets through:

control-ui.seed

and then never reaches plugins.bootstrap, so the hang is in the plugin bootstrap / startup maintenance phase, before HTTP binds.

Do one temporary isolation:

openclaw config set plugins.enabled false --strict-json

Then retry the short foreground startup:

# 
sudo -u ilkeraktuna env HOME=/Users/ilkeraktuna OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw OPENCLAW_SKIP_CHANNELS=1 PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789 --verbose

In another terminal:

lsof -nP -iTCP:18789 -sTCP:LISTEN || echo NO_LISTENER

Also clean the stale entry:

openclaw config unset plugins.entries.openclaw-web-search

If disabling plugins makes it listen, we’ve confirmed the regression is in plugin bootstrap. Then keep the gateway usable for now with plugins disabled, or re-enable and narrow the specific plugin:

# 
openclaw config unset plugins.enabled

If it still says NO_LISTENER even with plugins.enabled=false, then the remaining suspect is startup session migration, not plugin loading.

night harbor
#

after following 2 lines , it started listening. ilkeraktuna@ilkers-Mac-mini ~ % lsof -nP -iTCP:18789 -sTCP:LISTEN || echo NO_LISTENER

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 11988 ilkeraktuna 24u IPv4 0xa02f43b6a1696605 0t0 TCP *:18789 (LISTEN)
ilkeraktuna@ilkers-Mac-mini ~ % --------- but I can't connect to it (browser) even if I do port binding with reverse ssh. openclaw config set plugins.enabled false --strict-json

openclaw config unset plugins.entries.openclaw-web-search

eager gustBOT
#

Nice — that confirms the startup blocker is plugin bootstrap. Keep:

plugins.enabled=false

as the workaround for now.

For browser access: don’t use reverse SSH yet. Use a local forward from the browser machine:

ssh -N -L 18789:127.0.0.1:18789 ilkeraktuna@192.168.254.170

Then open:

# 
http://127.0.0.1:18789/

On the Mac mini, run:

openclaw dashboard --no-open

Use that token/URL locally, but don’t paste the token here. If the browser has stale auth, open an incognito window or clear site data for 127.0.0.1:18789, then paste the token in Overview → Gateway Access → Gateway Token.

Tiny checks if it still fails:

curl -sS -o /dev/null -w "HTTP:%{http_code}\n" http://127.0.0.1:18789/
# 
openclaw gateway status --require-rpc | grep -E 'Read probe|Connectivity probe|Capability'

Paste only those two short outputs.

night harbor
#

I did that forwad but http://127.0.0.1:18789/ does not open ilkeraktuna@ilkers-Mac-mini ~ % lsof -nP -iTCP:18789 -sTCP:LISTEN || echo NO_LISTENER
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 11988 ilkeraktuna 24u IPv4 0xa02f43b6a1696605 0t0 TCP *:18789 (LISTEN)
ilkeraktuna@ilkers-Mac-mini ~ % sudo netstat -an | grep 18789
Password:
tcp4 522 0 192.168.254.170.18789 192.168.254.150.62182 ESTABLISHED
tcp4 78 0 127.0.0.1.18789 127.0.0.1.50241 CLOSE_WAIT
tcp4 0 0 127.0.0.1.50241 127.0.0.1.18789 FIN_WAIT_2
tcp4 0 0 127.0.0.1.18789 127.0.0.1.50233 CLOSE_WAIT
tcp4 0 0 127.0.0.1.50233 127.0.0.1.18789 FIN_WAIT_2
tcp4 685 0 127.0.0.1.18789 127.0.0.1.50232 CLOSE_WAIT
tcp4 0 0 127.0.0.1.50232 127.0.0.1.18789 FIN_WAIT_2
tcp4 522 0 192.168.254.170.18789 192.168.254.150.50658 CLOSE_WAIT
tcp4 0 0 127.0.0.1.18789 127.0.0.1.50213 CLOSE_WAIT
tcp4 0 0 127.0.0.1.50213 127.0.0.1.18789 FIN_WAIT_2
tcp4 717 0 127.0.0.1.18789 127.0.0.1.50212 CLOSE_WAIT
tcp4 0 0 127.0.0.1.50212 127.0.0.1.18789 FIN_WAIT_2
tcp4 522 0 192.168.254.170.18789 192.168.254.150.50734 CLOSE_WAIT
tcp4 750 0 127.0.0.1.18789 127.0.0.1.50208 CLOSE_WAIT
tcp4 0 0 127.0.0.1.50208 127.0.0.1.18789 FIN_WAIT_2
tcp4 522 0 192.168.254.170.18789 192.168.254.150.58262 CLOSE_WAIT
tcp4 0 0 *.18789 . LISTEN
ilkeraktuna@ilkers-Mac-mini ~ % curl -sS -o /dev/null -w "HTTP:%{http_code}\n" http://127.0.0.1:18789/
^C
ilkeraktuna@ilkers-Mac-mini ~ % curl http://127.0.0.1:18789/
^C
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

Good catch: if curl on the Mac mini itself hangs, this is not SSH/browser/token yet. The gateway has bound the port, but the HTTP handler/event loop is stuck after bind.

Let’s get one tiny trace of the new stuck phase:

kill 11988 2>/dev/null

sudo -u ilkeraktuna env \
  OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
  OPENCLAW_SKIP_CHANNELS=1 \
  OPENCLAW_SKIP_PROVIDERS=1 \
  OPENCLAW_NO_AUTO_UPDATE=1 \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
# 
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-gateway.pid

sleep 10
grep 'startup trace' /tmp/oc-gateway-start.log | tail -12
curl --max-time 3 -sS -o /dev/null -w "HTTP:%{http_code}\n" http://127.0.0.1:18789/

Paste only those 12 trace lines + the HTTP: line.

For SSH later, use a different local port to avoid collisions:

ssh -N -L 18790:127.0.0.1:18789 ilkeraktuna@192.168.254.170
#

Then open http://127.0.0.1:18790/. But first local curl must stop hanging.

night harbor
#

grep 'startup trace' /tmp/oc-gateway-start.log | tail -12
[1] 13653

2026-04-29T22:40:39.894+03:00 [gateway] startup trace: sidecars.gmail-model 0.0ms total=149.4ms
2026-04-29T22:40:39.894+03:00 [gateway] startup trace: sidecars.internal-hooks 0.0ms total=149.8ms
2026-04-29T22:40:39.895+03:00 [gateway] startup trace: sidecars.channels 0.4ms total=150.5ms
2026-04-29T22:40:39.896+03:00 [gateway] startup trace: sidecars.plugin-services 0.4ms total=151.5ms
2026-04-29T22:40:39.896+03:00 [gateway] startup trace: sidecars.memory 0.0ms total=151.8ms
2026-04-29T22:40:39.897+03:00 [gateway] startup trace: sidecars.restart-sentinel 0.3ms total=152.5ms
2026-04-29T22:40:39.898+03:00 [gateway] startup trace: sidecars.subagent-recovery 1.0ms total=153.8ms
2026-04-29T22:40:39.902+03:00 [gateway] startup trace: sidecars.main-session-recovery 2.4ms total=157.6ms
2026-04-29T22:40:39.903+03:00 [gateway] startup trace: sidecars.total 11.2ms total=157.9ms
2026-04-29T22:40:39.903+03:00 [gateway] startup trace: sidecars.ready 0.3ms total=158.2ms
2026-04-29T22:40:39.903+03:00 [gateway] startup trace: runtime.post-attach 17.4ms total=158.8ms
2026-04-29T22:40:39.904+03:00 [gateway] startup trace: ready 0.3ms total=159.1ms
ilkeraktuna@ilkers-Mac-mini ~ %
ilkeraktuna@ilkers-Mac-mini ~ % curl --max-time 3 -sS -o /dev/null -w "HTTP:%{http_code}\n" http://127.0.0.1:18789/
curl: (28) Operation timed out after 3012 milliseconds with 0 bytes received
HTTP:000
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

Ah — this may just be the background test process being stopped by the shell. It’s listening, but not servicing requests.

Check:

ps -o pid,stat,%cpu,etime,command -p "$(cat /tmp/oc-gateway.pid)"

If STAT contains T, it’s stopped. Restart it with stdin closed:

kill "$(cat /tmp/oc-gateway.pid)" 2>/dev/null

sudo -u ilkeraktuna env \
  OPENCLAW_SKIP_CHANNELS=1 \
  OPENCLAW_SKIP_PROVIDERS=1 \
# 
  OPENCLAW_NO_AUTO_UPDATE=1 \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose </dev/null >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-gateway.pid

Then:

curl --max-time 3 -sS -o /dev/null -w "HTTP:%{http_code}\n" http://127.0.0.1:18789/

If that returns HTTP:200/401 instead of timeout, the gateway is fine now. Then we can put the same env/config into your LaunchDaemon.

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % ps -o pid,stat,%cpu,etime,command -p "$(cat /tmp/oc-gateway.pid)"
PID STAT %CPU ELAPSED COMMAND
13653 SN 0.0 02:50 sudo -u ilkeraktuna env OPENCLAW_GATEWAY_STARTUP_TRACE=1 OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=
ilkeraktuna@ilkers-Mac-mini ~ % kill "$(cat /tmp/oc-gateway.pid)" 2>/dev/null
ilkeraktuna@ilkers-Mac-mini ~ % sudo -u ilkeraktuna env
OPENCLAW_SKIP_CHANNELS=1
OPENCLAW_SKIP_PROVIDERS=1
OPENCLAW_NO_AUTO_UPDATE=1
HOME=/Users/ilkeraktuna
OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw
PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
/opt/homebrew/opt/node@22/bin/node
/opt/homebrew/lib/node_modules/openclaw/dist/index.js
gateway --port 18789 --verbose </dev/null >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-gateway.pid
[2] 14039
ilkeraktuna@ilkers-Mac-mini ~ % curl --max-time 3 -sS -o /dev/null -w "HTTP:%{http_code}\n" http://127.0.0.1:18789/

curl: (28) Operation timed out after 3011 milliseconds with 0 bytes received
HTTP:000
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

That ps output is the clue: /tmp/oc-gateway.pid is the sudo wrapper, not the actual node process. Let’s remove sudo from the test and kill the real listener first.

Run exactly:

lsof -tiTCP:18789 -sTCP:LISTEN | xargs -r kill
sleep 1
lsof -nP -iTCP:18789 -sTCP:LISTEN || echo CLEAN

Then start it directly as your current user:

env \
  OPENCLAW_SKIP_CHANNELS=1 \
  OPENCLAW_SKIP_PROVIDERS=1 \
# 
  OPENCLAW_NO_AUTO_UPDATE=1 \
  HOME=/Users/ilkeraktuna \
  OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw \
  PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin \
  /opt/homebrew/opt/node@22/bin/node \
  /opt/homebrew/lib/node_modules/openclaw/dist/index.js \
  gateway --port 18789 --verbose </dev/null >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-node.pid

Then test the unauthenticated health endpoint:

ps -o pid,stat,%cpu,etime,command -p "$(cat /tmp/oc-node.pid)"
curl --max-time 3 -sS http://127.0.0.1:18789/healthz
#

Paste only those two outputs. If /healthz responds, browser/tunnel is next. If it still times out, the node event loop is wedged after startup.

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % lsof -tiTCP:18789 -sTCP:LISTEN | xargs -r kill
sleep 1
lsof -nP -iTCP:18789 -sTCP:LISTEN || echo CLEAN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 13656 ilkeraktuna 23u IPv4 0xd11b951c123cfdb7 0t0 TCP *:18789 (LISTEN)
ilkeraktuna@ilkers-Mac-mini ~ % env
OPENCLAW_SKIP_CHANNELS=1
OPENCLAW_SKIP_PROVIDERS=1
OPENCLAW_NO_AUTO_UPDATE=1
HOME=/Users/ilkeraktuna
OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw
PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
/opt/homebrew/opt/node@22/bin/node
/opt/homebrew/lib/node_modules/openclaw/dist/index.js
gateway --port 18789 --verbose </dev/null >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-node.pid
[3] 14277
ilkeraktuna@ilkers-Mac-mini ~ % ps -o pid,stat,%cpu,etime,command -p "$(cat /tmp/oc-node.pid)"
PID STAT %CPU ELAPSED COMMAND
14277 SN 0.2 00:07 openclaw-gateway
ilkeraktuna@ilkers-Mac-mini ~ % curl --max-time 3 -sS http://127.0.0.1:18789/healthz
curl: (28) Operation timed out after 3011 milliseconds with 0 bytes received
ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

That kill didn’t actually remove the old listener:

node 13656 ... TCP *:18789 (LISTEN)

So your curl is still hitting the old wedged gateway, not the new test process.

Force-kill only whatever owns port 18789:

pids="$(lsof -tiTCP:18789 -sTCP:LISTEN)"
echo "$pids"
[ -n "$pids" ] && kill -9 $pids
sleep 1
lsof -nP -iTCP:18789 -sTCP:LISTEN || echo CLEAN
#

Only continue once it prints CLEAN.

Then start fresh:

env OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1 HOME=/Users/ilkeraktuna OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789 --verbose </dev/null >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-node.pid

Then:

lsof -nP -iTCP:18789 -sTCP:LISTEN
curl --max-time 3 -sS http://127.0.0.1:18789/healthz

Paste only those two outputs.

night harbor
#

lsof -nP -iTCP:18789 -sTCP:LISTEN || echo CLEAN
13656
[1] killed sudo -u ilkeraktuna env OPENCLAW_GATEWAY_STARTUP_TRACE=1 gateway >
CLEAN
ilkeraktuna@ilkers-Mac-mini ~ % env OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1 HOME=/Users/ilkeraktuna OPENCLAW_STATE_DIR=/Users/ilkeraktuna/.openclaw PATH=/opt/homebrew/opt/node@22/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789 --verbose </dev/null >/tmp/oc-gateway-start.log 2>&1 & echo $! >/tmp/oc-node.pid
[1] 14427
ilkeraktuna@ilkers-Mac-mini ~ % lsof -nP -iTCP:18789 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 14427 ilkeraktuna 21u IPv4 0x161ebd22e8126049 0t0 TCP *:18789 (LISTEN)
ilkeraktuna@ilkers-Mac-mini ~ % curl --max-time 3 -sS http://127.0.0.1:18789/healthz
curl: (28) Operation timed out after 3011 milliseconds with 0 bytes received
ilkeraktuna@ilkers-Mac-mini ~ %

#

this is getting weird. what might be the issue ? if it is config , I would say it should not because it was working before. If it is the binary, maybe we should update ?

eager gustBOT
#

Okay — now we have a very specific failure:

  • gateway reaches ready
  • port is listening
  • even /healthz hangs

That’s a wedged HTTP/event-loop state. At this point I’d stop trying to tune SSH/browser; the gateway process itself is unhealthy.

Two practical next steps:

1) Update off 2026.4.24

2026.4.24 has been looking suspicious in this thread. Please try:

openclaw update
#

Then repeat with plugins still disabled:

openclaw --version
env OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789 --verbose

2) If update doesn’t fix it, file this as a bug

Minimal repro summary:

macOS headless, OpenClaw 2026.4.24
plugins.enabled=false
OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1
gateway startup trace reaches "ready"
lsof shows TCP *:18789 LISTEN
# 
curl http://127.0.0.1:18789/healthz times out with 0 bytes

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

For now, keep plugins.enabled=false; that fixed the earlier pre-listen hang, but there’s a second HTTP-serving hang remaining.

GitHub
Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % df -h
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk3s1s1 228Gi 12Gi 49Gi 20% 458k 515M 0% /
devfs 201Ki 201Ki 0Bi 100% 697 0 100% /dev
/dev/disk3s6 228Gi 24Ki 49Gi 1% 0 515M 0% /System/Volumes/VM
/dev/disk3s2 228Gi 17Gi 49Gi 26% 2.1k 515M 0% /System/Volumes/Preboot
/dev/disk3s4 228Gi 735Mi 49Gi 2% 462 515M 0% /System/Volumes/Update
/dev/disk1s2 500Mi 6.0Mi 483Mi 2% 1 4.9M 0% /System/Volumes/xarts
/dev/disk1s1 500Mi 6.0Mi 483Mi 2% 37 4.9M 0% /System/Volumes/iSCPreboot
/dev/disk1s3 500Mi 548Ki 483Mi 1% 74 4.9M 0% /System/Volumes/Hardware
/dev/disk3s5 228Gi 147Gi 49Gi 75% 883k 515M 0% /System/Volumes/Data
map auto_home 0Bi 0Bi 0Bi 100% 0 0 - /System/Volumes/Data/home
/dev/disk3s1 228Gi 12Gi 49Gi 20% 458k 515M 0% /System/Volumes/Update/mnt1
ilkeraktuna@ilkers-Mac-mini ~ % ---------- is there a problem here ?

eager gustBOT
#

Yeah — I agree, this now smells more like a 2026.4.24 binary/regression triggered by your existing config/plugin state, not “your config is wrong”.

What we know:

  1. openclaw-web-search / plugin bootstrap blocked startup before listen.
  2. plugins.enabled=false let it reach ready.
  3. But even /healthz times out after bind, which is not normal.

So yes: update off 2026.4.24.

Suggested safe sequence:

# stop wedged gateway
lsof -tiTCP:18789 -sTCP:LISTEN | xargs -r kill -9
# 
# keep current workaround
openclaw config set plugins.enabled false --strict-json
openclaw config unset plugins.entries.openclaw-web-search

# update
openclaw update
openclaw --version

Then test manually before LaunchDaemon:

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789 --verbose

In another terminal:

# 
curl --max-time 3 http://127.0.0.1:18789/healthz

If that works after update, we can fix the LaunchDaemon env and then cautiously re-enable plugins. If it still hangs after update, this is a strong GitHub issue with a clean repro.
Docs: https://docs.openclaw.ai/gateway

#

No, disk space looks fine. You have ~49 GiB free and inode usage is basically 0%, so this doesn’t look like a storage/full-disk issue.

The relevant evidence still points elsewhere:

  • plugin/bootstrap issue: fixed enough by plugins.enabled=false
  • gateway reaches ready
  • port listens
  • /healthz still times out

So I’d proceed with updating off 2026.4.24:

lsof -tiTCP:18789 -sTCP:LISTEN | xargs -r kill -9
openclaw update
openclaw --version
#

Then retest:

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789 --verbose

And in another terminal:

curl --max-time 3 http://127.0.0.1:18789/healthz
night harbor
#

ilkeraktuna@ilkers-Mac-mini ~ % openclaw update

|
o Config warnings -------------------------------------------------------------------+
| |
| - plugins.entries.comfy: plugin disabled (plugins disabled) but config is present |
| |
+-------------------------------------------------------------------------------------+
Updating OpenClaw...

|
o âś“ Updating via package manager (9.11s)
|
o âś“ Running doctor checks (5.08s)

Update Result: OK
Root: /opt/homebrew/lib/node_modules/openclaw
Before: 2026.4.24
After: 2026.4.26

Total time: 14.64s
|
o Config warnings -------------------------------------------------------------------+
| |
| - plugins.entries.comfy: plugin disabled (plugins disabled) but config is present |
| |
+-------------------------------------------------------------------------------------+

Updating plugins...
No plugin updates needed.

Restarting service...
Gateway aborted: config is invalid.
plugins.entries.feishu: plugin feishu: plugin requires OpenClaw >=2026.4.25, but this host is 2026.4.24; skipping load
plugins.entries.whatsapp: plugin whatsapp: plugin requires OpenClaw >=2026.4.25, but this host is 2026.4.24; skipping load
Fix the config and retry, or run "openclaw doctor" to repair.
u0m% ilkeraktuna@ilkers-Mac-mini ~ %

eager gustBOT
#

Update probably succeeded. The confusing part is likely the old 2026.4.24 process continuing after it replaced the package, so its post-update restart/check still thinks the host is 2026.4.24.

Run:

hash -r
openclaw --version
which openclaw

If it says 2026.4.26, good. Then clean old listeners and retest:

lsof -tiTCP:18789 -sTCP:LISTEN | xargs -r kill -9

OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1 \
# 
openclaw gateway --port 18789 --verbose

In another terminal:

curl --max-time 3 http://127.0.0.1:18789/healthz

If /healthz works now, the binary update fixed the weird hang. Then we can update your LaunchDaemon plist/env.

The plugins.entries.comfy warning is not fatal. It just says plugin config exists while plugins.enabled=false. Keep plugins disabled until gateway health is confirmed.

night harbor
#

ok. çalıştı gibi : ilkeraktuna@ilkers-Mac-mini ~ % curl --max-time 3 http://127.0.0.1:18789/healthz
{"ok":true,"status":"live"}% ilkeraktuna@ilkers-Mac-mini ~ % ---------- web UI da geldi. ama birseyleri disable ettik: openclaw config set plugins.enabled false --strict-json

openclaw config unset plugins.entries.openclaw-web-search
------- bunları açalım mı

eager gustBOT
#

Süper, en kritik kısım çözüldü 🎉

Evet, şimdi dikkatli şekilde açalım. Önce sadece global plugin kapatmasını kaldır:

openclaw config unset plugins.enabled

Sonra gateway’i temiz restart/test et:

lsof -tiTCP:18789 -sTCP:LISTEN | xargs -r kill -9
OPENCLAW_SKIP_CHANNELS=1 OPENCLAW_SKIP_PROVIDERS=1 OPENCLAW_NO_AUTO_UPDATE=1 openclaw gateway --port 18789 --verbose

BaĹźka terminalde:

# 
curl --max-time 3 http://127.0.0.1:18789/healthz

Eğer çalışırsa, plugin sistemi genel olarak OK.
openclaw-web-search’ü hemen geri eklemeyelim; o zaten stale/problemli görünüyordu. Web search gerekiyorsa sonra temiz reinstall/update etmek daha iyi.

comfy uyarısı çıkarsa fatal değil; sadece config var ama plugin durumu uyumsuz olabilir.

night harbor
#

openclaw-web-search 'ü eklemek için ne yapmam lazım. bana bir config yaptırdın bir de dosyayı taşıttın

eager gustBOT
#

Evet, ama tek tek açalım. Biz iki şey yaptık:

  1. Tüm plugin’leri kapattık:
openclaw config set plugins.enabled false --strict-json
  1. openclaw-web-search klasörünü taşıdık ve config entry’sini sildik.

Şimdi geri almak için:

openclaw config unset plugins.enabled

Sonra klasörü geri taşı:

# 
mv ~/.openclaw/extensions/openclaw-web-search.disabled ~/.openclaw/extensions/openclaw-web-search

Sonra plugin’i enable etmeyi dene:

openclaw plugins enable openclaw-web-search

Eğer “plugin not found” derse:

openclaw plugins install ~/.openclaw/extensions/openclaw-web-search --force
openclaw plugins enable openclaw-web-search
#

Sonra gateway’i test et:

lsof -tiTCP:18789 -sTCP:LISTEN | xargs -r kill -9
openclaw gateway --port 18789 --verbose

BaĹźka terminalde:

curl --max-time 3 http://127.0.0.1:18789/healthz

Eğer tekrar bozulursa hızlı geri dönüş: