Summary
In runEmbeddedAttempt, the prep stage core-plugin-tools consistently takes ~10–12 s on every embedded run, dominating startup latency. The cost is paid even when the plugin registry is fully cached (no manifest scan), so it's not a discovery/IO cost — it's coming from per-run plugin tool factory invocations.
Subagent runs that pass disablePluginTools: true (e.g. skill-workshop-review) take ~0 ms in the same stage, which isolates the cost squarely to plugin tool resolution.
Running v2026.4.27. The cold persisted registry change in v2026.4.25 (per CHANGELOG) helped manifest scans but did not affect this per-run cost.
Reproducible trace
[trace:embedded-run] prep stages lines from ~/.openclaw/logs over a few hours, six agents, single gateway process:
core-plugin-tools:11675ms@13819ms totalMs=48374
core-plugin-tools:11891ms@11899ms totalMs=20845
core-plugin-tools:11153ms@11510ms totalMs=21709
core-plugin-tools:11963ms@12732ms totalMs=22326
core-plugin-tools:11643ms@11648ms totalMs=20972
core-plugin-tools:11682ms@13445ms totalMs=27994
core-plugin-tools:11891ms@11897ms totalMs=48471
core-plugin-tools:11901ms@13514ms totalMs=31357
core-plugin-tools:11103ms@12708ms totalMs=42552
core-plugin-tools:10691ms@12258ms totalMs=47577
core-plugin-tools:11153ms@12827ms totalMs=47542
core-plugin-tools:11212ms@11220ms totalMs=21667
core-plugin-tools:12753ms@14439ms totalMs=51442
core-plugin-tools:12958ms@13014ms totalMs=24531
core-plugin-tools:11699ms@13794ms totalMs=52099
core-plugin-tools:12261ms@13810ms totalMs=58969
core-plugin-tools:11993ms@13831ms totalMs=32672
core-plugin-tools:11911ms@13671ms totalMs=55732
core-plugin-tools:12330ms@14310ms totalMs=57267
core-plugin-tools:11572ms@11758ms totalMs=43813
core-plugin-tools:11768ms@11824ms totalMs=26290
core-plugin-tools:11808ms@11816ms totalMs=20907
core-plugin-tools:11363ms@13310ms totalMs=48191
core-plugin-tools:10828ms@10834ms totalMs=45231
core-plugin-tools:11671ms@13261ms totalMs=44933
core-plugin-tools:11444ms@13069ms totalMs=30574
core-plugin-tools:11974ms@11986ms totalMs=20772
core-plugin-tools:11600ms@13016ms totalMs=34062
Compare to the same field on a skill-workshop-review subagent run (which passes disablePluginTools: true):
core-plugin-tools:0ms@207ms totalMs=10468
core-plugin-tools:1ms@379ms totalMs=15345
i.e. the entire core-plugin-tools cost vanishes when plugin tool resolution is skipped.
What I traced in the bundle
In dist/selection-O4IbJwaT.js the core-plugin-tools mark wraps a single expression:
toolsRaw = applyEmbeddedAttemptToolsAllow(createOpenClawCodingTools({...}))
Inside createOpenClawCodingTools (dist/pi-tools-BS_IGzoH.js):
- Build core coding tools (read/write/edit/exec/applyPatch) — millisecond range.
- Call
createOpenClawTools (dist/openclaw-tools-BnZyM43Q.js) which instantiates ~15 native tools (canvas, cron, message, tts, image-generate, music-generate, video-generate, gateway, sessions-list/history/send/spawn/yield, agents-list, web-search, web-fetch, image, pdf). Each factory is light.
- Call
resolvePluginTools (dist/tools-B9flTjj3.js), which iterates the cached registry and invokes entry.factory(params.context) for every plugin tool, every run.
The third step is the suspect. The registry itself is cached by cacheKey (dist/loader-SnjzoVJ_.js:3490), but the entry.factory calls are not — they receive params.context (sandbox / sessionKey / workspaceDir / delivery context) which legitimately varies per run, but the body of those factories appears to do enough fixed work to add up to ~11 s consistently.
The constancy (always 10.7–13.0 s, never lower, never much higher) suggests the cost is fixed per run rather than scaling with plugin count or workspace size.
Setup
- 13 plugins in
plugins.allow: acpx, brave, google, llm-router-sync, mattermost, memory-core, memory-wiki, minimax, openrouter, skill-workshop, telegram, webhooks, zai
- Of those, 7 are
onStartup: true (acpx, mattermost, memory-core, memory-wiki, skill-workshop, telegram, webhooks)
- 6 active agents, one shared gateway process
- 122 bundled extensions in
dist/extensions/
Asks
- Is this expected on
v2026.4.27, or is there a regression vs. earlier versions?
- Are factory results memoizable per
(pluginId, sandboxKey) to amortize across runs that share workspace?
- Is there a config knob to opt agents out of plugin tools (the equivalent of
disablePluginTools: true exposed at the agent or run level), for agents/sessions that don't need plugin tools?
- Could
core-plugin-tools be split into per-plugin sub-marks so we can tell which plugin's factory is the heaviest?
Happy to run more traces / patch a debug build if useful.
Summary
In
runEmbeddedAttempt, the prep stagecore-plugin-toolsconsistently takes ~10–12 s on every embedded run, dominating startup latency. The cost is paid even when the plugin registry is fully cached (no manifest scan), so it's not a discovery/IO cost — it's coming from per-run plugin tool factory invocations.Subagent runs that pass
disablePluginTools: true(e.g.skill-workshop-review) take ~0 ms in the same stage, which isolates the cost squarely to plugin tool resolution.Running
v2026.4.27. The cold persisted registry change inv2026.4.25(per CHANGELOG) helped manifest scans but did not affect this per-run cost.Reproducible trace
[trace:embedded-run] prep stageslines from~/.openclaw/logsover a few hours, six agents, single gateway process:Compare to the same field on a
skill-workshop-reviewsubagent run (which passesdisablePluginTools: true):i.e. the entire
core-plugin-toolscost vanishes when plugin tool resolution is skipped.What I traced in the bundle
In
dist/selection-O4IbJwaT.jsthecore-plugin-toolsmark wraps a single expression:Inside
createOpenClawCodingTools(dist/pi-tools-BS_IGzoH.js):createOpenClawTools(dist/openclaw-tools-BnZyM43Q.js) which instantiates ~15 native tools (canvas, cron, message, tts, image-generate, music-generate, video-generate, gateway, sessions-list/history/send/spawn/yield, agents-list, web-search, web-fetch, image, pdf). Each factory is light.resolvePluginTools(dist/tools-B9flTjj3.js), which iterates the cached registry and invokesentry.factory(params.context)for every plugin tool, every run.The third step is the suspect. The registry itself is cached by
cacheKey(dist/loader-SnjzoVJ_.js:3490), but theentry.factorycalls are not — they receiveparams.context(sandbox / sessionKey / workspaceDir / delivery context) which legitimately varies per run, but the body of those factories appears to do enough fixed work to add up to ~11 s consistently.The constancy (always 10.7–13.0 s, never lower, never much higher) suggests the cost is fixed per run rather than scaling with plugin count or workspace size.
Setup
plugins.allow:acpx, brave, google, llm-router-sync, mattermost, memory-core, memory-wiki, minimax, openrouter, skill-workshop, telegram, webhooks, zaionStartup: true(acpx, mattermost, memory-core, memory-wiki, skill-workshop, telegram, webhooks)dist/extensions/Asks
v2026.4.27, or is there a regression vs. earlier versions?(pluginId, sandboxKey)to amortize across runs that share workspace?disablePluginTools: trueexposed at the agent or run level), for agents/sessions that don't need plugin tools?core-plugin-toolsbe split into per-plugin sub-marks so we can tell which plugin's factory is the heaviest?Happy to run more traces / patch a debug build if useful.