Openclaw Gateway issue | Friends of the Crustacean 🦞🤝 | Page 1

wild glen Apr 28, 2026, 8:37 AM

#

The issue that i have is that gateway does not restart properly when i try to use any of the openclaw commands. I always have to use stop and start.

keen laurelBOT Apr 28, 2026, 8:37 AM

#

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

torpid wraithBOT Apr 28, 2026, 8:38 AM

#

gateway restart should work, so if only stop → start works, I’d treat that as a service lifecycle/PATH issue rather than normal behavior.

First thing: what does this show?

openclaw --version
which openclaw
openclaw status --all
openclaw gateway status --deep

Then please run the failing restart directly and paste the exact output:

openclaw gateway restart --json

#

Also mention your OS/install method: macOS/Linux/VPS, npm/source/package, etc.

One likely cause is a split install / stale service wrapper: the shell openclaw and the managed gateway service may be pointing at different installs. The docs’ relevant runbook is here: https://docs.openclaw.ai/gateway/troubleshooting
Gateway lifecycle docs: https://docs.openclaw.ai/cli/gateway

wild glen Apr 28, 2026, 8:45 AM

#

using win11 WLS
OpenClaw 2026.4.26 (be8c246)
/home/luisadmin/.npm-global/bin/openclaw||
||OpenClaw status --all│ Version│ 2026.4.26
│ OS │ linux 6.6.87.2-microsoft-standard-WSL2 (x64)
│ Node │ 22.22.2
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale exposure │ off
│ Channel │ stable (default)
│ Update │ pnpm · up to date · npm latest 2026.4.26
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (timeout)
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown│
│ Gateway service │ systemd installed · enabled · running (pid 15397, state active)│
│ Node service │ systemd not installed│
│ Agents │ 1 total · 0 bootstrapping · 1 active · 16 sessions│
│ Secrets │ none
Channels
│ Channel │ Enabled │ State │ Detail
Agents
│ Agent │ Bootstrap file │ Sessions │ Active │ Store
│ main │ ABSENT │ 16 │ 1m ago │ /.openclaw/agents/main/sessions/sessions.json
Diagnosis (read-only)
Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/luisadmin/.openclaw/openclaw.json
Bind: loopback
✓ Config: /home/luisadmin/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789

#

Port 18789 is already in use.

pid 15397 luisadmin: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 22 eligible · 0 missing · /home/luisadmin/.openclaw/workspace
✓ Plugin compatibility (none)
Gateway restart attempts (tail): /home/luisadmin/.openclaw/logs/gateway-restart.log
[2026-04-27T08:59:58Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-27T10:16:31Z] openclaw restart done source=update
[2026-04-27T15:06:43Z] openclaw restart attempt source=update target=openclaw-

#

luisadmin@AE7:~$ openclaw gateway restart --json
{
"action": "restart",
"ok": true,
"result": "restarted",
"service": {
"label": "systemd",
"loaded": true,
"loadedText": "enabled",
"notLoadedText": "disabled"
}
}
luisadmin@AE7:~$

torpid wraithBOT Apr 28, 2026, 8:46 AM

#

Nice, that helps. The suspicious bit is:

Gateway service … systemd installed · enabled · running
but Gateway … unreachable (timeout)

So systemd thinks the process is alive, but the gateway isn’t answering on 127.0.0.1:18789. That’s why OpenClaw commands hang/fail.

Please paste these two outputs — especially the full ! Port 18789 ... line got cut off:

openclaw gateway status --deep
openclaw gateway restart --json

And the service log:

#

journalctl --user -u openclaw-gateway.service -n 120 --no-pager

If you just want to recover first:

openclaw gateway stop
openclaw gateway start
openclaw gateway status --deep

If that works, I’d next try refreshing the systemd unit:

openclaw gateway install --force

#

openclaw gateway restart

WSL2 is supported, but systemd/user-services can be a little cursed there. Relevant docs: https://docs.openclaw.ai/platforms/windows and https://docs.openclaw.ai/gateway/troubleshooting

#

Yep — that confirms it’s not another app stealing the port. It’s the OpenClaw gateway process itself:

pid 15397 ... openclaw-gateway (127.0.0.1:18789)

…but the CLI probe says it’s unreachable, so the gateway is bound to the port but not responding. That’s a hung/stuck gateway process.

Next useful thing is logs around the stuck state:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager
openclaw gateway restart --json

If restart consistently leaves it stuck but this works:

#

openclaw gateway stop
openclaw gateway start

then please file this as a bug with those outputs: https://github.com/openclaw/openclaw/issues

For a local workaround, you can refresh the systemd unit once:

openclaw gateway install --force
openclaw gateway stop
openclaw gateway start

After that, check:

#

openclaw gateway status --deep

The key detail to include in the issue: WSL2 + OpenClaw 2026.4.26 + systemd service running + gateway process owns 18789 but RPC probe times out; stop/start recovers, restart doesn’t.

#

That output means systemd accepted the restart and OpenClaw thinks the lifecycle command succeeded.

Now run this immediately after:

openclaw gateway status --deep
openclaw health --verbose

If those show Connectivity probe: ok / healthy, then manual restart is fine and we need the specific OpenClaw command that makes it get stuck.

If they still show unreachable (timeout) even after restart --json says ok: true, that’s useful bug evidence: restart reports success while the gateway is bound to 18789 but not responding.

Please also grab:

#

journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 80 ~/.openclaw/logs/gateway-restart.log

The next key question is: which command triggers the bad restart? openclaw update, openclaw doctor, config changes, dashboard changes, or literally any CLI command?

wild glen Apr 28, 2026, 8:54 AM

#

luisadmin@AE7:~/gemma4-browser-extension$ openclaw gateway install --force
openclaw gateway stop
openclaw gateway start
Installed systemd service: /home/luisadmin/.config/systemd/user/openclaw-gateway.service
Previous unit backed up to: /home/luisadmin/.config/systemd/user/openclaw-gateway.service.bak
Stopped systemd service: openclaw-gateway.service
Restarted systemd service: openclaw-gateway.service
luisadmin@AE7:~/gemma4-browser-extension$ openclaw gateway status --deep
◒ Checking gateway status...
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.log
Command: /home/luisadmin/.nvm/versions/node/v22.22.2/bin/node /home/luisadmin/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
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. (/home/luisadmin/.nvm/versions/node/v22.22.2/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/luisadmin/.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 16565, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
Troubles: run openclaw status

torpid wraithBOT Apr 28, 2026, 8:55 AM

#

Good — the gateway is healthy now:

Runtime: running
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789

The remaining warning is probably the important bit:

Service uses Node from a version manager: ~/.nvm/versions/node/v22.22.2/bin/node

That can make systemd services flaky after Node/OpenClaw upgrades because systemd doesn’t load your normal shell/nvm setup.

#

I’d do this next:

openclaw doctor
openclaw doctor --repair
openclaw gateway restart
openclaw gateway status --deep

If doctor says it can’t migrate because no system Node 22+ is available, install Node 22 system-wide in WSL, then rerun openclaw doctor --repair.

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

If restart hangs again after that, grab:

#

journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 100 ~/.openclaw/logs/gateway-restart.log

and file it here: https://github.com/openclaw/openclaw/issues

wild glen Apr 28, 2026, 8:56 AM

#

eveery command that restart the gataway. It Looks like the process of stoping and start gataway are to slow so it needs time and thats why it found the port in use

torpid wraithBOT Apr 28, 2026, 8:56 AM

#

Yeah, your read makes sense — but OpenClaw should wait long enough after a restart. If WSL2/systemd is slow and the old gateway still owns 18789, that’s either a restart timeout bug or a stuck shutdown.

Useful repro to capture:

date -Ins
openclaw gateway restart --json
date -Ins
openclaw gateway status --deep
sleep 10
openclaw gateway status --deep

And systemd details:

#

systemctl --user show openclaw-gateway.service -p ActiveState -p SubState -p ExecMainPID -p TimeoutStopUSec -p Restart -p KillMode
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Workaround for now:

openclaw gateway stop
sleep 5
openclaw gateway start

If sleep 5 fixes it reliably, please file that as a bug: WSL2 + 2026.4.26 restart reports success / restarts too quickly while old gateway still holds port 18789.

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

wild glen Apr 28, 2026, 9:04 AM

#

is not just the gateway is everything openclaw just go very slow. when it is open it takes 1 or 2 minutes to responde a simple Hole using gpt 5.5

torpid wraithBOT Apr 28, 2026, 9:04 AM

#

That changes the diagnosis a bit. If everything is slow, split it into two tests:

1) Is the local gateway slow?

Run:

time openclaw health --verbose
time openclaw gateway status --require-rpc

Those should be seconds, not 1–2 minutes. If they’re slow, it’s WSL/systemd/local gateway.

2) Is the model call slow?

Run:

#

time openclaw infer model run --prompt "Reply with exactly: pong" --json
openclaw models status --probe

If only this is slow, it’s provider/model/auth/network latency, not the gateway restart path. For current model recommendations, #models is the best place because latency changes constantly.

Also, because your service warning showed nvm/systemd weirdness, I’d still do:

openclaw doctor --repair
openclaw gateway restart

Then test a fresh session too — long sessions/tool context can make even “hola” take much longer than a raw chat completion.

#

/new

If you paste the timings from those time ... commands, we can tell pretty quickly whether this is WSL/gateway, provider/model, or session-context bloat.

wild glen Apr 28, 2026, 9:05 AM

#

luisadmin@AE7:~$ time openclaw health --verbose
time openclaw gateway status --require-rpc

🦞 OpenClaw 2026.4.26 (be8c246) — Somewhere between 'hello world' and 'oh god what have I built.'

│
◇
[openclaw] Failed to start CLI: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/luisadmin/.openclaw/openclaw.json
Bind: loopback
at Timeout.<anonymous> (file:///home/luisadmin/.npm-global/lib/node_modules/openclaw/dist/call-CP7A3sdw.js:286:9)
at listOnTimeout (node:internal/timers:585:17)
at process.processTimers (node:internal/timers:521:7)

real 0m11.670s
user 0m1.834s
sys 0m0.605s
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-28.log
Command: /home/luisadmin/.nvm/versions/node/v22.22.2/bin/node /home/luisadmin/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
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. (/home/luisadmin/.nvm/versions/node/v22.22.2/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/luisadmin/.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 17731, state active, sub running, last exit 0, reason 0)
Read probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
Troubles: run openclaw status
real 0m6.954s
user 0m1.829s
sys 0m0.360s

torpid wraithBOT Apr 28, 2026, 9:06 AM

#

That confirms it: this is local gateway slowness, not GPT/model latency.

openclaw health --verbose should not take 10s and timeout, and gateway status --require-rpc taking ~7s is already too slow. So focus on WSL/systemd/runtime first.

Two things to do next:

openclaw doctor --repair
openclaw gateway restart
openclaw gateway status --deep

That nvm warning matters:

service uses Node from a version manager

#

Systemd + nvm in WSL can be flaky/slow because it doesn’t load the same shell environment.

Then grab local logs without going through RPC:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager
tail -n 200 /tmp/openclaw/openclaw-2026-04-28.log

And one quick resource check:

ps -p 17731 -o pid,etime,%cpu,%mem,rss,cmd
free -h
df -h ~ /tmp

#

If doctor --repair doesn’t fix the nvm/systemd warning and the gateway still takes 7–10s for local probes, this is good GitHub issue material. The key title would be something like:

WSL2 gateway RPC very slow / health timeout while status read probe succeeds

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

wild glen Apr 28, 2026, 9:25 AM

#

ime openclaw infer model run --prompt "Reply with exactly: pong" --json
openclaw models status --probe
11:07:22 [agent/embedded] workspace bootstrap file AGENTS.md is 19193 chars (limit 12000); truncating in injected context (sessionKey=agent:main:main)
11:07:22 [agent/embedded] workspace bootstrap file TOOLS.md is 16892 chars (limit 12000); truncating in injected context (sessionKey=agent:main:main)
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.5",
"attempts": [],
"outputs": [
{
"text": "pong",
"mediaUrl": null
}
]
}
real 1m25.256s
user 0m59.423s
sys 0m27.978s
11:08:34 [agent/embedded] workspace bootstrap file AGENTS.md is 19193 chars (limit 12000); truncating in injected context (sessionKey=probe-openai-codex-27e4888e-49e3-42b9-bc4b-555eb5d70208)
11:08:34 [agent/embedded] workspace bootstrap file TOOLS.md is 16892 chars (limit 12000); truncating in injected context (sessionKey=probe-openai-codex-27e4888e-49e3-
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (2): openai-codex/gpt-5.4, openai-codex/gpt-5.5
Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (1)

openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:luis_tabla@hotmail.com=OAuth (luis_tabla@hotmail.com)
Outh/token status
openai-codex usage: 5h 94% left ⏱2h 51m · Week 99% left ⏱6d 21h
- openai-codex:luis_tabla@hotmail.com (luis_tabla@hotmail.com) ok expires in 9d
  Auth probes
  │ Model│ Profile│ Status│
  │ openai-codex/gpt-5.5 │ openai-codex:luis_tabla@hotmail.com (luis_tabla@hotmail.com) (oauth) │ ok · 35.7s │
  Probed 1 target in 62.7s
  luisadmin@AE7:~$

torpid wraithBOT Apr 28, 2026, 9:26 AM

#

Yep — now we have the smoking guns.

Two separate slowdowns:

Huge workspace bootstrap files
```
AGENTS.md is 19193 chars
TOOLS.md is 16892 chars
truncating...
```
Those are injected into every run. Even “pong” is carrying a giant prompt. Trim those way down or temporarily move them aside to test.

Provider/model probe is slow

openai-codex/gpt-5.5 probe ok · 35.7s
Probed 1 target in 62.7s

#

That part is model/provider latency. For current fast model recommendations, ask in #models — latency changes too fast for me to confidently recommend one here.

Quick test:

cd ~/.openclaw/workspace
mv AGENTS.md AGENTS.md.bak
mv TOOLS.md TOOLS.md.bak
printf '%s\n' '# AGENTS.md' 'Keep replies concise.' > AGENTS.md
printf '%s\n' '# TOOLS.md' > TOOLS.md

time openclaw infer model run --prompt "Reply with exactly: pong" --json

If that drops from 1m25s to something much smaller, your workspace bootstrap is the main local slowdown. Then restore the useful parts gradually, but keep AGENTS.md / TOOLS.md short.

wild glen Apr 28, 2026, 9:38 AM

#

luisadmin@AE7:~$ cd ~/.openclaw/workspace
mv AGENTS.md AGENTS.md.bak
mv TOOLS.md TOOLS.md.bak
printf '%s\n' ' AGENTS.md' 'Keep replies concise.' > AGENTS.md
printf '%s\n' 'TOOLS.md' > TOOLS.md

time openclaw infer model run --prompt "Reply with exactly: pong" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.5",
"attempts": [],
"outputs": [
{
"text": "pong",
"mediaUrl": null
}
]
}

real 1m29.117s
user 0m58.272s
sys 0m28.571s

torpid wraithBOT Apr 28, 2026, 9:38 AM

#

That test disproves the big AGENTS.md/TOOLS.md theory. Even with tiny files, the raw model smoke test is still 1m29s.

The weird part is this:

real 1m29s
user 0m58s
sys  0m28s

That means your machine/WSL is spending a lot of CPU locally, not just waiting on the network. And your probe already showed openai-codex/gpt-5.5 taking 35.7s, so you likely have both local overhead + slow provider/model path.

Please run these quick isolators:

time openclaw --version

#

time openclaw models status --json >/tmp/models.json
time openclaw infer model inspect --name gpt-5.5 --json >/tmp/inspect.json
time openclaw infer model run --gateway --prompt "Reply with exactly: pong" --json

If --version / models status are also slow, it’s local WSL/Node/OpenClaw startup. If only infer model run is slow, it’s the openai-codex/gpt-5.5 route.

Also: for speed, ask in #models what people are currently using. Your current default is the Codex OAuth/subscription route, and that may simply be slow right now.

wild glen Apr 28, 2026, 10:26 AM

#

luisadmin@AE7:~/.openclaw/workspace$ time openclaw --version
OpenClaw 2026.4.26 (be8c246)

real 0m0.096s
user 0m0.054s
sys 0m0.023s
luisadmin@AE7:~/.openclaw/workspace$ time openclaw models status --json >/tmp/models.json
time openclaw infer model inspect --name gpt-5.5 --json >/tmp/inspect.json
time openclaw infer model run --gateway --prompt "Reply with exactly: pong" --json

real 0m9.584s
user 0m8.592s
sys 0m1.829s
error: required option '--model <provider/model>' not specified

real 0m1.356s
user 0m1.592s
sys 0m0.318s
{
"ok": true,
"capability": "model.run",
"transport": "gateway",
"provider": "openai-codex",
"model": "gpt-5.5",
"attempts": [],
"outputs": [
{
"text": "pong",
"mediaUrl": null
}
]
}

real 0m44.795s
user 0m2.376s
sys 0m0.510s

torpid wraithBOT Apr 28, 2026, 10:26 AM

#

This is clearer now:

openclaw --version: 0.096s ✅ local CLI startup is fine
models status: 9.5s = some local config/auth overhead, but not the main issue
raw gateway model call: 44.8s for pong = the big slowdown is the openai-codex/gpt-5.5 route

So the 1–2 minute “hola” replies are probably not WSL itself. Your selected model/provider path is slow, and full chat replies add extra agent/session/tool overhead on top of that.

For the failed inspect command, use:

time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json

For speed, I’d test a different provider/model config. Ask in #models for what’s currently fast — I don’t want to give stale model advice here.

Also, your restart issue may be partly related: if a model call is taking 45–90s, gateway restarts can feel stuck while the process is busy/draining. Still worth filing if restart reports success while the port is stale.

wild glen Apr 28, 2026, 10:30 AM

#

luisadmin@AE7:~/.openclaw/workspace$ time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json

real 0m32.703s
user 0m24.645s
sys 0m8.821s

torpid wraithBOT Apr 28, 2026, 10:31 AM

#

That confirms local catalog/provider setup is slow, not just the model reply.

model inspect shouldn’t need a real model completion, but it still took:

real 32.7s
user 24.6s
sys  8.8s

So OpenClaw is spending a lot of local CPU just loading/resolving the openai-codex/gpt-5.5 catalog/auth path.

Next useful debug:

OPENCLAW_DEBUG_INGRESS_TIMING=1 time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json

#

Paste the timing/stage logs it prints. That should show whether it’s stuck on models.json generation, PI SDK import, auth storage, registry read, or plugin catalog merge.

Also, since trimming AGENTS.md/TOOLS.md didn’t help, restore them if you want:

cd ~/.openclaw/workspace
mv -f AGENTS.md.bak AGENTS.md
mv -f TOOLS.md.bak TOOLS.md

At this point I’d file this as a performance bug: WSL2 + 2026.4.26 + openai-codex/gpt-5.5 model inspect takes 32s CPU and model run takes 45–90s.

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

wild glen Apr 28, 2026, 10:41 AM

#

luisadmin@AE7:~/.openclaw/workspace$ OPENCLAW_DEBUG_INGRESS_TIMING=1 time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json
[model-catalog] stage=models-json-ready elapsedMs=14509
[model-catalog] stage=pi-sdk-imported elapsedMs=14524
[model-catalog] stage=catalog-deps-ready elapsedMs=14528
[model-catalog] stage=auth-storage-ready elapsedMs=20367
[model-catalog] stage=registry-ready elapsedMs=20372
[model-catalog] stage=registry-read elapsedMs=20373 entries=887
[model-catalog] stage=plugin-models-merged elapsedMs=30392 entries=909
[model-catalog] stage=complete elapsedMs=30393 entries=909
24.64user 9.18system 0:33.23elapsed 101%CPU (0avgtext+0avgdata 822244maxresident)k
214488inputs+10344outputs (56major+518236minor)pagefaults 0swaps
luisadmin@AE7:~/.openclaw/workspace$

torpid wraithBOT Apr 28, 2026, 10:42 AM

#

This is a very useful trace. It shows the slowdown is mostly model catalog/discovery, before any real model call:

models-json-ready      14.5s
auth-storage-ready     20.3s
plugin-models-merged   30.4s

plugin-models-merged taking ~10s strongly suggests plugin model discovery — likely Codex discovery. If you’re not intentionally using the native Codex harness, try disabling Codex model discovery:

openclaw config set plugins.entries.codex.config.discovery.enabled false --strict-json
openclaw gateway restart

Then retest:

#

OPENCLAW_DEBUG_INGRESS_TIMING=1 time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json
time openclaw infer model run --gateway --prompt "Reply with exactly: pong" --json

This should not remove your openai-codex/gpt-5.5 OAuth route — it just avoids probing Codex’s native app-server model discovery and uses fallback catalog behavior.

Docs mention this exact knob here: https://docs.openclaw.ai/plugins/codex-harness#model-discovery

wild glen Apr 28, 2026, 10:48 AM

#

luisadmin@AE7:~/.openclaw/workspace$ OPENCLAW_DEBUG_INGRESS_TIMING=1 time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json
time openclaw infer model run --gateway --prompt "Reply with exactly: pong" --json
Config warnings:

plugins.entries.codex: plugin disabled (bundled (disabled by default)) but config is present
[model-catalog] stage=models-json-ready elapsedMs=14249
[model-catalog] stage=pi-sdk-imported elapsedMs=14256
[model-catalog] stage=catalog-deps-ready elapsedMs=14258
[model-catalog] stage=auth-storage-ready elapsedMs=20367
[model-catalog] stage=registry-ready elapsedMs=20370
[model-catalog] stage=registry-read elapsedMs=20371 entries=887
[model-catalog] stage=plugin-models-merged elapsedMs=30344 entries=909
[model-catalog] stage=complete elapsedMs=30346 entries=909
25.81user 9.05system 0:32.46elapsed 107%CPU (0avgtext+0avgdata 883168maxresident)k
37912inputs+9368outputs (38major+531250minor)pagefaults 0swaps
Config warnings:
plugins.entries.codex: plugin disabled (bundled (disabled by default)) but config is present
{
"ok": true,
"capability": "model.run",
"transport": "gateway",
"provider": "openai-codex",
"model": "gpt-5.5",
"attempts": [],
"outputs": [
{
"text": "pong",
"mediaUrl": null
}
]
}

real 0m42.912s
user 0m2.497s
sys 0m0.491s
luisadmin@AE7:~/.openclaw/workspace$

torpid wraithBOT Apr 28, 2026, 10:50 AM

#

Yep — Codex discovery was a bad guess. The warning says Codex is disabled, so that config isn’t being used.

This trace is still a solid bug/perf case:

models-json-ready      14.2s
auth-storage-ready     20.3s
plugin-models-merged   30.3s
RSS ~883MB

That means catalog/auth/plugin setup is eating ~30s locally before any useful work.

You can clean the warning with:

#

openclaw config unset plugins.entries.codex

…but I don’t expect that to fix the 30s, since Codex is already disabled.

For the GitHub issue, include this trace plus:

openclaw plugins list --enabled --json > /tmp/plugins.json
openclaw config get plugins --json > /tmp/plugins-config.json
ls -lh ~/.openclaw/agents/main/agent/models.json ~/.openclaw/agents/main/agent/auth-profiles.json

Review /tmp/plugins-config.json before sharing, just in case plugin config contains anything private.

At this point I’d file it as:

#

WSL2 2026.4.26 model catalog load takes 30s / 880MB before model inspect

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

wild glen Apr 28, 2026, 10:51 AM

#

is it worth uploading WSL?

torpid wraithBOT Apr 28, 2026, 10:52 AM

#

If you mean updating WSL: yes, it’s worth trying. It may not fix the OpenClaw catalog bug, but WSL2/systemd weirdness can absolutely cause slow/stale service behavior.

From PowerShell as admin:

wsl --update
wsl --shutdown

Then reopen Ubuntu/WSL and run:

sudo apt update && sudo apt upgrade -y
openclaw gateway restart
openclaw gateway status --deep

#

Then retest the slow catalog trace:

OPENCLAW_DEBUG_INGRESS_TIMING=1 time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json

If it’s still ~30s after WSL update, file the issue — we’ve got enough evidence.

wild glen Apr 28, 2026, 11:00 AM

#

luisadmin@AE7:~$ OPENCLAW_DEBUG_INGRESS_TIMING=1 time openclaw infer model inspect --model openai-codex/gpt-5.5 --json >/tmp/inspect.json
[model-catalog] stage=models-json-ready elapsedMs=12760
[model-catalog] stage=pi-sdk-imported elapsedMs=12772
[model-catalog] stage=catalog-deps-ready elapsedMs=12774
[model-catalog] stage=auth-storage-ready elapsedMs=18661
[model-catalog] stage=registry-ready elapsedMs=18666
[model-catalog] stage=registry-read elapsedMs=18666 entries=887
[model-catalog] stage=plugin-models-merged elapsedMs=28159 entries=909
[model-catalog] stage=complete elapsedMs=28161 entries=909
25.05user 8.78system 0:30.28elapsed 111%CPU (0avgtext+0avgdata 877744maxresident)k
5816inputs+44200outputs (54major+545221minor)pagefaults 0swaps
luisadmin@AE7:~$

torpid wraithBOT Apr 28, 2026, 11:00 AM

#

WSL update helped only a tiny bit, so yeah — this is worth filing now.

The repro is clean:

OpenClaw 2026.4.26
WSL2 / linux 6.6.87.2-microsoft-standard-WSL2
openai-codex/gpt-5.5
model inspect takes ~30s CPU, ~878MB RSS
models-json-ready ~12.8s
auth-storage-ready ~18.7s
plugin-models-merged ~28.2s

That’s not normal for a catalog inspect.

Please file it here: https://github.com/openclaw/openclaw/issues

#

Suggested title:

WSL2: model catalog inspect takes ~30s / 878MB for openai-codex provider

Include the timing trace you just pasted, plus:

openclaw --version
openclaw status --all
openclaw plugins list --enabled --json
ls -lh ~/.openclaw/agents/main/agent/models.json ~/.openclaw/agents/main/agent/auth-profiles.json

Don’t paste secrets/auth files directly — just sizes and sanitized status output.

wild glen Apr 28, 2026, 11:01 AM

#

should change to 5.4 help?

torpid wraithBOT Apr 28, 2026, 11:01 AM

#

It might help the model latency part, but it probably won’t fix the 30s catalog-load bug. Worth testing before changing default.

Run this first:

time openclaw infer model run --gateway --model openai-codex/gpt-5.4 --prompt "Reply with exactly: pong" --json

Compare it to your 5.5 result (~43s gateway / ~85s local).

If 5.4 is much faster, switch default:

openclaw models set openai-codex/gpt-5.4
openclaw gateway restart

#

Then test normal chat again.

But if 5.4 is still slow, don’t chase model versions too much — the catalog trace is still the bigger OpenClaw-side issue to file.

wild glen Apr 28, 2026, 11:03 AM

#

luisadmin@AE7:~$ time openclaw infer model run --gateway --model openai-codex/gpt-5.4 --prompt "Reply with exactly: pong" --json
{
"ok": true,
"capability": "model.run",
"transport": "gateway",
"provider": "openai-codex",
"model": "gpt-5.4",
"attempts": [],
"outputs": [
{
"text": "pong",
"mediaUrl": null
}
]
}

real 0m46.704s
user 0m2.428s
sys 0m0.503s

torpid wraithBOT Apr 28, 2026, 11:03 AM

#

Nope — 5.4 doesn’t help. It’s basically the same as 5.5:

5.5 gateway pong: ~42.9s
5.4 gateway pong: ~46.7s

So I’d stay on 5.5 unless you prefer 5.4 for other reasons.

What we know now:

local CLI startup is fine
gateway RPC works but is sometimes slow
openai-codex model calls are ~45s even for pong
catalog loading is ~30s CPU / ~878MB RSS
changing 5.5 → 5.4 doesn’t improve latency

#Openclaw Gateway issue

1) Is the local gateway slow?

2) Is the model call slow?