openclaw - 💡(How to fix) Fix [Bug]: Each plugin extension manifest read 100+ times per request → 60s prep stages [8 comments, 7 participants]

Q: Expected behavior

Plugin extension manifests (dist/extensions/*/openclaw.plugin.json) parsed once at gateway startup, kept in memory embedded-run prep stages complete in <2s on idle daemon Idle minimal install: simple "hi" message answered in 5–10 seconds (matches docs/community baseline of 2–5s for simple messages)

openclaw2026-05-01 10:34:29

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#75591•Fetched 2026-05-02 05:32:58

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

cross-referenced ×16commented ×8subscribed ×3labeled ×2

Setup: OpenClaw 2026.4.29 npm global, Hetzner CX33 (4 vCPU, 8GB), 1 channel (telegram), 0 hooks, idle daemon.

Symptom: Every embedded-run takes 90-180s before first token. Single-word "hi" message → 1m53s consistently.

trace:embedded-run prep stages (consistent across requests):

core-plugin-tools: 17s system-prompt: 18s stream-setup: 18s Diagnosis via strace -c -f (during one request):

93.93% / 137s futex 2,833 calls ← worker thread contention 4.04% / 5.9s statx 103,096 calls 0.51% / 0.7s access 11,825 calls 0.40% / 0.6s openat 7,719 calls strace -e openat reveals each dist/extensions/*/openclaw.plugin.json is opened ~105 times per request:

108 dist/extensions/telegram/openclaw.plugin.json 106 dist/extensions/feishu/openclaw.plugin.json 106 dist/extensions/discord/openclaw.plugin.json 106 dist/extensions/bluebubbles/openclaw.plugin.json ... (24+ extensions, each opened 105-108 times) 127 openclaw/package.json 127 openclaw/dist/package.json (ENOENT, retried each time) Total: 18,852 openat per request in ~/.npm-global/lib/node_modules/openclaw/.

This appears to be an O(N×M) loop where N items × M extensions = 7,500 redundant manifest reads. Combined with futex contention from worker threads serializing on these sync reads, each prep stage (core-plugin-tools, system-prompt, stream-setup) pays ~17s.

Expected: Plugin manifests parsed once at gateway startup, kept in memory. Per-request prep should be <2s on idle daemon.

Tried (none helped): tools.profile=messaging, hooks disabled, fresh sessions, NODE_COMPILE_CACHE, NODE_OPTIONS=--dns-result-order=ipv4first, sessions wipe, daemon install --force, OPENCLAW_NO_RESPAWN=1. Confirmed loadModelCatalog cache works correctly (only logs first request).

Reproducer: any minimal install on Linux. OPENCLAW_DEBUG_INGRESS_TIMING=1 openclaw agent --message "hi" shows the prep stages; strace -e openat -p $(pgrep -f openclaw-gateway) during a request shows the redundant reads.

Root Cause

Setup: OpenClaw 2026.4.29 npm global, Hetzner CX33 (4 vCPU, 8GB), 1 channel (telegram), 0 hooks, idle daemon.

Symptom: Every embedded-run takes 90-180s before first token. Single-word "hi" message → 1m53s consistently.

trace:embedded-run prep stages (consistent across requests):

core-plugin-tools: 17s system-prompt: 18s stream-setup: 18s Diagnosis via strace -c -f (during one request):

Expected: Plugin manifests parsed once at gateway startup, kept in memory. Per-request prep should be <2s on idle daemon.

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Summary

Setup: OpenClaw 2026.4.29 npm global, Hetzner CX33 (4 vCPU, 8GB), 1 channel (telegram), 0 hooks, idle daemon.

Symptom: Every embedded-run takes 90-180s before first token. Single-word "hi" message → 1m53s consistently.

trace:embedded-run prep stages (consistent across requests):

core-plugin-tools: 17s system-prompt: 18s stream-setup: 18s Diagnosis via strace -c -f (during one request):

Expected: Plugin manifests parsed once at gateway startup, kept in memory. Per-request prep should be <2s on idle daemon.

Steps to reproduce

1 Install OpenClaw 2026.4.29 globally via npm on a clean Linux VM 2 Run openclaw onboard with minimal config: 1 provider (anthropic), 1 channel (telegram), no hooks, no custom plugins 3 Set tools.profile: "messaging" and channels.telegram.streaming: "off" 4 Start the gateway as a systemd user service 5 Send a single short message via openclaw agent --agent main --message "hi" (or via the Telegram bot) 6 Measure end-to-end latency and the embedded-run trace stages 7 Run strace -c -f -p $(systemctl --user show openclaw-gateway -p MainPID --value) during the request to capture syscall summary 8 Run strace -e openat -f -p $PID during a separate request to capture file access patterns

Expected behavior

Plugin extension manifests (dist/extensions/*/openclaw.plugin.json) parsed once at gateway startup, kept in memory embedded-run prep stages complete in <2s on idle daemon Idle minimal install: simple "hi" message answered in 5–10 seconds (matches docs/community baseline of 2–5s for simple messages)

Actual behavior

Every request takes 90–180 seconds before first token. Single-word "hi" → 1m 53s consistently across 6+ measurements

trace:embedded-run prep stages on every request:

core-plugin-tools: ~17s system-prompt: ~18s stream-setup: ~18s session-resource-loader: ~3.7s

strace -c -f during one request:

93.93% / 137s futex 2,833 calls (worker thread contention) 4.04% / 5.9s statx 103,096 calls 0.51% / 0.7s access 11,825 calls 0.40% / 0.6s openat 7,719 calls

strace -e openat shows each dist/extensions/*/openclaw.plugin.json opened ~105 times per request (telegram 108, feishu/discord/bluebubbles 106, 20+ others at 105). openclaw/package.json opened 127 times. openclaw/dist/package.json opened 127 times all returning ENOENT.
Total: 18,852 openat calls per request, 99% in ~/.npm-global/lib/node_modules/openclaw/. This is an O(N×M) loop (~105 items × ~70 extensions) re-reading the same manifests.
Tried with no effect: tools.profile=messaging, hooks disabled, fresh sessions, full sessions wipe, NODE_COMPILE_CACHE, NODE_OPTIONS=--dns-result-order=ipv4first, OPENCLAW_NO_RESPAWN=1, daemon install --force after npm update. Confirmed loadModelCatalog cache works correctly (only logs first request via OPENCLAW_DEBUG_INGRESS_TIMING=1).

OpenClaw version

2026.4.29 (a448042)

Operating system

Ubuntu 24.04.4 LTS (Hetzner Cloud CX33, 4 vCPU / 8 GB RAM / NVMe SSD, Helsinki)

Install method

npm global (npm install -g [email protected]), running as systemd user service (openclaw-gateway.service) via openclaw daemon install --force

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

openclaw → anthropic (direct API, no gateway/router/proxy)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue can be fixed by optimizing the plugin manifest parsing to avoid redundant reads, potentially by caching the manifests in memory at gateway startup.

Guidance

Investigate the OpenClaw gateway startup process to determine why plugin manifests are not being cached in memory as expected.
Review the code responsible for parsing plugin manifests to identify the O(N×M) loop causing redundant reads.
Consider implementing a caching mechanism to store plugin manifests in memory after initial parsing, reducing the need for repeated file access.
Use the strace tool to monitor file access patterns and verify the effectiveness of any optimizations.

Example

No code snippet is provided as the issue description does not include specific code references. However, the optimization might involve modifying the plugin loading mechanism to cache manifests, similar to:

// Pseudo-code example, actual implementation may vary
const pluginManifests = {};

// Cache plugin manifests at gateway startup
function loadPluginManifests() {
  // ...
  pluginManifests[pluginName] = manifest;
}

// Use cached manifests during requests
function getPluginManifest(pluginName) {
  return pluginManifests[pluginName];
}

Notes

The provided information suggests an issue with the OpenClaw gateway's plugin loading mechanism, but without access to the codebase, it's challenging to provide a precise solution. The proposed fix assumes that caching plugin manifests in memory will alleviate the redundant read issue.

Recommendation

Apply a workaround by optimizing the plugin manifest parsing and caching mechanism, as the root cause appears to be related to the gateway's internal implementation rather than a version-specific issue.

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

#api #model loading #dependency error #configuration error #environment variable

Still need to ship something?

×6

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

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix [Bug]: Each plugin extension manifest read 100+ times per request → 60s prep stages [8 comments, 7 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Bug type

Beta release blocker

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Each plugin extension manifest read 100+ times per request → 60s prep stages [8 comments, 7 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Bug type

Beta release blocker

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING