- Unknown or unavailable CLI commands should fail before provider/plugin runtime loading. - Invalid CLI commands should not leave hot child processes alive. - `channels logs` should not require loading provider/model plugins just to print recent channel logs. - `models.list` / `sessions.list` / Control UI polling should not repeatedly cold-load all provider plugins on the gateway hot path. - Repeated UI polling should not be able to keep the main gateway loop at ~60-80% CPU when no agent run is active. - Event-loop delay should stay low enough for gateway health/readiness and channel handling to remain responsive.

openclaw - ✅(Solved) Fix Unknown CLI commands load plugins and leave hot child process while gateway saturates [1 pull requests, 4 comments, 2 participants]

bcdonadio · 2026-04-30T22:26:12Z

[openclaw] A live main source checkout is showing two related CPU/event-loop issues: 1. Running a non-existent command such as openclaw foo does not fail fast.… A live `main` source checkout is showing two related CPU/event-loop issues: 1. Running a non-existent command such as `openclaw foo` does not fail fast. It loads provider plugins, loads the runtime plugin set, prints an unavailable-command error, and leaves a hot `openclaw` child process alive at ~90% CPU. 2. The running gateway shows high sustained CPU, degraded event-loop diagnostics, and repeated provider plugin load bursts around log/model/session/control-ui surfaces. The key failure mode is that invalid CLI input can trigger expensive plugin loading and leave a busy child process instead of returning a normal unknown-command error and exiting cleanly. # PR #75326: perf: keep models list responsive during catalog discovery - Repository: openclaw/openclaw - Author: steipete - State: closed | merged: True - Link: https://github.com/openclaw/openclaw/pull/75326 ## Description (problem / solution / changelog) ## Summary - Problem: `models.list` default/configured views wait for full gateway model catalog discovery on cold or slow provider/plugin catalog paths. - Why it matters: slow model discovery makes common CLI/UI control-plane calls look stalled during gateway CPU/event-loop starvation incidents. - What changed: default/configured `models.list` now falls back to configured/synthetic rows after a short wait, while discovery continues through the existing catalog cache path. - What did NOT change (scope boundary): `models.list --all` remains exact and waits for the full discovered catalog; no provider auth, catalog schema, or model execution behavior changed. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor required for the fix - [x] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [x] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [x] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Related #72338 - Related #74404 - Related #75297 - Related #75287 - [x] This PR fixes a bug or regression ## Root Cause (if applicable) - Root cause: `models.list` always awaited `context.loadGatewayModelCatalog()`, even for views that can answer from configured model rows when provider discovery is slow. - Missing detection / guardrail: `sessions.list` had slow-catalog timeout coverage, but `models.list` did not. - Contributing context (if known): provider plugin augmentation/runtime-deps can make model catalog discovery slow on packaged gateway installs. ## Regression Test Plan (if applicable) - Coverage level that should have caught this: - [x] Unit test - [ ] Seam / integration test - [ ] End-to-end test - [ ] Existing coverage already sufficient - Target test or file: `src/gateway/server-methods/models.test.ts` - Scenario the test should lock in: configured view returns configured model rows after a slow-catalog timeout; `view=all` still waits for exact catalog data. - Why this is the smallest reliable guardrail: it exercises the request handler directly with fake timers and a deferred catalog promise. - Existing test that already covers this (if any): existing server model tests cover catalog contents, not slow discovery behavior. - If no new test is added, why not: N/A. ## User-visible / Behavior Changes `models list` default/configured views can return configured model rows quickly while provider discovery is still slow. `models list --all` remains the exact wait-for-discovery command. ## Diagram (if applicable) ```text Before: models.list default/configured -> await full provider catalog -> delayed response After: models.list default/configured -> short wait -> configured/synthetic rows -> responsive control plane models.list --all -> await full provider catalog -> exact response ``` ## Security Impact (required) - New permissions/capabilities? No - Secrets/tokens handling changed? No - New/changed network calls? No - Command/tool execution surface changed? No - Data access scope changed? No - If any `Yes`, explain risk + mitigation: N/A ## Repro + Verification ### Environment - OS: macOS local plus Blacksmith Linux Testbox - Runtime/container: Node/pnpm via repo wrappers - Model/provider: configured model fixture - Integration/channel (if any): Gateway RPC `models.list` - Relevant config (redacted): configured `models.providers.openai.models` fixture ### Steps 1. Call `models.list` configured view with `loadGatewayModelCatalog()` deferred. 2. Advance fake timers past the short timeout. 3. Assert the handler returns configured model rows. 4. Repeat with `view=all` and assert it waits for the deferred catalog. ### Expected - Default/configured views stay responsive; `all` remains exact. ### Actual - Before this patch, all views waited on the slow catalog promise. After this patch, only `all` does. ## Evidence

openclaw2026-04-30 22:26:12

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#75287•Fetched 2026-05-01 05:35:46

View on GitHub

Comments

Participants

Timeline

Reactions

Author

bcdonadio

Participants

bcdonadio

clawsweeper[bot]

Timeline (top)

commented ×4cross-referenced ×2renamed ×1

A live main source checkout is showing two related CPU/event-loop issues:

Running a non-existent command such as openclaw foo does not fail fast. It loads provider plugins, loads the runtime plugin set, prints an unavailable-command error, and leaves a hot openclaw child process alive at ~90% CPU.
The running gateway shows high sustained CPU, degraded event-loop diagnostics, and repeated provider plugin load bursts around log/model/session/control-ui surfaces.

The key failure mode is that invalid CLI input can trigger expensive plugin loading and leave a busy child process instead of returning a normal unknown-command error and exiting cleanly.

Error Message

Config warnings:

plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts) Config warnings:
plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts) [plugins] loading anthropic from .../dist/extensions/anthropic/index.js [plugins] loading byteplus from .../dist/extensions/byteplus/index.js [plugins] loading deepseek from .../dist/extensions/deepseek/index.js [plugins] loading moonshot from .../dist/extensions/moonshot/index.js [plugins] loading tencent from .../dist/extensions/tencent/index.js [plugins] loading volcengine from .../dist/extensions/volcengine/index.js [plugins] loading xai from .../dist/extensions/xai/index.js [plugins] loaded 7 plugin(s) (7 attempted) in 434.6ms [plugins] loading anthropic from .../dist/extensions/anthropic/index.js ... [plugins] loaded 7 plugin(s) (7 attempted) in 31.3ms [plugins] loading openclaw-honcho from /home/claw/openclaw-honcho/dist/index.js [plugins] Honcho memory plugin loaded [plugins] loading opik-openclaw from /home/claw/opik-openclaw/index.ts [plugins] loading acpx from .../dist/extensions/acpx/index.js ... [plugins] loading lossless-claw from /home/claw/.openclaw/extensions/lossless-claw/dist/index.js plugin runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current(). [plugins] loaded 120 plugin(s) (17 attempted) in 4184.6ms [openclaw] Failed to start CLI: Error: The openclaw foo command is unavailable because plugins.allow excludes "foo". Add "foo" to plugins.allow if you want that bundled plugin CLI surface.

Root Cause

Config warnings:
- plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts)
Config warnings:
- plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts)
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
[plugins] loading byteplus from .../dist/extensions/byteplus/index.js
[plugins] loading deepseek from .../dist/extensions/deepseek/index.js
[plugins] loading moonshot from .../dist/extensions/moonshot/index.js
[plugins] loading tencent from .../dist/extensions/tencent/index.js
[plugins] loading volcengine from .../dist/extensions/volcengine/index.js
[plugins] loading xai from .../dist/extensions/xai/index.js
[plugins] loaded 7 plugin(s) (7 attempted) in 434.6ms
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
...
[plugins] loaded 7 plugin(s) (7 attempted) in 31.3ms
[plugins] loading openclaw-honcho from /home/claw/openclaw-honcho/dist/index.js
[plugins] Honcho memory plugin loaded
[plugins] loading opik-openclaw from /home/claw/opik-openclaw/index.ts
[plugins] loading acpx from .../dist/extensions/acpx/index.js
...
[plugins] loading lossless-claw from /home/claw/.openclaw/extensions/lossless-claw/dist/index.js
plugin runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current().
[plugins] loaded 120 plugin(s) (17 attempted) in 4184.6ms
[openclaw] Failed to start CLI: Error: The `openclaw foo` command is unavailable because `plugins.allow` excludes "foo". Add "foo" to `plugins.allow` if you want that bundled plugin CLI surface.

Fix Action

Fix / Workaround

Check CLI dispatch and provider/plugin catalog loading for:

PR fix notes

PR #75326: perf: keep models list responsive during catalog discovery

Repository: openclaw/openclaw
Author: steipete
State: closed | merged: True
Link: https://github.com/openclaw/openclaw/pull/75326

Description (problem / solution / changelog)

Summary

Problem: models.list default/configured views wait for full gateway model catalog discovery on cold or slow provider/plugin catalog paths.
Why it matters: slow model discovery makes common CLI/UI control-plane calls look stalled during gateway CPU/event-loop starvation incidents.
What changed: default/configured models.list now falls back to configured/synthetic rows after a short wait, while discovery continues through the existing catalog cache path.
What did NOT change (scope boundary): models.list --all remains exact and waits for the full discovered catalog; no provider auth, catalog schema, or model execution behavior changed.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Related #72338
Related #74404
Related #75297
Related #75287
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: models.list always awaited context.loadGatewayModelCatalog(), even for views that can answer from configured model rows when provider discovery is slow.
Missing detection / guardrail: sessions.list had slow-catalog timeout coverage, but models.list did not.
Contributing context (if known): provider plugin augmentation/runtime-deps can make model catalog discovery slow on packaged gateway installs.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/gateway/server-methods/models.test.ts
Scenario the test should lock in: configured view returns configured model rows after a slow-catalog timeout; view=all still waits for exact catalog data.
Why this is the smallest reliable guardrail: it exercises the request handler directly with fake timers and a deferred catalog promise.
Existing test that already covers this (if any): existing server model tests cover catalog contents, not slow discovery behavior.
If no new test is added, why not: N/A.

User-visible / Behavior Changes

models list default/configured views can return configured model rows quickly while provider discovery is still slow. models list --all remains the exact wait-for-discovery command.

Diagram (if applicable)

Before:
models.list default/configured -> await full provider catalog -> delayed response

After:
models.list default/configured -> short wait -> configured/synthetic rows -> responsive control plane
models.list --all -> await full provider catalog -> exact response

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: macOS local plus Blacksmith Linux Testbox
Runtime/container: Node/pnpm via repo wrappers
Model/provider: configured model fixture
Integration/channel (if any): Gateway RPC models.list
Relevant config (redacted): configured models.providers.openai.models fixture

Steps

Call models.list configured view with loadGatewayModelCatalog() deferred.
Advance fake timers past the short timeout.
Assert the handler returns configured model rows.
Repeat with view=all and assert it waits for the deferred catalog.

Expected

Default/configured views stay responsive; all remains exact.

Actual

Before this patch, all views waited on the slow catalog promise. After this patch, only all does.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios: focused models handler test passed locally; combined changed gate passed on Blacksmith Testbox before PR split.
Edge cases checked: view=all exact behavior is covered by a separate test.
What you did not verify: live Linux npm-global Telegram repro/profile.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: default/configured views may temporarily omit auth-backed discovered provider rows during slow discovery.
- Mitigation: configured/synthetic rows still return, existing cache refresh continues, and --all remains available for exact discovery.

Changed files

CHANGELOG.md (modified, +1/-0)
docs/cli/models.md (modified, +5/-0)
src/gateway/server-methods/models.test.ts (added, +156/-0)
src/gateway/server-methods/models.ts (modified, +40/-1)

Code Example

openclaw foo

---

setsid bash -lc "openclaw foo >/tmp/openclaw-direct-foo.log 2>&1" &
sleep 20
ps -eo pid,ppid,pgid,etime,stat,pcpu,command | awk -v pg="$leader" '$3==pg || $1==pg {print}'

---

PID      PPID    PGID    ELAPSED STAT %CPU COMMAND
1104454  1104452 1104454 00:20   Ss    0.0 bash -lc openclaw foo ...
1104481  1104454 1104454 00:19   Sl    0.8 openclaw
1104493  1104481 1104454 00:19   Rl   93.5 openclaw

---

Config warnings:
- plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts)
Config warnings:
- plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts)
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
[plugins] loading byteplus from .../dist/extensions/byteplus/index.js
[plugins] loading deepseek from .../dist/extensions/deepseek/index.js
[plugins] loading moonshot from .../dist/extensions/moonshot/index.js
[plugins] loading tencent from .../dist/extensions/tencent/index.js
[plugins] loading volcengine from .../dist/extensions/volcengine/index.js
[plugins] loading xai from .../dist/extensions/xai/index.js
[plugins] loaded 7 plugin(s) (7 attempted) in 434.6ms
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
...
[plugins] loaded 7 plugin(s) (7 attempted) in 31.3ms
[plugins] loading openclaw-honcho from /home/claw/openclaw-honcho/dist/index.js
[plugins] Honcho memory plugin loaded
[plugins] loading opik-openclaw from /home/claw/opik-openclaw/index.ts
[plugins] loading acpx from .../dist/extensions/acpx/index.js
...
[plugins] loading lossless-claw from /home/claw/.openclaw/extensions/lossless-claw/dist/index.js
plugin runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current().
[plugins] loaded 120 plugin(s) (17 attempted) in 4184.6ms
[openclaw] Failed to start CLI: Error: The `openclaw foo` command is unavailable because `plugins.allow` excludes "foo". Add "foo" to `plugins.allow` if you want that bundled plugin CLI surface.

---

pnpm openclaw gateway status --deep
pnpm openclaw channels logs --lines 80
journalctl --user -u openclaw-gateway.service --since '10 minutes ago' --no-pager
ps -p $(systemctl --user show openclaw-gateway.service -p MainPID --value) -o pid,ppid,etime,pcpu,pmem,rss,stat,command
pnpm openclaw health --json

---

[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
[plugins] loading byteplus from .../dist/extensions/byteplus/index.js
[plugins] loading deepseek from .../dist/extensions/deepseek/index.js
[plugins] loading moonshot from .../dist/extensions/moonshot/index.js
[plugins] loading tencent from .../dist/extensions/tencent/index.js
[plugins] loading volcengine from .../dist/extensions/volcengine/index.js
[plugins] loading xai from .../dist/extensions/xai/index.js
[plugins] loaded 7 plugin(s) (7 attempted) in 565.2ms
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
...
[plugins] loaded 7 plugin(s) (7 attempted) in 92.8ms

---

[plugins] loading amazon-bedrock from .../dist/extensions/amazon-bedrock/index.js
[plugins] loading amazon-bedrock-mantle from .../dist/extensions/amazon-bedrock-mantle/index.js
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
[plugins] loading anthropic-vertex from .../dist/extensions/anthropic-vertex/index.js
...
[plugins] loading zai from .../dist/extensions/zai/index.js
[plugins] loaded 49 plugin(s) (49 attempted) in 1422.3ms
[ws] ⇄ res ✓ models.list 18353ms ...
[ws] ⇄ res ✓ models.list 7590ms ...

---

[gateway] sessions.list continuing without model catalog after 750ms
[ws] ⇄ res ✓ sessions.list 10155ms ...

---

PID       ELAPSED %CPU %MEM   RSS STAT COMMAND
1101846   07:12  61.8  5.4  892284 Rsl  node dist/index.js gateway --port 18789

---

[diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=30s eventLoopDelayP99Ms=2457.9 eventLoopDelayMaxMs=5469.4 eventLoopUtilization=1 cpuCoreRatio=0.921 active=0 waiting=0 queued=0
[diagnostic] liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=1270.9 eventLoopDelayMaxMs=1598 eventLoopUtilization=0.94 cpuCoreRatio=0.818 active=0 waiting=0 queued=0

---

[ws] ⇄ res ✓ node.list 1480ms conn=...
[ws] ⇄ res ✓ node.list 1423ms conn=...
[ws] ⇄ res ✓ node.list 3535ms conn=...
[ws] ⇄ res ✓ node.list 3538ms conn=...
[ws] ⇄ res ✓ node.list 2026ms conn=...
[ws] ⇄ res ✓ node.list 2058ms conn=...

---

pnpm openclaw health --json
# durationMs: 10282
# plugins.errors: []
# channels signal/telegram/whatsapp running, whatsapp healthy/linked

RAW_BUFFERClick to expand / collapse

Summary

A live main source checkout is showing two related CPU/event-loop issues:

Running a non-existent command such as openclaw foo does not fail fast. It loads provider plugins, loads the runtime plugin set, prints an unavailable-command error, and leaves a hot openclaw child process alive at ~90% CPU.
The running gateway shows high sustained CPU, degraded event-loop diagnostics, and repeated provider plugin load bursts around log/model/session/control-ui surfaces.

The key failure mode is that invalid CLI input can trigger expensive plugin loading and leave a busy child process instead of returning a normal unknown-command error and exiting cleanly.

Environment

Repo: openclaw/openclaw
Checkout kind: source/git checkout
Affected local commit when reproduced: 4429ee7d2e7f6261bc5af5827e20d9566b2287da
origin/main at time of update to this issue: 359d871293e801dc9e5506b5002a4bf545c42662
Note on version: this is a live mainline source checkout on 2026-04-30. The package/CLI banner still reports 2026.4.27, so do not interpret the original report as being limited to an old 4.27 release.
Runtime: Node 22, systemd user gateway
Gateway command: node dist/index.js gateway --port 18789

Repro: non-existent CLI command

openclaw foo

Controlled repro used a separate process group so it could be cleaned up safely:

setsid bash -lc "openclaw foo >/tmp/openclaw-direct-foo.log 2>&1" &
sleep 20
ps -eo pid,ppid,pgid,etime,stat,pcpu,command | awk -v pg="$leader" '$3==pg || $1==pg {print}'

After 20 seconds, the command still had a hot child process:

PID      PPID    PGID    ELAPSED STAT %CPU COMMAND
1104454  1104452 1104454 00:20   Ss    0.0 bash -lc openclaw foo ...
1104481  1104454 1104454 00:19   Sl    0.8 openclaw
1104493  1104481 1104454 00:19   Rl   93.5 openclaw

The command output showed repeated plugin loading before the unknown/unavailable command error:

Config warnings:
- plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts)
Config warnings:
- plugins.entries.opik-openclaw: plugin opik-openclaw: duplicate plugin id detected; global plugin will be overridden by config plugin (/home/claw/opik-openclaw/index.ts)
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
[plugins] loading byteplus from .../dist/extensions/byteplus/index.js
[plugins] loading deepseek from .../dist/extensions/deepseek/index.js
[plugins] loading moonshot from .../dist/extensions/moonshot/index.js
[plugins] loading tencent from .../dist/extensions/tencent/index.js
[plugins] loading volcengine from .../dist/extensions/volcengine/index.js
[plugins] loading xai from .../dist/extensions/xai/index.js
[plugins] loaded 7 plugin(s) (7 attempted) in 434.6ms
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
...
[plugins] loaded 7 plugin(s) (7 attempted) in 31.3ms
[plugins] loading openclaw-honcho from /home/claw/openclaw-honcho/dist/index.js
[plugins] Honcho memory plugin loaded
[plugins] loading opik-openclaw from /home/claw/opik-openclaw/index.ts
[plugins] loading acpx from .../dist/extensions/acpx/index.js
...
[plugins] loading lossless-claw from /home/claw/.openclaw/extensions/lossless-claw/dist/index.js
plugin runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current().
[plugins] loaded 120 plugin(s) (17 attempted) in 4184.6ms
[openclaw] Failed to start CLI: Error: The `openclaw foo` command is unavailable because `plugins.allow` excludes "foo". Add "foo" to `plugins.allow` if you want that bundled plugin CLI surface.

Expected behavior for openclaw foo:

No provider catalog loads.
No runtime plugin load.
No background/hot child process after printing the error.
The error should be a normal unknown-command or unavailable-command response that exits promptly.

Signal note: the operator report is that Ctrl-C/SIGINT does not stop the busy-looping openclaw foo path and SIGKILL is needed. In my controlled repro, SIGINT sent to the entire test process group did stop the tree, so the exact interrupt-resistant variant may depend on how the command is launched. The important reproduced bug is that the invalid command leaves a high-CPU child alive after printing the error; it should not require SIGINT, SIGTERM, or SIGKILL cleanup at all.

Repro: channel logs / provider reloads

From the source checkout:

pnpm openclaw gateway status --deep
pnpm openclaw channels logs --lines 80
journalctl --user -u openclaw-gateway.service --since '10 minutes ago' --no-pager
ps -p $(systemctl --user show openclaw-gateway.service -p MainPID --value) -o pid,ppid,etime,pcpu,pmem,rss,stat,command
pnpm openclaw health --json

openclaw channels logs --lines 80 prints plugin load bursts before showing log lines:

[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
[plugins] loading byteplus from .../dist/extensions/byteplus/index.js
[plugins] loading deepseek from .../dist/extensions/deepseek/index.js
[plugins] loading moonshot from .../dist/extensions/moonshot/index.js
[plugins] loading tencent from .../dist/extensions/tencent/index.js
[plugins] loading volcengine from .../dist/extensions/volcengine/index.js
[plugins] loading xai from .../dist/extensions/xai/index.js
[plugins] loaded 7 plugin(s) (7 attempted) in 565.2ms
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
...
[plugins] loaded 7 plugin(s) (7 attempted) in 92.8ms

Earlier in the same current-generation gateway journal, model/session surfaces triggered much larger provider-plugin reload bursts:

[plugins] loading amazon-bedrock from .../dist/extensions/amazon-bedrock/index.js
[plugins] loading amazon-bedrock-mantle from .../dist/extensions/amazon-bedrock-mantle/index.js
[plugins] loading anthropic from .../dist/extensions/anthropic/index.js
[plugins] loading anthropic-vertex from .../dist/extensions/anthropic-vertex/index.js
...
[plugins] loading zai from .../dist/extensions/zai/index.js
[plugins] loaded 49 plugin(s) (49 attempted) in 1422.3ms
[ws] ⇄ res ✓ models.list 18353ms ...
[ws] ⇄ res ✓ models.list 7590ms ...

sessions.list also showed catalog pressure:

[gateway] sessions.list continuing without model catalog after 750ms
[ws] ⇄ res ✓ sessions.list 10155ms ...

Runtime impact observed

The gateway process stayed hot even with no active agent run:

PID       ELAPSED %CPU %MEM   RSS STAT COMMAND
1101846   07:12  61.8  5.4  892284 Rsl  node dist/index.js gateway --port 18789

Short top samples showed the process around 70-86% CPU.

Gateway diagnostics reported event-loop degradation while active/waiting/queued work was zero:

[diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=30s eventLoopDelayP99Ms=2457.9 eventLoopDelayMaxMs=5469.4 eventLoopUtilization=1 cpuCoreRatio=0.921 active=0 waiting=0 queued=0
[diagnostic] liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=1270.9 eventLoopDelayMaxMs=1598 eventLoopUtilization=0.94 cpuCoreRatio=0.818 active=0 waiting=0 queued=0

At the same time, two Control UI clients were repeatedly polling node.list, each response taking over a second and sometimes over three seconds:

[ws] ⇄ res ✓ node.list 1480ms conn=...
[ws] ⇄ res ✓ node.list 1423ms conn=...
[ws] ⇄ res ✓ node.list 3535ms conn=...
[ws] ⇄ res ✓ node.list 3538ms conn=...
[ws] ⇄ res ✓ node.list 2026ms conn=...
[ws] ⇄ res ✓ node.list 2058ms conn=...

A health probe still eventually returned ok: true, but took ~10s:

pnpm openclaw health --json
# durationMs: 10282
# plugins.errors: []
# channels signal/telegram/whatsapp running, whatsapp healthy/linked

Expected behavior

Unknown or unavailable CLI commands should fail before provider/plugin runtime loading.
Invalid CLI commands should not leave hot child processes alive.
channels logs should not require loading provider/model plugins just to print recent channel logs.
models.list / sessions.list / Control UI polling should not repeatedly cold-load all provider plugins on the gateway hot path.
Repeated UI polling should not be able to keep the main gateway loop at ~60-80% CPU when no agent run is active.
Event-loop delay should stay low enough for gateway health/readiness and channel handling to remain responsive.

Troubleshooting notes

This was reproduced after a fresh source install/update and gateway restart.
The configured channels remained healthy, so this is not a simple channel crash loop.
There is a duplicate Opik plugin warning in this environment because config intentionally overrides the global Opik plugin with a local checkout; that warning is present but does not explain the provider catalog reload bursts across model providers or the openclaw foo hot child.
Killing a long-running local channels logs command stopped that CLI process, but the gateway process remained CPU hot due to ongoing Control UI node.list polling and event-loop degradation.

Suspected area

Check CLI dispatch and provider/plugin catalog loading for:

command validation happening after plugin discovery/runtime initialization,
plugin CLI fallback treating arbitrary words like possible plugin commands before checking allowlists/known command tables,
child process lifecycle cleanup after CLI startup errors,
missing request-level or process-level memoization of provider plugin catalog loads,
expensive plugin loader calls inside models.list, sessions.list, or log/status commands,
duplicated Control UI polling across multiple clients/tabs,
synchronous work on the gateway main loop during catalog/provider discovery.

extent analysis

TL;DR

The issue can be mitigated by optimizing CLI dispatch and provider/plugin catalog loading to prevent unnecessary plugin loading and child process creation for invalid commands.

Guidance

Review the CLI dispatch logic to ensure command validation occurs before plugin discovery and runtime initialization.
Implement request-level or process-level memoization of provider plugin catalog loads to prevent repeated loading of plugins.
Optimize models.list, sessions.list, and log/status commands to reduce expensive plugin loader calls.
Investigate and limit duplicated Control UI polling across multiple clients/tabs to prevent excessive CPU usage.
Consider introducing asynchronous processing for catalog/provider discovery to prevent blocking the gateway main loop.

Example

No specific code example is provided due to the complexity of the issue and the need for a thorough review of the codebase.

Notes

The root cause of the issue appears to be related to the CLI dispatch and provider/plugin catalog loading mechanisms. The provided information suggests that invalid commands are triggering expensive plugin loading and child process creation, leading to high CPU usage and event-loop degradation.

Recommendation

Apply workaround: Optimize CLI dispatch and provider/plugin catalog loading to prevent unnecessary plugin loading and child process creation for invalid commands. This can be achieved by implementing request-level or process-level memoization of provider plugin catalog loads and optimizing expensive plugin loader calls.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

Unknown or unavailable CLI commands should fail before provider/plugin runtime loading.
Invalid CLI commands should not leave hot child processes alive.
channels logs should not require loading provider/model plugins just to print recent channel logs.
models.list / sessions.list / Control UI polling should not repeatedly cold-load all provider plugins on the gateway hot path.
Repeated UI polling should not be able to keep the main gateway loop at ~60-80% CPU when no agent run is active.
Event-loop delay should stay low enough for gateway health/readiness and channel handling to remain responsive.

#ssr #cache issue #memory leak #API versioning #request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix Unknown CLI commands load plugins and leave hot child process while gateway saturates [1 pull requests, 4 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #75326: perf: keep models list responsive during catalog discovery

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Changed files

Code Example

Summary

Environment

Repro: non-existent CLI command

Repro: channel logs / provider reloads

Runtime impact observed

Expected behavior

Troubleshooting notes

Suspected area

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING