openclaw - 💡(How to fix) Fix [Bug]: Windows plugin TS source-loading via jiti is pathologically slow in real production call sites [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On Windows, the current synchronous jiti-based plugin loading path for TypeScript source entries is pathologically slow in real production call sites, while an async native-import TS-aware path reproduces successful loading with dramatically lower latency.

Steps to reproduce

1. Run OpenClaw on Windows with a real production call site that loads TypeScript source plugins through the current synchronous plugin loader path.
2. Trigger plugin loading from a production path such as CLI plugin registration, plugin status/inspect, gateway plugin bootstrap, or a cold async caller using a core registry.
3. Observe that plugin import enters the jiti-based path and takes seconds to minutes for some plugins on Windows.
4. Compare against an experimental async native-import TS-aware path on the same caller and observe the same plugins loading successfully with dramatically lower latency.

Expected behavior

Plugin loading from real production call sites on Windows should complete without pathological latency. TypeScript source plugins should load within a reasonable startup/import time envelope, and the same production callers should not require minutes to complete plugin bootstrap.

Actual behavior

On Windows, real production call sites that load TypeScript source plugins through the current synchronous jiti-based loader path show pathological latency. In the measured cases, plugin import commonly took from several seconds to several minutes depending on the plugin and caller, while equivalent experimental async native-import TS-aware paths loaded the same plugins successfully with dramatically lower latency.

OpenClaw version

2026.3.26

Operating system

Windows 11 Home

Install method

Local source checkout / dev runtime on Windows

Model

NOT_ENOUGH_INFO

Provider / routing chain

This issue was investigated in plugin loading/bootstrap paths on Windows and does not appear to depend on a specific model/provider configuration.

Additional provider/model setup details

This issue was reproduced in Windows plugin-loading/bootstrap paths and does not appear to depend on a specific model/provider setup. The bottleneck is in the synchronous jiti-based plugin source-loading path for TypeScript source entries.

Logs, screenshots, and evidence

Observed on Windows across multiple real production call sites.

Grounded findings:
- The current synchronous jiti-based plugin loader path for TypeScript source entries is pathologically slow on Windows.
- An experimental async native-import TS-aware path loaded the same plugins successfully with dramatically lower latency in the same real call sites.
- The issue was reproduced in real production paths, not only in isolated harnesses.

Real call sites validated:
- CLI plugin command registration
- plugin status / inspect
- gateway startup plugin bootstrap
- CLI plugin registry preload
- HTTP tools path
- TTS path
- media-understanding path

Representative timings observed on Windows:
- browser: ~14s–26s with jiti vs ~0.2s–1.1s with native-import
- diagnostics-otel: ~7s–12s with jiti vs ~0.5s–1.5s with native-import
- anthropic: ~281s with jiti vs ~0.17s–1.1s with native-import
- memory-core: ~279s–297s with jiti vs ~0.3s–1.2s with native-import

What was ruled out during investigation:
- not plugin discovery
- not manifest resolution
- not register phase
- not general plugin compatibility
- not cache/activate/registry behavior in the async experiments

Important diagnostic note:
- `require(...)` was tested during diagnosis and reduced latency, but exposed import-vs-require conditional exports mismatches and is not the right direction
- native `import()` under a TS-aware runtime reproduced successful loading without those require-specific failures

Conclusion:
The pathological latency is concentrated in the current synchronous jiti-based TS source-loading path on Windows. A parallel async loader path using native `import()` is a viable direction and was validated across multiple real production call sites.

Impact and severity

Affected: Windows users loading TypeScript source plugins through real production plugin bootstrap/call sites. Severity: High for affected Windows setups, because plugin bootstrap/import can take from several seconds to several minutes in real production paths. Frequency: Reproduced consistently in the measured Windows call sites during investigation. Consequence: Severe startup/import latency in plugin bootstrap paths, degraded responsiveness, and in some measured paths plugin loading cost large enough to make production flows impractical.

Additional information

This issue is not filed as a regression because I do not have grounded evidence for a last-known-good version for this specific behavior.

The investigation ruled out discovery, manifest resolution, register phase, and general plugin compatibility as the primary cause in the measured paths. The bottleneck is concentrated in the current synchronous jiti-based TS source-loading path on Windows.

A parallel async native-import TS-aware path was validated successfully in multiple real production call sites and core registries, while preserving successful plugin loading with much lower latency.