Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

During gateway startup on Windows, the plugin discovery phase spends ~20 minutes repeatedly calling fs.realpathSync (via safeRealpathSync) to resolve paths under ~/.openclaw/extensions and bundled plugin directories, making the chat page initialization extremely slow.

Steps to reproduce

Install OpenClaw 2026.4.12-beta.1 globally via npm on Windows 10: npm install -g openclaw Start the OpenClaw gateway Open the chat page and connect to the gateway Observe ~20 minutes of initialization delay Debug in Node.js debugger and pause — call stack shows:

safeRealpathSync (path-safety.ts:14) → fs.realpathSync addCandidate (discovery.ts:427) discoverInDirectory (discovery.ts:576) discoverOpenClawPlugins (discovery.ts:942) loadPluginManifestRegistry (manifest-registry.ts:491) resolvePluginAutoEnableCandidates detectPluginAutoEnableCandidates applyPluginAutoEnable resolvePluginActivationSnapshot resolveBundledPluginCompatibleActivationInputs ...

Expected behavior

Plugin discovery should complete within seconds, similar to Linux/macOS. The gateway should be ready to accept chat connections shortly after startup.

Actual behavior

Initialization takes ~20 minutes. The debugger shows the bottleneck is safeRealpathSync in src/plugins/path-safety.ts:14, which calls fs.realpathSync for every file and directory encountered during recursive plugin discovery. On Windows, fs.realpathSync appears to be very slow when traversing the npm global install directory.

OpenClaw version

2026.4.12-beta.1

Operating system

Windows 10 Home 10.0.19045

Install method

npm global (D:\npm-global\node_modules\openclaw)

Model

local

Provider / routing chain

whalecloud/LOCAL/Qwen3.5-122B-A10B

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Logs, screenshots, and evidence
Debug call stack (captured via Node.js debugger during initialization):


safeRealpathSync          VM168 ... :282  (path-safety.ts:14 → fs.realpathSync)
addCandidate              VM168 ... :528  (discovery.ts:427)
discoverInDirectory       VM168 ... :691  (discovery.ts:576)
discoverOpenClawPlugins   VM168 ... :912  (discovery.ts:942)
loadPluginManifestRegistry manifest-registry.ts:489
resolvePluginAutoEnableCandidates plugin-auto-enable.detect.ts
detectPluginAutoEnableCandidates plugin-auto-enable.detect.ts
applyPluginAutoEnable     plugin-auto-enable.apply.ts
resolvePluginActivationSnapshot plugin-auto-enable.prefer-over.ts
resolveBundledPluginCompatibleActivationInputs ...
The targetPath being resolved at the breakpoint was:
D:\npm-global\node_modules\openclaw\dist\extensions\xai

Root cause analysis:

discoverOpenClawPlugins recursively scans three directories: stock (bundled), global (~/.openclaw/extensions), and workspace (.openclaw/extensions)
For each directory entry, addCandidate calls safeRealpathSync on the rootDir parameter
safeRealpathSync has a per-call cache parameter that is shared within loadPluginManifestRegistry (see manifest-registry.ts:501), but this cache is NOT shared during the discoverOpenClawPlugins phase
discoverOpenClawPlugins calls safeRealpathSync at multiple points (lines 146, 147, 339, 340, 427, 576) without passing any shared cache — each call resolves the realpath independently
On Windows, fs.realpathSync is significantly slower than on Unix, especially for paths under npm global directories

Impact and severity

Affected: All OpenClaw users on Windows using npm global install Severity: High — renders the chat UI nearly unusable (20 min wait per startup/reload) Frequency: Always on Windows with this install method Consequence: Users must wait ~20 minutes for gateway initialization before they can interact with the chat interface

Additional information

There is no configuration option to skip or disable the plugin discovery phase. plugins.enabled: false in config only prevents plugin loading, not discovery — the discovery runs before the plugins.enabled check. Environment variables like OPENCLAW_PLUGIN_DISCOVERY_CACHE_MS only control the short TTL cache (default 1 second) for collapsing bursty repeated discovery calls, but do not help with the initial slow fs.realpathSync calls during the first discovery run.

Potential fix direction: consider sharing the realpath cache between discoverOpenClawPlugins and loadPluginManifestRegistry, or skip realpathSync for bundled plugin paths that are known to be safe and don't contain symlinks.