#Gateway is taking 15 minutes to launch

1 messages · Page 1 of 1 (latest)

woven holly
#

08:45:38 [plugins] embedded acpx runtime backend ready
08:45:47 [health-monitor] [whatsapp:default] health-monitor: restarting (reason: stopped)
08:48:24 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:telegram:group:-1003673798985:topic:1 state=processing age=166s queueDepth=1
08:48:24 [telegram] Polling stall detected (active getUpdates stuck for 166.24s); forcing restart. [diag inFlight=1 outcome=started startedAt=1777272338588 finishedAt=1777272338487 durationMs=58615 offset=12854218]
08:48:24 [telegram] [diag] polling cycle finished reason=polling stall detected inFlight=0 outcome=error startedAt=1777272338588 finishedAt=1777272504829 durationMs=166241 offset=12854218 error=Network request for 'getUpdates' failed!
08:48:24 [telegram] polling runner stopped (polling stall detected); restarting in 2.46s.

earnest egretBOT
#

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

crude flameBOT
#

That log doesn’t look like “gateway is still launching” — it looks like the gateway got far enough to start plugins, then Telegram long-polling wedged and OpenClaw’s watchdog restarted the Telegram poller.

Key line:

Network request for 'getUpdates' failed!

That usually points at host/network egress to api.telegram.org: DNS, IPv6, proxy, TLS, or flaky VPS networking.

Can you paste:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe
woven holly
#

Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /opt/homebrew/opt/node/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18982
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18982

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

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

Runtime: unknown (Bad request.
Could not find service "ai.openclaw.gateway" in domain for user gui: 501)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18982
connect ECONNREFUSED 127.0.0.1:18982
Capability: unknown

Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.24 (cbcfdf6) — The lobster in your shell. 🦞

│
◇
Gateway not reachable: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18982
Source: local loopback
Config: /Users/jchopard/.openclaw/openclaw.json
Bind: loopback

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.
    Gateway not reachable; showing config-only status.
    Config: /Users/jchopard/.openclaw/openclaw.json
    Mode: local

  • Telegram default: enabled, configured, token:config

  • WhatsApp default: enabled, not configured

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

OpenClaw
General troubleshooting - OpenClaw
crude flameBOT
#

This confirms the main problem: the gateway isn’t running at all.

ECONNREFUSED 127.0.0.1:18982 + LaunchAgent (not loaded) + Service unit not found means launchd doesn’t currently have the OpenClaw service loaded.

Try this:

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status
openclaw status --deep

One extra macOS gotcha: if you previously used attach-only/dev mode, check for this marker:

# 
ls ~/.openclaw/disable-launchagent

If it exists and you do want OpenClaw managed by LaunchAgent, remove it, then rerun the install/restart:

rm ~/.openclaw/disable-launchagent
openclaw gateway install --force
openclaw gateway restart

After the gateway is actually reachable, then we can look at the Telegram getUpdates stall separately. That part points more toward network/DNS/proxy/IPv6 to api.telegram.org, but it’s secondary until launchd is fixed.

woven holly
#

Bundled plugin runtime deps are missing.

crude flameBOT
#

Yep — that’s the blocker.

For packaged installs, active bundled plugins repair their runtime deps via doctor. Run:

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

Since your status showed WhatsApp enabled but not configured, disable it if you’re not using it:

openclaw config set channels.whatsapp.enabled false --strict-json
openclaw doctor --fix
# 
openclaw gateway restart

If doctor --fix says it installed deps but the next run still says they’re missing, paste the full bundled plugin runtime deps section from doctor. Especially any npm ERR!, ENOTEMPTY, or path like ~/node_modules / openclaw-unknown-*.

This area has been a little spicy around 2026.4.24, so if it loops after doctor --fix, the exact doctor output will tell us whether it’s normal repair or the runtime-deps install regression.

Docs:
https://docs.openclaw.ai/gateway/doctor
https://docs.openclaw.ai/install/updating

woven holly
#

OAuth refresh errors ───────────────────────────────────────────────────╮
│ │
│ - google-antigravity:default: OAuth refresh failed — Try again; if │
│ this persists, run openclaw models auth login --provider │ │ google-antigravity. │
│ - google-gemini-cli:default: OAuth refresh failed — Try again; if this │
│ persists, run openclaw models auth login --provider │ │ google-gemini-cli.

crude flameBOT
#

That’s a separate auth problem from the LaunchAgent/plugin-deps issue.

Those two OAuth profiles have stale/expired refresh tokens. If you still want to use those Google-backed providers, re-login from the same Mac user that runs the gateway:

openclaw models auth login --provider google-antigravity
openclaw models auth login --provider google-gemini-cli

Only add --set-default if you intentionally want that provider to become your default model route:

openclaw models auth login --provider google-gemini-cli --set-default

Then:

# 
openclaw models status
openclaw doctor
openclaw gateway restart

If you don’t use one of those providers, the better fix is to remove it from your default/fallback/allowlist config rather than keep refreshing it. Check what’s selected with:

openclaw models status
openclaw config get agents.defaults.model
openclaw config get agents.defaults.models

Docs:
https://docs.openclaw.ai/concepts/oauth
https://docs.openclaw.ai/concepts/models

woven holly
#

everything is going so slow, doctor is taking like 10 minutes to run, is this normal?

crude flameBOT
#

No — 10 minutes is not normal for a plain doctor run.

It can be slow the first time if it’s repairing bundled plugin runtime deps because that may run npm installs, but 10 minutes usually means it’s stuck on one of:

  • npm/network fetching plugin deps
  • OAuth refresh/login prompt waiting
  • LaunchAgent/service repair hanging
  • the 2026.4.24 plugin-runtime-deps weirdness

Don’t run multiple doctors in parallel. In a second terminal, check what it’s doing:

ps aux | grep -E 'openclaw|npm|node' | grep -v grep
tail -n 120 /tmp/openclaw/openclaw-2026-04-27.log

If doctor is just sitting with no CPU/network activity, Ctrl-C is okay, then try the non-interactive path:

# 
openclaw doctor --fix --non-interactive

If it hangs specifically at Bundled plugin runtime deps, paste that section + any npm ERR! lines. If you see paths like ~/node_modules, ENOTEMPTY, or openclaw-unknown-*, that’s suspicious and likely not something you caused.

Docs: https://docs.openclaw.ai/cli/doctor

woven holly
crude flameBOT
#

Thanks, this log is much clearer.

Two separate things are happening:

  1. Startup is slow because bundled plugin deps are being staged

    • acpx/google/openai/telegram/whatsapp each install in ~5–8s.
    • That’s ~40s, annoying but not 10 min.
    • If this happens on every restart, that’s not normal — deps aren’t being persisted/found.

  2. Telegram is the thing that’s actually broken

    • Network request for 'getUpdates' failed!
    • Polling stall detected
    • That means the gateway is running, but Telegram long polling to api.telegram.org is hanging/failing.

First, disable WhatsApp if you’re not using it:

# 
openclaw config set channels.whatsapp.enabled false --strict-json
openclaw gateway restart

Then test Telegram network from the same Mac:

curl -4 -I --connect-timeout 10 https://api.telegram.org
curl -6 -I --connect-timeout 10 https://api.telegram.org

If IPv6 hangs/fails but IPv4 works, try:

openclaw config set channels.telegram.network.autoSelectFamily false --strict-json
woven holly
#

HTTP/2 302
server: nginx/1.18.0
date: Mon, 27 Apr 2026 07:47:12 GMT
content-type: text/html
content-length: 145
location: https://core.telegram.org/bots
strict-transport-security: max-age=31536000; includeSubDomains; preload
access-control-allow-origin: *
access-control-allow-methods: GET, POST, OPTIONS
access-control-expose-headers: Content-Length,Content-Type,Date,Server,Connection

HTTP/2 302
server: nginx/1.18.0
date: Mon, 27 Apr 2026 07:47:12 GMT
content-type: text/html
content-length: 145
location: https://core.telegram.org/bots
strict-transport-security: max-age=31536000; includeSubDomains; preload
access-control-allow-origin: *
access-control-allow-methods: GET, POST, OPTIONS
access-control-expose-headers: Content-Length,Content-Type,Date,Server,Connection

Bots: An introduction for developers

Bots are small applications that run entirely within the Telegram app. Users interact with bots through flexible interfaces…

crude flameBOT
#

Good — both curls returning HTTP/2 302 quickly means basic IPv4 + IPv6 access to api.telegram.org is fine. So don’t chase IPv6 yet.

Now I’d isolate whether Telegram is what’s freezing the gateway:

openclaw config set channels.telegram.enabled false --strict-json
openclaw gateway restart
openclaw gateway status
openclaw status --deep

If startup becomes fast/reliable with Telegram disabled, we’ve confirmed it’s the Telegram channel path.

Then re-enable and run the built-in probe:

# 
openclaw config set channels.telegram.enabled true --strict-json
openclaw gateway restart
openclaw channels status --probe

Also, the scary line in your log is actually this:

node.list 156869ms

node.list should be basically instant. If it takes 156s, the gateway/event loop is getting wedged, not just “Telegram is slow”.

Next useful paste: the output of:

# 
openclaw channels status --probe
openclaw status --all

And if you’re using a VPN/proxy/firewall app on macOS, say which one — curl from your shell working doesn’t always mean the LaunchAgent process has the same network/proxy behavior.

woven holly
#

Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18982
Source: local loopback
Config: /Users/jchopard/.openclaw/openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: /Users/jchopard/.openclaw/openclaw.json
Mode: local

  • Telegram default: enabled, configured, token:config

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

crude flameBOT
#

That means the process is either not accepting WS at all or it’s accepting but the gateway event loop is wedged for >30s.

Important: your status still says:

Telegram default: enabled

So first isolate it offline:

openclaw config set channels.telegram.enabled false --strict-json
openclaw config set channels.whatsapp.enabled false --strict-json
openclaw gateway restart
openclaw gateway status
openclaw status --all
#

If the gateway becomes reachable with Telegram disabled, the Telegram provider is wedging startup/runtime and we can debug that separately.

If it’s still timing out with Telegram disabled, grab:

ps aux | grep -E 'openclaw|node|npm' | grep -v grep
tail -n 200 /tmp/openclaw/openclaw-2026-04-27.log
openclaw gateway status

Also: since you’re on 2026.4.24 and your logs showed runtime deps being staged repeatedly, this may be the plugin runtime deps issue rather than your config. If disabling Telegram/WhatsApp doesn’t make the gateway responsive, I’d file the full repro/logs here: https://github.com/openclaw/openclaw/issues

woven holly
crude flameBOT
#

This report is useful — this is not Telegram anymore.

The gateway process is running, but it never finishes startup:

[gateway] ready (1 plugin: acpx; 53.5s)
[gateway] starting channels and sidecars...
chat.history unavailable during gateway startup
models.list unavailable during gateway startup
Gateway health: timeout

So it’s stuck in the sidecars phase. Also: you’re on Node 25.2.1. OpenClaw’s recommended/default runtime is Node 24, and Node 25 has been suspicious in a few places. I’d fix that first.

Try:

# 
brew install node@24
brew unlink node
brew link --force --overwrite node@24
node -v

Make sure it prints v24.x.x, then reinstall/rewrite the service:

pnpm add -g openclaw@latest
pnpm approve-builds -g
openclaw gateway install --force
openclaw gateway restart
openclaw status --all
#

If it still hangs at “starting channels and sidecars”, isolate sidecars:

launchctl setenv OPENCLAW_SKIP_CHANNELS 1
openclaw gateway restart
openclaw status --all

If that makes it reachable, it’s channel/model-prewarm related. If it still hangs, temporarily disable ACP/acpx:

openclaw config set acp.enabled false --strict-json
openclaw gateway restart
openclaw status --all

That acpx plugin is the only plugin showing, so it’s the next suspect after Node 25.

woven holly
crude flameBOT
#

Nice, Node 24 is confirmed — and the problem still persists, so Node 25 wasn’t the root cause.

This is now narrowed down pretty hard:

  • Channels table is empty → Telegram/WhatsApp aren’t the current blocker.
  • Gateway reaches ready (1 plugin: acpx; 60.6s).
  • Then hangs at starting channels and sidecars....
  • Only loaded plugin is acpx.
  • acpx runtime deps are still being staged every restart.

Next isolation step: disable ACP/acpx temporarily.

openclaw config set acp.enabled false --strict-json
openclaw gateway restart
openclaw status --all
#

If it’s still stuck, also disable the plugin itself:

openclaw plugins disable acpx
openclaw gateway restart
openclaw status --all

If that makes the gateway reachable, this is very likely an ACP/acpx startup/runtime-deps regression in 2026.4.24, not your Telegram config.

At that point I’d file this with the exact status/log chunk you pasted:
https://github.com/openclaw/openclaw/issues

Key repro details to include:

  • macOS 26.3.1 arm64
  • OpenClaw 2026.4.24
  • Node 24.15.0
#
  • pnpm global install
  • Gateway hangs after ready (1 plugin: acpx) / starting channels and sidecars...
  • acpx staging bundled runtime deps ... acpx@0.5.3 repeats on restart
  • Gateway health times out while LaunchAgent process is running.
woven holly
crude flameBOT
#

Okay, this rules out Node 25 and mostly rules out acpx:

ready (0 plugins, 46.4s)
starting channels and sidecars...
Gateway health: timeout

So the hang is now in core sidecar startup, after the HTTP server starts. Next step is to get phase timings.

Run this:

launchctl setenv OPENCLAW_GATEWAY_STARTUP_TRACE 1
launchctl setenv OPENCLAW_SKIP_CHANNELS 1
openclaw gateway restart
# 
sleep 90
openclaw status --all
tail -n 200 ~/.openclaw/logs/gateway.log

If that makes the gateway reachable, the blocker is in the channel/model-prewarm path — likely around the configured primary model:

agent model: openai-codex/gpt-5.4

If it’s still unreachable, paste the startup trace: lines from gateway.log; they should show exactly which sidecar phase is hanging.

You can undo the env after testing with:

# 
launchctl unsetenv OPENCLAW_SKIP_CHANNELS
launchctl unsetenv OPENCLAW_GATEWAY_STARTUP_TRACE

At this point this looks like a real 2026.4.24 startup bug, not a Telegram setup mistake.

woven holly
#

Timed out after 60s waiting for gateway port 18982 to become healthy.
Gateway process is running but port 18982 is still free (startup hang/crash loop or very slow VM startup).
Service runtime: status=running, state=active, pid=38434
Gateway port 18982 status: free.
Gateway restart timed out after 60s waiting for health checks.

crude flameBOT
#

That changes the picture: port 18982 is free, so the gateway is now hanging before it even starts the HTTP/WebSocket server. That’s earlier than the sidecars phase.

Please grab the fresh startup logs around PID 38434:

ps -p 38434 -o pid,etime,%cpu,%mem,command
tail -n 250 ~/.openclaw/logs/gateway.log
tail -n 250 ~/.openclaw/logs/gateway.err.log

Since this is a true startup hang, a macOS process sample would be super useful too:

sample 38434 10 -file /tmp/openclaw-gateway-sample.txt

Then attach/paste /tmp/openclaw-gateway-sample.txt.

#

If you haven’t already, keep these envs for the next restart so the logs show the exact phase:

launchctl setenv OPENCLAW_GATEWAY_STARTUP_TRACE 1
launchctl setenv OPENCLAW_SKIP_CHANNELS 1
launchctl setenv OPENCLAW_NO_AUTO_UPDATE 1
openclaw gateway restart

This is now very much looking like a 2026.4.24 startup hang/regression. The process sample + trace logs should make the GitHub issue actionable.

woven holly
crude flameBOT
#

This trace is excellent — it shows the gateway isn’t crashing. It’s just taking longer than the 60s restart health timeout.

Key timings:

config.auth        34.9s
plugins.bootstrap 36.4s
http.bound         at 71.9s
sidecars.total     20ms
sidecars.ready     yes

So with OPENCLAW_SKIP_CHANNELS=1, sidecars are fine. The real slow parts are:

  1. Auth resolution — likely stale/slow model auth/OAuth profiles.
  2. Plugin bootstrap — Telegram runtime deps are still being staged every start.
#

Next:

openclaw status --all

If it’s reachable now after waiting ~90s, that confirms the timeout is just too short for the current boot.

Then reduce the slow boot:

openclaw models status

Re-auth or remove any stale providers it reports, especially the earlier:

# 
openclaw models auth login --provider google-antigravity
openclaw models auth login --provider google-gemini-cli

And if you’re not actively using Telegram right now, disable it more completely:

openclaw config set channels.telegram.enabled false --strict-json
openclaw plugins disable telegram
openclaw gateway restart

If Telegram deps still stage every restart after that, this is very likely the 2026.4.24 bundled runtime-deps regression. Include these trace lines in a GitHub issue — they’re the smoking gun.

woven holly
crude flameBOT
#

Good news: gateway is reachable now ✅

Gateway reachable · 54ms
sidecars.ready
Channel issues (none)

So the hard hang is mostly resolved. The remaining problem is startup is still way too slow:

config.auth        34.9s
plugins.bootstrap 36.4s
total boot         ~72s

That explains why openclaw gateway restart times out at 60s even though the gateway eventually comes up.

#

Next cleanup:

openclaw models status

If it shows stale OAuth/auth issues, fix those first — earlier you had google-antigravity / google-gemini-cli refresh failures.

Also, if you’re done testing, unset the debug env:

launchctl unsetenv OPENCLAW_GATEWAY_STARTUP_TRACE
launchctl unsetenv OPENCLAW_SKIP_CHANNELS
launchctl unsetenv OPENCLAW_NO_AUTO_UPDATE
openclaw gateway restart
#

One more smoking gun: Telegram deps are still being staged during boot:

telegram staging bundled runtime deps ...

If that repeats every restart, that’s likely a 2026.4.24 plugin-runtime-deps bug. I’d file an issue with those trace lines:
https://github.com/openclaw/openclaw/issues

For now, if you don’t need Telegram active while debugging:

openclaw config set channels.telegram.enabled false --strict-json
openclaw plugins disable telegram
openclaw gateway restart
woven holly
#

It's been 10 minutes that I'm trying to launch the gateway : 12:09:41 [gateway] loading configuration…
12:09:41 [gateway] resolving authentication…
12:09:41 [gateway] starting...
12:10:19 [gateway] starting HTTP server...
12:10:19 [canvas] host mounted at http://127.0.0.1:18982/__openclaw__/canvas/ (root /Users/jchopard/.openclaw/canvas)
12:10:20 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
12:10:20 [gateway] agent model: openai-codex/gpt-5.4
12:10:20 [gateway] ready (0 plugins, 38.7s)
12:10:20 [gateway] log file: /tmp/openclaw/openclaw-2026-04-27.log
12:10:20 [gateway] security warning: dangerous config flags enabled: plugins.entries.acpx.config.permissionMode=approve-all. Run openclaw security audit.
12:10:20 [gateway] starting channels and sidecars...
12:14:05 [heartbeat] started
12:14:05 [gateway] acp startup identity reconcile (renderer=v1): checked=2 resolved=0 failed=2

crude flameBOT
#

I know this is maddening, but this log finally points at the likely blocker:

agent model: openai-codex/gpt-5.4
ready (0 plugins, 38.7s)
starting channels and sidecars...
... 4 minutes ...
heartbeat started

So the gateway does start, but sidecar startup is likely waiting on the configured primary model/auth prewarm — probably openai-codex.

Run:

openclaw models status
#

If openai-codex auth looks stale/broken, re-login:

openclaw models auth login --provider openai-codex
openclaw gateway restart

Fast workaround while debugging:

launchctl setenv OPENCLAW_SKIP_CHANNELS 1
openclaw gateway restart

That already made startup finish cleanly earlier, so it confirms the core gateway is okay. The real issue is startup work after starting channels and sidecars..., not the HTTP server itself.

Also clean the stale acpx warning:

# 
openclaw config unset plugins.entries.acpx.config.permissionMode
openclaw gateway restart
woven holly
#

Restarted LaunchAgent: gui/501/ai.openclaw.gateway
Timed out after 60s waiting for gateway port 18982 to become healthy.
Gateway process is running but port 18982 is still free (startup hang/crash loop or very slow VM startup).
Service runtime: status=running, state=active, pid=54774
Gateway port 18982 status: free.
Gateway restart timed out after 60s waiting for health checks.
Tip: openclaw gateway status --deep
Tip: openclaw doctor

crude flameBOT
#

That 60s timeout is expected with the trace we saw: your gateway didn’t bind HTTP until ~72s because startup work before http.bound is slow.

Don’t keep restarting yet — wait another 30–60s, then run:

openclaw status --all

If it becomes reachable, the immediate “fix” is: gateway starts, but restart waits only 60s and your startup currently takes longer.

To identify what’s still slow on this fresh PID:

tail -n 120 ~/.openclaw/logs/gateway.log | grep 'startup trace'

Earlier it was:

# 
config.auth ~35s
plugins.bootstrap ~36s

So next real fixes are:

  1. openclaw models status → clean/re-login stale auth profiles.
  2. Stop Telegram/plugin deps staging every boot, or file it as the 2026.4.24 runtime-deps bug.

For now, please wait and check status once before restarting again. Restart loops are making this harder to pin down.

woven holly
#

i ran openclaw gateway status : Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /opt/homebrew/opt/node@24/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18982
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18982

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

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

Runtime: running (pid 54774, state active)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18982
timeout
Capability: unknown

Port 18982 is already in use.

  • pid 54774 jchopard: openclaw-gateway (127.0.0.1:18982)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    Listening: 127.0.0.1:18982
    Troubles: run openclaw status
crude flameBOT
#

Now it has bound the port, so it got past the earlier phase. But the WS probe is timing out, which usually means it’s still finishing startup / event loop is busy.

Please don’t restart yet. Run only this:

tail -n 160 ~/.openclaw/logs/gateway.log | grep 'startup trace'

If you see ready / sidecars.ready, then wait 30s and run:

openclaw status --all

If you don’t see sidecars.ready, paste the last startup trace line — that tells us exactly where it’s stuck.

Also, because gateway status says:

# 
Listening: 127.0.0.1:18982
Connectivity probe: timeout

it’s no longer a LaunchAgent install problem. It’s the gateway process being slow/busy after bind. The trace is the important bit now.

woven holly
crude flameBOT
#

This trace says the current boot did finish:

12:24:06 sidecars.ready
12:24:06 ready
total=65211ms

So the gateway is coming up in ~65s, but openclaw gateway restart times out at 60s. That’s why it looks broken.

The slow parts are now very clear:

config.auth        47s
plugins.bootstrap 17s
#

Sidecars are fine.

Do this next:

openclaw status --all
openclaw models status
openclaw config get gateway.auth
launchctl getenv OPENCLAW_GATEWAY_TOKEN
launchctl getenv OPENCLAW_GATEWAY_PASSWORD

For the repeated plugin bootstrap/runtime-deps staging, try:

openclaw doctor --fix --non-interactive
woven holly
crude flameBOT
#

Good — gateway is reachable now. The remaining slow boot is explained by two things:

  1. Expired Google OAuth profiles
google-antigravity:default expired
google-gemini-cli:default expired

Fix or remove them. If you use them:

openclaw models auth login --provider google-antigravity
openclaw models auth login --provider google-gemini-cli
  1. Telegram runtime deps keep staging
# 
telegram staging bundled runtime deps...

Run:

openclaw doctor --fix --non-interactive

If that still happens every restart, it’s likely a 2026.4.24 runtime-deps bug worth filing.

Also: your gateway is currently reachable, but channels table is empty — likely because debug isolation is still active or Telegram is disabled. When ready, undo debug env:

launchctl unsetenv OPENCLAW_SKIP_CHANNELS
# 
launchctl unsetenv OPENCLAW_GATEWAY_STARTUP_TRACE
launchctl unsetenv OPENCLAW_NO_AUTO_UPDATE
openclaw gateway restart

For the acpx warning, if you don’t use ACP/acpx:

openclaw config unset plugins.entries.acpx

Then restart. Docs: https://docs.openclaw.ai/cli/doctor

woven holly
#

everything is so slow, i don't know what's going on, the doctor has been running since 10 minutes and still not done

crude flameBOT
#

Yeah, at this point I’d stop doctor — 10 minutes is not normal.

Press Ctrl-C. Then run the smallest checks instead:

ps aux | grep -E 'openclaw|npm|node' | grep -v grep
openclaw models status

The main smoking gun from your last output was:

google-antigravity:default expired
google-gemini-cli:default expired

So fix those directly instead of waiting on doctor:

# 
openclaw models auth login --provider google-antigravity
openclaw models auth login --provider google-gemini-cli

If you don’t use those providers, don’t re-login — remove/disable them later, but for now re-login is the quickest way to stop auth refresh from hanging.

After that:

openclaw gateway restart
# wait ~90s, don't restart-loop
openclaw status --all

Also keep OPENCLAW_SKIP_CHANNELS=1 set for now while debugging. Telegram/plugin deps are a second issue; fix the expired OAuth/auth slowness first.

woven holly
crude flameBOT
#

Yeah — stop running doctor now. It actually completed, but the output confirms a bug/loop:

  • Doctor says bundled deps are missing
  • Doctor installs them
  • Then immediately says the same deps are missing again
  • Telegram staging later fails validation

That’s not normal.

Do only these next:

openclaw models auth login --provider google-antigravity
openclaw models auth login --provider google-gemini-cli

Then, for now, keep Telegram disabled while the runtime-deps bug is unresolved:

# 
openclaw config set channels.telegram.enabled false --strict-json
openclaw plugins disable telegram
openclaw gateway restart

Also this is important:

LaunchAgent writes are disabled via ~/.openclaw/disable-launchagent

If you want normal LaunchAgent behavior back:

rm ~/.openclaw/disable-launchagent
# 
openclaw gateway install --force

But don’t keep looping doctor. Please file this as a GitHub issue with this doctor output:
https://github.com/openclaw/openclaw/issues

Title suggestion: 2026.4.24 bundled plugin runtime deps reinstall repeatedly / doctor reports missing after install.

woven holly
#

12:53:05 [gateway] loading configuration…
12:53:05 [gateway] resolving authentication…
12:53:05 [gateway] starting...
12:53:44 [gateway] starting HTTP server...
12:53:44 [canvas] host mounted at http://127.0.0.1:18982/__openclaw__/canvas/ (root /Users/jchopard/.openclaw/canvas)
12:53:44 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
12:55:50 [gmail-watcher] gmail watcher stopped
12:55:50 Gateway failed to start: another gateway instance is already listening on ws://127.0.0.1:18982 | listen EADDRINUSE: address already in use 127.0.0.1:18982
If the gateway is supervised, stop it with: openclaw gateway stop
12:55:50 Port 18982 is already in use.
12:55:50 - pid 77769 jchopard: openclaw-gateway (127.0.0.1:18982)
12:55:50 - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
12:55:50 Gateway service appears loaded. Stop it first.
12:55:50 Tip: openclaw gateway stop
12:55:50 Or: launchctl bootout gui/$UID/ai.openclaw.gateway

#

but my claw is not answering

crude flameBOT
#

You now have two gateway starts colliding on the same port. One supervised LaunchAgent is already running on 18982, and another manual/start attempt tried to bind the same port.

Stop the duplicate cleanly:

openclaw gateway stop

Then check:

openclaw gateway status

If it still shows something listening on 18982, use the PID from the output:

# 
kill 77769

Then restore normal LaunchAgent management — earlier doctor said this marker exists:

rm ~/.openclaw/disable-launchagent
openclaw gateway install --force
openclaw gateway restart

Important: after that, don’t run openclaw gateway --port 18982 manually while the LaunchAgent is loaded. Use only:

openclaw gateway restart
# 
openclaw gateway status

You’re very close — this latest error is just duplicate gateway processes, not a new Telegram issue.

#

That’s expected right now: your last status --all showed no enabled channels. So the gateway can be reachable, but Claw won’t answer Telegram/WhatsApp/etc.

You likely still have one or more debug disables active. Re-enable Telegram like this:

launchctl unsetenv OPENCLAW_SKIP_CHANNELS
launchctl unsetenv OPENCLAW_GATEWAY_STARTUP_TRACE
launchctl unsetenv OPENCLAW_NO_AUTO_UPDATE

openclaw plugins enable telegram
openclaw config set channels.telegram.enabled true --strict-json
openclaw gateway restart

Then wait ~90 seconds and check:

# 
openclaw status --all
openclaw channels status --probe

You want to see Telegram listed as enabled/running, ideally works.

Also don’t run openclaw gateway --port 18982 manually while LaunchAgent is active — that caused the duplicate gateway conflict. Use only:

openclaw gateway restart
openclaw gateway status
woven holly
#

jchopard@Mac ~ % openclaw update
│
◇ Config warnings ──────────────────────────────────────────────────╮
│ │
│ - plugins.entries.acpx: plugin disabled (disabled in config) but │
│ config is present │
│ │
├────────────────────────────────────────────────────────────────────╯
Updating OpenClaw...

│
◇ ✓ Updating via package manager (16.3s)
│
◇ ✓ Running doctor checks (621.9s)

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

Total time: 638.97s
│
◇ Config warnings ──────────────────────────────────────────────────╮
│ │
│ - plugins.entries.acpx: plugin disabled (disabled in config) but │
│ config is present │
│ │
├────────────────────────────────────────────────────────────────────╯

Updating plugins...
npm plugins: 0 updated, 0 unchanged, 1 skipped.
Completion cache update failed: Error: spawnSync /opt/homebrew/Cellar/node@24/24.15.0/bin/node ETIMEDOUT

Restarting service...
Gateway did not become healthy after restart.
Service runtime: status=running, state=active, pid=3821
Gateway port 18982 status: free.
Restart log: /Users/jchopard/.openclaw/logs/gateway-restart.log
Run openclaw gateway status --deep for details.

crude flameBOT
#

Oof. openclaw update didn’t actually change versions:

Before: 2026.4.24
After: 2026.4.24

It mostly spent 10+ minutes running doctor, then restarted into the same slow startup problem.

Don’t run update/doctor again for now. Check the restart log:

tail -n 200 ~/.openclaw/logs/gateway-restart.log
tail -n 200 ~/.openclaw/logs/gateway.log | grep -E 'startup trace|starting|ready|failed|error'

Also wait ~90s, then:

# 
openclaw status --all

Your known blockers are still:

google-antigravity expired
google-gemini-cli expired
bundled plugin deps reinstalling / failing

Fix auth directly, not via doctor:

openclaw models auth login --provider google-antigravity
# 
openclaw models auth login --provider google-gemini-cli

And remove the stale acpx warning:

openclaw config unset plugins.entries.acpx

If the gateway becomes reachable but Claw still doesn’t answer, re-enable Telegram after clearing debug env:

launchctl unsetenv OPENCLAW_SKIP_CHANNELS
openclaw plugins enable telegram
openclaw config set channels.telegram.enabled true --strict-json
# 
openclaw gateway restart

But first: paste gateway-restart.log. That’s the next useful signal.

woven holly
crude flameBOT
#

The restart log confirms it: the service does eventually start, but startup is wildly variable and often longer than the health timeout:

ready in 108s
ready in 97.9s
ready in 122.4s
ready in 68.3s

That’s why update/restart says “failed” even though the gateway later comes up.

Two concrete causes remain:

config.auth 68s
plugins.bootstrap 37s
#

And your doctor output showed:

  • expired google-antigravity
  • expired google-gemini-cli
  • plugin deps repeatedly missing/reinstalling

I’d stop chasing restart status and do this focused cleanup:

openclaw models auth login --provider google-antigravity
openclaw models auth login --provider google-gemini-cli
openclaw config unset plugins.entries.acpx

Then:

# 
openclaw gateway restart
# wait 2 minutes, do not restart again
openclaw status --all

If Claw still doesn’t answer, check only channel status:

openclaw channels status --probe

If Telegram says works but replies fail, we’ll look at the Telegram session/model path next.

woven holly
#

i wanna deactivate google antigravity and femini cli as i'm not using it

crude flameBOT
#

Yep — those are just stale auth profiles. Remove only those two; leave normal google / GEMINI_API_KEY alone.

Try:

openclaw capability model auth logout --provider google-antigravity
openclaw capability model auth logout --provider google-gemini-cli
openclaw models status

Then restart:

openclaw gateway restart
# wait ~90s
openclaw status --all
#

If capability model auth logout isn’t available in your build, use a backup + manual removal:

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.json.bak

python3 - <<'PY'
import json, pathlib
p = pathlib.Path.home()/".openclaw/agents/main/agent/auth-profiles.json"
d = json.loads(p.read_text())
for k in list(d.get("profiles", {})):
    if k.startswith(("google-antigravity:", "google-gemini-cli:")):
        del d["profiles"][k]
for section in ("usageStats", "order", "lastGood"):
    if section in d:
        for k in list(d[section]):
            if k.startswith(("google-antigravity", "google-gemini-cli")):
# 
                del d[section][k]
p.write_text(json.dumps(d, indent=2) + "\n")
PY

Then:

openclaw models status
openclaw gateway restart
#

Let me rebuild context first, then I’ll diagnose the gateway startup from your log.

#

I just started a fresh session, and I don’t see a resume file/highlights from an earlier run, so I may be missing prior context. If there’s one important thing I should know from before, tell me.

From the log you attached, this does not look like a simple “gateway takes 15 minutes to launch” problem.

What the log says

  • The gateway itself is reaching ready in about 40–122 seconds on each attempt.
  • One slow boot spent ~68.7s in config.auth and ~37.3s in plugins.bootstrap before the HTTP server bound.
  • After that, Telegram keeps stalling/restarting:
    • Polling stall detected
    • Network request for 'getUpdates' failed!
    • health-monitor: restarting (reason: stopped)

So the bigger issue is: Telegram long polling is unhealthy, and the health monitor keeps bouncing it. That makes the whole thing feel like endless startup.

Also, that ready (0 plugins) line is a bit misleading here — channel bring-up continues after that (starting channels and sidecars...), so I wouldn’t treat that line as the root problem by itself.

Most likely cause

#

Per the Telegram docs, persistent getUpdates stalls/failures usually mean network/DNS/IPv6/TLS egress trouble to api.telegram.org, especially on VPSes.

Best first fix to try
If this is on a VPS / Linux box / WSL-ish environment, I’d try forcing IPv4-ish behavior first:

{
  channels: {
    telegram: {
      network: {
        autoSelectFamily: false,
      },
    },
  },
}
#

Lemme verify the exact provider names/commands so I don’t hand you made-up config.

#

Fresh session here: I checked the bootstrap stuff and don’t see a resume file or today’s highlights, so I may be missing earlier context. If there’s one important thing from before, tell me.

Yep — you can remove both. Since you’re on OpenClaw 2026.4.23 from the earlier output, I’d do it like this:

# optional: see what auth is currently saved
openclaw infer model auth status

# remove saved auth for Antigravity
openclaw infer model auth logout --provider google-antigravity

# remove saved auth for Gemini CLI
openclaw infer model auth logout --provider google-gemini-cli

A couple gotchas:

#

  1. If your default model still points at one of those, switch it first

    openclaw config get agents.defaults.model.primary
openclaw models set <some-other-provider/model>

  2. If you were using Gemini CLI as the runtime, clear that too

    openclaw config get agents.defaults.agentRuntime.id
openclaw config unset agents.defaults.agentRuntime.id

  3. If they still show up in /model, they’re probably in your allowlist
    Check:

    openclaw config get agents.defaults.models --json
#

If you want, paste that and I’ll tell you exactly what to remove.

Tiny nuance: Google Antigravity and Gemini CLI are separate things:

  • google-antigravity = Antigravity OAuth bridge
  • google-gemini-cli = local Gemini CLI runtime/auth

Docs:

If you paste these two outputs, I can tell you the exact cleanup commands next:

openclaw config get agents.defaults.model.primary
openclaw config get agents.defaults.agentRuntime.id
woven holly
#

🦞 OpenClaw 2026.4.24 (cbcfdf6)
Runs on a Raspberry Pi. Dreams of a rack in Iceland.

│
◇ Config warnings ──────────────────────────────────────────────────╮
│ │
│ - plugins.entries.acpx: plugin disabled (disabled in config) but │
│ config is present │
│ │
├────────────────────────────────────────────────────────────────────╯
Warning: launchctl stop did not fully stop the service; used bootout fallback and left service unloaded
Stopped LaunchAgent (degraded): gui/501/ai.openclaw.gateway

crude flameBOT
#

That means the gateway service is now stopped and unloaded. So Claw definitely won’t answer until you load/start it again.

Before starting, clean the leftover acpx config warning:

openclaw config unset plugins.entries.acpx

Then reinstall/load the LaunchAgent cleanly:

rm ~/.openclaw/disable-launchagent 2>/dev/null
openclaw gateway install --force
openclaw gateway restart

Wait ~2 minutes, then:

# 
openclaw status --all
openclaw channels status --probe

If gateway restart still times out at 60s, don’t restart again — wait another minute and run openclaw status --all. Your gateway has been taking 60–120s to become healthy.

woven holly
#

Timed out after 60s waiting for gateway port 18982 to become healthy.
Gateway process is running but port 18982 is still free (startup hang/crash loop or very slow VM startup).
Service runtime: status=running, state=active, pid=26890
Gateway port 18982 status: free.
Gateway restart timed out after 60s waiting for health checks.
Tip: openclaw gateway status --deep
Tip: openclaw doctor

crude flameBOT
#

Same pattern: it’s still in the pre-bind startup phase and your health timeout is only 60s.

Please don’t restart again. Wait 60–90 seconds, then run:

openclaw status --all

If you want to see whether it’s progressing while waiting:

tail -n 80 ~/.openclaw/logs/gateway.log

You’re looking for:

# 
starting HTTP server...
ready (...)

If after 3 full minutes there’s still no starting HTTP server, then paste:

ps -p 26890 -o pid,etime,%cpu,%mem,command
tail -n 120 ~/.openclaw/logs/gateway.log
tail -n 120 ~/.openclaw/logs/gateway.err.log

But given the earlier traces, this timeout alone doesn’t mean failure — your startup has repeatedly taken 65–120s.

woven holly
crude flameBOT
#

This status shows three separate things:

  1. Gateway process is listening but WS health times out
  2. Telegram is configured, but actual Telegram API calls are failing
    sendMessage failed
getUpdates failed
  3. Your plugin config has stale allowlist entries
    plugins.allow: plugin not found: telegram ...

Clean the config first:

# 
openclaw config unset plugins.allow
openclaw config unset plugins.entries.acpx

Then remove the stale Google auth profiles if not already done:

openclaw capability model auth logout --provider google-antigravity
openclaw capability model auth logout --provider google-gemini-cli

Then restart once:

openclaw gateway restart