#Openclaw Not Working

1 messages · Page 1 of 1 (latest)

steady osprey
#

│ OS │ macos 14.8.5 (x64) · node 22.22.2 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale exposure │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest unknown │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · │
│ │ unreachable (timeout) │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 389) │
│ Node service │ LaunchAgent not installed │
│ Agents │ 1 · 1 bootstrap file present · sessions 2 · default │
│ │ main active 11m ago │
│ Memory │ enabled (plugin memory-core) · unavailable │
│ Plugin compatibility │ none │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Tasks │ none │
│ Heartbeat │ 30m (main) │
│ Sessions │ 2 active · default gemini-3.1-flash-lite-preview │
│ │ (200k ctx) · ~/.openclaw/agents/main/sessions/ │
│ │ sessions.json │

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴────────────────────────────────────────────────┘

rancid radishBOT
#

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

spice siloBOT
#

This looks like LaunchAgent is running, but the Gateway isn’t actually answering on 127.0.0.1:18789. Ignore Memory unavailable for now — that may just be fallout from the gateway timeout.

Please run/paste:

openclaw --version
openclaw gateway status --deep
openclaw gateway probe
openclaw logs --follow

If logs can’t connect, use the file log directly:

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"
steady osprey
#

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/Users/akkarthikeyan/.nvm/versions/node/v22.22.2/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/Users/akkarthikeyan/.nvm/versions/node/v22.22.2/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 2910)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Gateway port 18789 is not listening (service appears running).
Last gateway error: 2026-04-29T21:08:00.077+05:30 [ws] closed before connect conn=c284b6ca-40cc-4188-bcdb-4979377a9792 peer=127.0.0.1:18789 remote=? fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
Logs: ~/.openclaw/logs/gateway.log
Errors: ~/.openclaw/logs/gateway.err.log
Restart log: ~/.openclaw/logs/gateway-restart.log

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Yep — this narrows it down. The LaunchAgent process exists, but nothing is listening on port 18789, so the gateway is failing before it fully starts.

Do this next:

openclaw doctor

If it offers to repair the gateway service config, say yes. Or run the direct repair:

openclaw doctor --repair
openclaw gateway restart
openclaw gateway status

The important warning is the nvm one:

# 
Gateway service uses Node from a version manager
/Users/akkarthikeyan/.nvm/versions/node/v22.22.2/bin/node

LaunchAgents don’t load your normal shell init, so nvm-pinned services are fragile. Doctor should rewrite the service to a more stable config if possible.

If it still fails after repair, paste these logs:

tail -n 200 ~/.openclaw/logs/gateway.err.log
tail -n 200 ~/.openclaw/logs/gateway-restart.log
tail -n 200 ~/.openclaw/logs/gateway.log

Also useful:

# 
openclaw --version
lsof -nP -iTCP:18789 -sTCP:LISTEN
steady osprey
#

con i remove nvm itself

spice siloBOT
#

You can, but don’t remove nvm first. The problem isn’t “nvm exists” — it’s that the LaunchAgent is pinned to nvm’s Node path.

Safer order:

brew install node
corepack enable
which node
node -v

Make sure which node is not under ~/.nvm/.

Then repair OpenClaw’s service:

# 
openclaw doctor --repair
openclaw gateway restart
openclaw gateway status

Before deleting nvm, check what would break:

which node
which pnpm
which openclaw

If any of those still point into ~/.nvm/, removing nvm will break them. Once they don’t, removing nvm is optional.

Docs: https://docs.openclaw.ai/install/node

steady osprey
#

akkarthikeyan@As-MacBook-Air ~ % which node
which pnpm
which openclaw
/usr/local/bin/node
pnpm not found
/usr/local/bin/openclaw
akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

That’s better — your current shell is using system/Homebrew-ish paths now:

/usr/local/bin/node
/usr/local/bin/openclaw

pnpm not found is separate. I’d do this next:

node -v
openclaw --version
openclaw doctor --repair
openclaw gateway restart
openclaw gateway status --deep
#

The key thing: even though your shell now uses /usr/local/bin/node, the installed LaunchAgent may still be pinned to the old nvm Node path until doctor --repair rewrites it.

If you want pnpm available too:

corepack enable
corepack prepare pnpm@latest --activate
pnpm -v

If doctor --repair still reports the service using ~/.nvm/..., force-rewrite the service:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep
steady osprey
#

Installed LaunchAgent: /Users/akkarthikeyan/Library/LaunchAgents/ai.openclaw.gateway.plist
Logs: /Users/akkarthikeyan/.openclaw/logs/gateway.log

🦞 OpenClaw 2026.4.26 (be8c246)
I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

🦞 OpenClaw 2026.4.26 (be8c246)
I'm not magic—I'm just extremely persistent with retries and coping strategies.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /usr/local/bin/node /usr/local/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

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/Users/akkarthikeyan/.nvm/versions/node/v22.22.2/bin)
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 6474)
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 6474 akkarthikeyan: 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
    akkarthikeyan@As-MacBook-Air ~ %
spice siloBOT
#

Good news: the service command is fixed now:

/usr/local/bin/node /usr/local/lib/node_modules/openclaw/dist/index.js gateway --port 18789

So the old nvm Node executable problem is mostly gone. The remaining nvm warning is about the service PATH, not the command itself.

The real issue now is: the gateway process is listening, but the WebSocket probe times out. That usually means it’s stuck during startup or throwing in the logs.

Please paste:

tail -n 200 /tmp/openclaw/openclaw-2026-04-29.log
tail -n 200 ~/.openclaw/logs/gateway.err.log
tail -n 100 ~/.openclaw/logs/gateway-restart.log
#

Also run this once more after ~10 seconds:

openclaw gateway status --deep

If you want to clean the remaining PATH warning too:

openclaw doctor --repair --force
openclaw gateway restart

But don’t chase that warning first — logs are the key now. The gateway is alive enough to bind the port, but not healthy enough to answer.

steady osprey
#

2or 15751ms (gateway fqdn=A’s MacBook Air (OpenClaw)._openclaw-gw._tcp.local. host=As-MacBook-Air.local. port=18789 state=probing))
2026-04-29T21:48:04.120+05:30 [ws] closed before connect conn=3e1d52bb-0a0c-41fd-85de-d97b5ff8fe9c peer=127.0.0.1:50342->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
2026-04-29T21:49:53.158+05:30 (node:6474) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
2026-04-29T21:49:54.270+05:30 [gateway] security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run openclaw security audit.
2026-04-29T21:51:15.418+05:30 [plugins] bonjour: watchdog detected non-announced service; attempting re-advertise (gateway fqdn=A’s MacBook Air (OpenClaw)._openclaw-gw._tcp.local. host=As-MacBook-Air.local. port=18789 state=probing)
2026-04-29T21:51:15.615+05:30 [model-pricing] OpenRouter pricing fetch failed (timeout 60s): TimeoutError: The operation was aborted due to timeout
2026-04-29T21:51:15.622+05:30 [model-pricing] LiteLLM pricing fetch failed (timeout 60s): TimeoutError: The operation was aborted due to timeout
2026-04-29T21:51:37.054+05:30 [plugins] bonjour: restarting advertiser (service stuck in announcing for 21546ms (gateway fqdn=A’s MacBook Air (OpenClaw)._openclaw-gw._tcp.local. host=As-MacBook-Air.local. port=18789 state=announcing))
2026-04-29T21:51:37.462+05:30 [ws] closed before connect conn=2bde1c1f-618b-4a61-9bb5-97ad7c7674b7 peer=127.0.0.1:18789 remote=? fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1006 reason=n/a
tail: /Users/akkarthikeyan/.openclaw/logs/gateway-restart.log: No such file or directory
akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

That log is useful. The punycode warning is harmless, and missing gateway-restart.log is fine.

Two things are noisy/stalling startup:

  • remote pricing catalog fetches timing out after 60s
  • Bonjour/mDNS advertiser getting stuck/restarted

Try disabling both temporarily:

openclaw config set models.pricing.enabled false --strict-json
openclaw plugins disable bonjour
openclaw gateway restart
sleep 10
openclaw gateway status --deep
#

If it works, you can leave those off for now. Pricing only affects cost estimates; Bonjour only affects LAN auto-discovery.

If it still times out, paste:

grep -Ei "fatal|error|exception|listen|ready|started|failed|timeout" /tmp/openclaw/openclaw-2026-04-29.log | tail -200

Also: Port 18789 is already in use is okay here — it’s the OpenClaw gateway process itself listening, not necessarily a duplicate. The problem is that it’s listening but not completing the WS health probe.

steady osprey
#

{"0":"{"subsystem":"gateway/health-monitor"}","1":"started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)","_meta":{"runtime":"node","runtimeVersion":"24.13.1","hostname":"unknown","name":"{"subsystem":"gateway/health-monitor"}","parentNames":["openclaw"],"date":"2026-04-29T16:27:17.373Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":"/usr/local/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/usr/local/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-29T21:57:17.373+05:30","hostname":"As-MacBook-Air.local","message":"started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)"}
{"0":"{"subsystem":"gateway"}","1":"http server listening (7 plugins: acpx, browser, device-pair, memory-core, phone-control, talk-voice, telegram; 36.3s)","_meta":{"runtime":"node","runtimeVersion":"24.13.1","hostname":"unknown","name":"{"subsystem":"gateway"}","parentNames":["openclaw"],"date":"2026-04-29T16:27:17.836Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":"/usr/local/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":"/usr/local/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-29T21:57:17.836+05:30","hostname":"As-MacBook-Air.local","message":"http server listening (7 plugins: acpx, browser, device-pair, memory-core, phone-control, talk-voice, telegram; 36.3s)"}
akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Nice — that’s a good sign. This line means the gateway finally finished startup:

http server listening ... 36.3s

Now verify from the CLI:

openclaw gateway status --deep
openclaw status --deep

If Connectivity probe: ok, then you’re back. Open the dashboard:

# 
open http://127.0.0.1:18789/

I’d leave these disabled for now:

models.pricing.enabled = false
bonjour disabled

They’re not required for core OpenClaw. Pricing only affects cost estimates, and Bonjour only affects LAN auto-discovery.

If it’s working now, the likely fix was: rewrite stale nvm service config + disable startup tasks that were timing out/stalling.

steady osprey
#

akkarthikeyan@As-MacBook-Air ~ % openclaw gateway probe

🦞 OpenClaw 2026.4.26 (be8c246)
Claws out, commit in—let's ship something mildly responsible.

│
◇
Gateway Status
Reachable: no
Capability: unknown
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeout · Capability: unknown

akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Found 0 gateways via Bonjour is expected now because we disabled Bonjour. Ignore that part.

But Local loopback ... timeout means the gateway is still not completing the WS handshake within the default 3s. Try a longer probe first:

openclaw gateway probe --timeout 30000
openclaw gateway status --deep --timeout 30000
openclaw health --verbose --timeout 30000

Also check whether plain HTTP responds:

curl -v --max-time 10 http://127.0.0.1:18789/

If those still timeout, grab the newest errors around the probe time:

# 
tail -n 300 /tmp/openclaw/openclaw-2026-04-29.log | grep -Ei "fatal|error|exception|timeout|closed before connect|health|ws|listening|plugin"

The gateway is now starting, so we’re past the original nvm/LaunchAgent issue. This is now “server listening, but event loop / WS connect is stuck.”

steady osprey
#

🦞 OpenClaw 2026.4.26 (be8c246) — Ah, the fruit tree company! 🍎

Gateway LaunchAgent was installed but not loaded; re-bootstrapped launchd service.
akkarthikeyan@As-MacBook-Air ~ % tail -f ~/.openclaw/logs/gateway.log
2026-04-29T22:15:37.071+05:30 [gateway] loading configuration…
2026-04-29T22:15:37.403+05:30 [gateway] resolving authentication…
2026-04-29T22:15:37.408+05:30 [gateway] starting...
2026-04-29T22:15:58.062+05:30 [gateway] starting HTTP server...
2026-04-29T22:15:58.071+05:30 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /Users/akkarthikeyan/.openclaw/canvas)
2026-04-29T22:15:58.349+05:30 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
2026-04-29T22:15:58.765+05:30 [gateway] agent model: google/gemini-3.1-flash-lite-preview
2026-04-29T22:15:58.768+05:30 [gateway] http server listening (2 plugins: acpx, browser; 21.3s)
2026-04-29T22:15:58.771+05:30 [gateway] log file: /tmp/openclaw/openclaw-2026-04-29.log
2026-04-29T22:15:58.855+05:30 [gateway] starting channels and sidecars...

spice siloBOT
#

That’s progress. It’s now loaded and listening with only acpx + browser, so the startup is much cleaner.

Leave that tail -f running for another ~30 seconds. If it hangs after:

starting channels and sidecars...

then stop the tail with Ctrl+C and run:

openclaw gateway probe --timeout 30000
openclaw gateway status --deep --timeout 30000

If it still times out, paste the next log lines after starting channels and sidecars....

#

Also since it says the LaunchAgent “was installed but not loaded”, run:

openclaw doctor --repair

That should make the launchd state consistent so it survives restarts.

steady osprey
#

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeout · Capability: unknown

🦞 OpenClaw 2026.4.26 (be8c246)
I read logs so you can keep pretending you don't have to.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /usr/local/bin/node /usr/local/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

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/Users/akkarthikeyan/.nvm/versions/node/v22.22.2/bin)
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 8336)
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 8336 akkarthikeyan: 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
    akkarthikeyan@As-MacBook-Air ~ %
spice siloBOT
#

The important missing line is gateway ready. So it’s binding the port, then getting stuck during channels/sidecars startup.

Let’s isolate that:

cat >> ~/.openclaw/.env <<'EOF'
OPENCLAW_GATEWAY_STARTUP_TRACE=1
OPENCLAW_SKIP_CHANNELS=1
OPENCLAW_SKIP_STARTUP_MODEL_PREWARM=1
EOF

openclaw plugins disable acpx
openclaw gateway restart
sleep 15
openclaw gateway probe --timeout 30000
openclaw gateway status --deep --timeout 30000
#

Then check the log for trace lines:

grep -E "startup trace|gateway ready|starting channels|sidecars|error|failed|timeout" ~/.openclaw/logs/gateway.log | tail -200

If that works, the culprit is likely acpx or a startup sidecar, not the port or LaunchAgent anymore.

You can re-enable ACP later with:

openclaw plugins enable acpx

The remaining nvm PATH warning is annoying, but not the main blocker now — the command itself is using /usr/local/bin/node, which is good.

steady osprey
#

.4ms total=17784.9ms eventLoopMax=27.7ms
2026-04-29T22:25:19.672+05:30 [gateway] startup trace: sidecars.gmail-watch 0.2ms total=17789.1ms eventLoopMax=0.0ms
2026-04-29T22:25:19.676+05:30 [gateway] startup trace: sidecars.gmail-model 0.2ms total=17794.1ms eventLoopMax=0.0ms
2026-04-29T22:25:19.679+05:30 [gateway] startup trace: sidecars.internal-hooks 0.1ms total=17797.0ms eventLoopMax=0.0ms
2026-04-29T22:25:19.684+05:30 [gateway] startup trace: sidecars.channels 2.7ms total=17802.5ms eventLoopMax=0.0ms
2026-04-29T22:25:21.633+05:30 [gateway] startup trace: sidecars.plugin-services 1945.1ms total=19751.6ms eventLoopMax=0.0ms
2026-04-29T22:25:21.635+05:30 [gateway] startup trace: sidecars.memory 0.2ms total=19753.9ms eventLoopMax=0.0ms
2026-04-29T22:25:21.669+05:30 [gateway] startup trace: sidecars.restart-sentinel 30.4ms total=19786.2ms eventLoopMax=0.0ms
2026-04-29T22:25:21.778+05:30 [gateway] startup trace: sidecars.subagent-recovery 105.9ms total=19896.2ms eventLoopMax=0.0ms
2026-04-29T22:25:21.788+05:30 [gateway] startup trace: sidecars.main-session-recovery 6.9ms total=19906.4ms eventLoopMax=0.0ms
2026-04-29T22:25:21.817+05:30 [gateway] startup trace: sidecars.total 2156.9ms total=19908.9ms eventLoopMax=0.0ms
2026-04-29T22:25:21.821+05:30 [gateway] startup trace: sidecars.ready 29.1ms total=19938.0ms eventLoopMax=0.0ms
2026-04-29T22:25:21.828+05:30 [gateway] startup trace: runtime.post-attach 3590.3ms total=19945.9ms eventLoopMax=0.0ms
2026-04-29T22:25:21.830+05:30 [gateway] startup trace: ready 2.8ms total=19948.7ms eventLoopMax=0.0ms
akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Excellent — now it’s actually reaching ready:

startup trace: ready ... total=19948.7ms

So run the final verification:

openclaw gateway probe --timeout 30000
openclaw status --deep --timeout 30000

If that shows reachable/ok, you can keep this temporary “minimal startup” setup for now:

  • OPENCLAW_SKIP_CHANNELS=1
  • OPENCLAW_SKIP_STARTUP_MODEL_PREWARM=1
#
  • Bonjour disabled
  • pricing disabled
  • acpx disabled

Then re-enable things one at a time later to find the blocker. Start with channels last.

If it’s fixed, please mark the solution so it’s indexed on Answer Overflow:

right-click the solution message → Apps → ✅ Mark Solution. This helps future users.

steady osprey
#

Here's the breakdown. You have 62 enabled, and based on your config (only Google + Telegram credentials), most are dead weight.

Keep these (actively used or useful):

Plugin Why
google Your primary AI provider
browser Agent web access
document-extract Agent file handling
web-readability Agent web content

Safe to disable — unused AI providers (no credentials configured for any of these):

openclaw plugins disable \
  alibaba amazon-bedrock amazon-bedrock-mantle \
  anthropic anthropic-vertex arcee byteplus cerebras \
  chutes cloudflare-ai-gateway comfy copilot-proxy \
  deepseek fireworks github-copilot groq huggingface \
  kilocode kimi litellm lmstudio microsoft-foundry \
  minimax mistral moonshot nvidia ollama openai \
  opencode opencode-go openrouter qianfan qwen \
  runway sglang stepfun synthetic tencent together \
  venice vercel-ai-gateway vllm volcengine voyage \
  vydra xai xiaomi zai

Safe to disable — unused speech/TTS:

openclaw plugins disable \
  azure-speech deepgram elevenlabs inworld microsoft tts-local-cli

Safe to disable — unused channels:

openclaw plugins disable qqbot firecrawl senseaudio

That's ~50 plugins gone. Restart after and plugins.bootstrap should drop from 6.2s to under 1s.

Two things to confirm before running:

  1. Are you using Ollama or LM Studio locally for any models?
  2. Are you using firecrawl or xAI/Grok for any agents?

If no to both, run all three blocks and restart.

spice siloBOT
#

I’d not run that giant disable block yet.

Two cautions:

  1. If you use Telegram, you must keep telegram enabled — and right now OPENCLAW_SKIP_CHANNELS=1 means Telegram won’t start anyway.
  2. Mass-disabling provider plugins is reversible, but it can create confusing “model/provider not found” issues later.

Do this cleaner path first:

openclaw gateway probe --timeout 30000

If reachable, remove the temporary channel skip:

# 
perl -ni -e 'print unless /OPENCLAW_SKIP_CHANNELS=1/' ~/.openclaw/.env
openclaw gateway restart
openclaw gateway probe --timeout 30000

If it breaks only after re-enabling channels, then the Telegram/channel side is the blocker.

If you still want to trim plugins, first snapshot:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.before-plugin-trim
openclaw plugins list --enabled

And keep at least:

# 
google
telegram
browser
memory-core   # if you want memory
document-extract
web-readability

I’d optimize plugins after the gateway is stable, not while we’re still isolating the startup failure.

steady osprey
#

akkarthikeyan@As-MacBook-Air ~ % openclaw gateway probe --timeout 30000

🦞 OpenClaw 2026.4.26 (be8c246) — No $999 stand required.

│
◇
Gateway Status
Reachable: no
Capability: unknown
Probe budget: 30000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeout · Capability: unknown

akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Interesting: the gateway says ready, but the CLI still can’t complete the WS connect. Next we need to split HTTP works vs WS/proxy issue.

Run:

curl -v --max-time 10 http://127.0.0.1:18789/healthz
curl -v --max-time 10 http://127.0.0.1:18789/readyz
env | grep -i proxy

Then try bypassing any proxy env just in case:

NO_PROXY=127.0.0.1,localhost no_proxy=127.0.0.1,localhost openclaw gateway probe --timeout 30000

After that probe, check if the gateway saw it:

# 
grep -E "ws|connect|closed before connect|upgrade|error" ~/.openclaw/logs/gateway.log | tail -80

If /healthz and /readyz respond but WS probe times out, this is likely a local WS/proxy/auth-handshake issue — not startup anymore.

steady osprey
#

kkarthikeyan@As-MacBook-Air ~ % openclaw gateway probe --timeout 30000

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

│
◇
Gateway Status
Reachable: yes
Capability: connected-no-operator-scope
Probe budget: 30000ms

Warning:

  • Read-probe diagnostics are limited by gateway scopes (missing operator.read). Connection succeeded, but read-only status calls are incomplete. Hint: pair device identity or use credentials with operator.read.

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: ok (129ms) · Capability: connect-only · Read probe: limited - missing scope: operator.read

akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Nice — that’s a win 🎉

Reachable: yes
Connect: ok

The remaining warning is not a gateway failure. It just means the CLI connected without operator.read, so deeper diagnostics are limited.

To fix that part:

openclaw devices list

If you see a pending local/operator request, approve the exact ID:

# 
openclaw devices approve <requestId>

Then rerun:

openclaw gateway probe --timeout 30000
openclaw status --deep --timeout 30000

Also: Found 0 gateways via Bonjour is expected because Bonjour is disabled.

Once paired, re-enable things slowly. First channels/Telegram:

steady osprey
#

akkarthikeyan@As-MacBook-Air ~ % openclaw gateway restart && sleep 35 && openclaw gateway probe --timeout 30000

🦞 OpenClaw 2026.4.26 (be8c246)
Self-hosted, self-updating, self-aware (just kidding... unless?).

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

🦞 OpenClaw 2026.4.26 (be8c246)
I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

│
◇
Gateway Status
Reachable: no
Capability: unknown
Probe budget: 30000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeout · Capability: unknown

akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Yep — that means the thing we re-enabled brought the startup hang back.

Please check which temp skips are still in .env:

grep OPENCLAW ~/.openclaw/.env

Then restore the known-good minimal mode:

cat >> ~/.openclaw/.env <<'EOF'
OPENCLAW_SKIP_CHANNELS=1
OPENCLAW_SKIP_STARTUP_MODEL_PREWARM=1
EOF
# 
openclaw gateway restart
sleep 25
openclaw gateway probe --timeout 30000

If that returns Reachable: yes again, the blocker is almost certainly channel startup, likely Telegram.

Next step after that is not mass-disabling plugins — it’s inspect the channel logs:

grep -Ei "telegram|channel|sidecars|gateway ready|error|timeout|failed" ~/.openclaw/logs/gateway.log | tail -200

Paste that output and we can narrow it to the exact channel/sidecar.

steady osprey
#

akkarthikeyan@As-MacBook-Air ~ % openclaw gateway restart && sleep 35 && openclaw gateway probe --timeout 30000

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

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

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

│
◇
Gateway Status
Reachable: no
Capability: unknown
Probe budget: 30000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeout · Capability: unknown

akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

Don’t restart again yet — we need to confirm the service actually picked up the minimal env.

Run/paste these:

grep OPENCLAW ~/.openclaw/.env
grep -E "skipping channel|starting channels|gateway ready|startup trace: ready|error|failed|timeout" ~/.openclaw/logs/gateway.log | tail -200

If OPENCLAW_SKIP_CHANNELS=1 is not present, restore known-good minimal mode:

cat >> ~/.openclaw/.env <<'EOF'
OPENCLAW_SKIP_CHANNELS=1
OPENCLAW_SKIP_STARTUP_MODEL_PREWARM=1
EOF
# 

openclaw gateway restart
sleep 45
openclaw gateway probe --timeout 30000

If it is present but still hangs, the log lines will tell us which startup phase is blocking now.

steady osprey
#

Progress! Connect: ok (5150ms) — gateway IS reachable. The read probe just needs more time. But the user asked about reinstalling, so let me address that first.

You don't need a full wipe. The core issue is rate limiting from repeated restarts — that clears on its own. Right now the gateway is working (connection succeeds, admin-capable), it's just slow.

Here's the actual state:

Thing Status
Gateway running ✅
WebSocket auth ✅ working
Probe connect ✅ ok (5s)
Startup speed ❌ rate-limited (8+ min vs 20s)
Telegram ⚠️ skipped for now

The rate limiting is from the plugin registry + Google auth endpoints. It will recover on its own in 30–60 minutes without touching anything.

What I'd recommend instead of reinstalling:

  1. Leave the gateway running as-is (it IS working)
  2. Don't restart it again for at least 30 minutes
  3. Then run one clean probe — it'll connect fast again

If you want to verify it's serving requests right now:

openclaw gateway probe --timeout 60000

That gives the read probe enough time to complete even with the slowdown.

Want to wait it out, or do you actually want to do a clean wipe?

spice siloBOT
#

I’d wait it out — don’t wipe/reinstall yet.

The important part is:

Connect: ok
admin-capable

That means the gateway/auth path is working now. A wipe risks losing config/session state and will probably add more noise.

Do this instead:

# leave gateway running, no more restarts for ~30 min
openclaw gateway probe --timeout 60000
# 
openclaw status --deep --timeout 60000

If it stays reachable, then later re-enable Telegram carefully by removing only this line from ~/.openclaw/.env:

OPENCLAW_SKIP_CHANNELS=1

Then restart once and test again.

I’d treat the “rate limiting” explanation as plausible but not proven. The confirmed facts are: startup/connect is slow, but gateway is alive now. Keep it stable first.
Docs: https://docs.openclaw.ai/help/troubleshooting

steady osprey
#

akkarthikeyan@As-MacBook-Air ~ % openclaw gateway probe --timeout 60000

🦞 OpenClaw 2026.4.26 (be8c246)
Deployed locally, trusted globally, debugged eternally.

│
◇
Gateway Status
Reachable: no
Capability: unknown
Probe budget: 60000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: ok (9468ms) · Capability: admin-capable · Read probe: failed - gateway request timeout for status

akkarthikeyan@As-MacBook-Air ~ %

spice siloBOT
#

That’s actually partly good:

Connect: ok (9468ms)
Capability: admin-capable

So the Gateway is reachable and auth works. The confusing Reachable: no is because the follow-up status RPC timed out, not because the WebSocket failed.

Don’t reinstall/restart yet. Isolate the slow RPC:

curl -fsS http://127.0.0.1:18789/healthz; echo
curl -fsS http://127.0.0.1:18789/readyz; echo

openclaw gateway call health --timeout 60000 --json
# 
openclaw gateway call system-presence --timeout 60000 --json
openclaw gateway call status --timeout 120000 --json

Then grab relevant logs:

grep -Ei "gateway ready|status|health|request timeout|slow|error|failed|startup trace" ~/.openclaw/logs/gateway.log | tail -200

If health works but status hangs, we’ve narrowed it to the status diagnostics path. That’s degraded diagnostics, not a dead gateway.

Docs note this case here: https://docs.openclaw.ai/cli/gateway

steady osprey
#

Good news in the trend — the gateway is actively recovering on its own. Look at the status RPC trajectory:
Time Status RPC Trend
07:06 4 s baseline
07:30 32 s peak slowness
07:42 6 s recovering
So the rate-limit/retry aftermath is clearing. Your diagnosis was right — gateway is alive and operator-capable, only the diagnostics path was dragging.
Pulled out of the startup trace (the 8.7-min boot at 23:46) — these are the actual rate-limit hot spots so we know what to watch:
Phase Time Normal
config.auth 98 s 5 s
plugins.bootstrap 104 s 6 s
sidecars.restart-sentinel 167 s <1 s
sidecars.session-locks 34 s <1 s
That session-locks line had eventLoopMax=34057ms — a 34-second synchronous event-loop block acquiring file locks on the session files. That's worth flagging — it's the kind of thing that can cause status RPCs to hang when triggered.
Two leftover items I noticed in the status payload:

  1. agent:main:telegram:direct:121908106 is marked status: running but hasn't been updated in 10.6 hours (age: 38298955ms). On the next restart, subagent-recovery will probably try to resume it, which triggers more Gemini retries.
  2. /healthz and /readyz time out on plain HTTP — looks like only WebSocket+auth surfaces are exposed in 2026.4.26.
    What I would do next (no restart):
  • Wait another 30 min, watch status RPC drop under 1s
  • Then clean up the stale Telegram session (abortedLastRun: true or remove the running status before any future restart) so the recovery storm doesn't kick off again
    Want me to fix the stale Telegram session in sessions.json while the gateway is up so the next restart is clean?
    ¯
#

Good news in the trend — the gateway is actively recovering on its own. Look at the status RPC trajectory:
Time Status RPC Trend
07:06 4 s baseline
07:30 32 s peak slowness
07:42 6 s recovering
So the rate-limit/retry aftermath is clearing. Your diagnosis was right — gateway is alive and operator-capable, only the diagnostics path was dragging.
Pulled out of the startup trace (the 8.7-min boot at 23:46) — these are the actual rate-limit hot spots so we know what to watch:
Phase Time Normal
config.auth 98 s 5 s
plugins.bootstrap 104 s 6 s
sidecars.restart-sentinel 167 s <1 s
sidecars.session-locks 34 s <1 s
That session-locks line had eventLoopMax=34057ms — a 34-second synchronous event-loop block acquiring file locks on the session files. That's worth flagging — it's the kind of thing that can cause status RPCs to hang when triggered.
Two leftover items I noticed in the status payload:

  1. agent:main:telegram:direct:121908106 is marked status: running but hasn't been updated in 10.6 hours (age: 38298955ms). On the next restart, subagent-recovery will probably try to resume it, which triggers more Gemini retries.
  2. /healthz and /readyz time out on plain HTTP — looks like only WebSocket+auth surfaces are exposed in 2026.4.26.
    What I would do next (no restart):
  • Wait another 30 min, watch status RPC drop under 1s
  • Then clean up the stale Telegram session (abortedLastRun: true or remove the running status before any future restart) so the recovery storm doesn't kick off again
    Want me to fix the stale Telegram session in sessions.json while the gateway is up so the next restart is clean?
steady osprey
#

Gateway Status
Reachable: no
Capability: unknown
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - connect ECONNREFUSED 127.0.0.1:18789 · Capability: unknown

akkarthikeyan@As-MacBook-Air ~ %