OpenClaw merged PR #168313, a Windows Gateway startup fix for machines with installed plugins.
The regression was serious enough to block release validation for 2026.10.5-beta.1. According to the PR, Windows installer-fresh lanes were timing out because plugin source capture could spend minutes copying installed plugin files before the Gateway bound its port. Affected candidates included 2026.10.1 and 2026.10.5-beta.1.
What Changed
The slowdown came from a guarded clone path introduced during plugin source capture hardening. On Windows, that guarded clone skips native copies and path-admission caching, making it much slower for ordinary plugin files. With installed plugins present, the startup path could stretch from a normal startup into a multi-minute wait.
OpenClaw now uses the existing pinned-descriptor copy path again for small ordinary files on Windows. Large files and native files still keep the guarded clone path, preserving the safety boundary where it matters most.
The PR also moves the small-copy guard tests onto Windows, so the intended behavior is covered on the platform that regressed.
Why It Matters
Gateway startup is one of the few flows where a performance bug can feel like a total outage. If the process has not bound yet, the user does not see a slightly slower feature; they see OpenClaw failing to start, reconnect, or pass release checks.
This fix matters most for Windows users who install plugins and then rely on OpenClaw to recover cleanly after updates, restarts, or fresh installs. The PR reports affected candidates taking four to ten minutes to bind, while passing runs bind in about 42 seconds.
That difference is not cosmetic. It decides whether the release lane sees a working Gateway or a timeout.
Release Context
PR #168313 is a forward-port to main of an equivalent fix that already landed on the release/2026.10.1 branch in PR #168256. That matters because the release branch had already proven the same shape of repair, while main still carried the regression.
The user-facing impact is intentionally narrow:
- Windows Gateways with installed plugins start without multi-minute source-capture stalls.
- Small ordinary plugin files use the faster pinned-descriptor copy path.
- Large and native files retain guarded clone behavior.
- No schema, configuration, or plugin manifest change is involved.
Evidence From The PR
The PR cites the failing cross-OS installer-fresh release lane and identifies the last known passing run. It also reports a local macOS pass for src/plugins/plugin-source-file.copy.test.ts, while the Windows proof comes from CI and the release-validation lane after the backport.
Because the issue was platform-specific, that Windows release-lane evidence is the important part. The fix is not a broad plugin rewrite; it restores the correct copy strategy for the Windows startup case that broke.
Bottom Line
PR #168313 removes a release-blocking Windows startup stall for plugin-heavy OpenClaw installs. For users, the visible result should be simple: the Gateway gets back to binding promptly instead of disappearing into minutes of plugin file capture.