Best possible solution:

Land the asynchronous Discord startup probe and SDK-alias loader preservation after the remaining exact-head check completes and maintainer review is satisfied.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection on current main shows Discord startup awaits the 2.5s /users/@me probe before starting monitorDiscordProvider, matching the related WSL2 timeout report even though I did not live-test WSL2.

Is this the best way to solve the issue?

Yes, with validation still pending. Moving only the enrichment probe off the startup path is the narrow maintainable fix for the reported startup blocking, and the latest loader alias change appears targeted at preserving existing plugin load contracts.

What I checked:

• Current main blocks before monitor startup: Discord startAccount awaits probeDiscord(token, 2500, { includeApplication: true }) before calling monitorDiscordProvider, so a slow /users/@me probe can delay channel startup. (extensions/discord/src/channel.ts:556, 86fc9e3279d1)
• Probe uses the reported REST path: probeDiscord calls fetchWithTimeout for ${DISCORD_API_BASE}/users/@me with the caller-supplied timeout. (extensions/discord/src/probe.ts:145, 86fc9e3279d1)
• PR moves probe off the critical path: The PR adds startDiscordStartupProbe and calls it without awaiting before monitorDiscordProvider, while still setting bot/application status when the probe resolves. (extensions/discord/src/channel.ts:82, 66a28696bf2c)
• Regression coverage added: The PR adds a test where the startup probe promise remains pending while monitorDiscordProvider is still called, then verifies later status enrichment after the probe resolves. (extensions/discord/src/channel.test.ts:423, 66a28696bf2c)
• Loader alias follow-up present: The latest PR head adds SDK import detection in plugin-module-loader-cache.ts so JS targets importing openclaw/plugin-sdk can route through the source-transform alias path instead of native require. (src/plugins/plugin-module-loader-cache.ts:48, 66a28696bf2c)
• Exact-head check status: At the latest read-only status query, check-runs for head 66a2869 showed 81 successful, 1 neutral, 17 skipped, and 1 still in progress on the first page; page 2 had no blocking failure output. (66a28696bf2c)

Likely related people:

• steipete: Current-main blame/log show Peter Steinberger on the Discord startup path and the recent native plugin-loader fast path that this PR adjusts; GitHub commit metadata maps those commits to steipete. (role: recent Discord and plugin-loader maintainer; confidence: high; commits: 1a573d33bc78, 705bde459471, e420592bdfd9; files: extensions/discord/src/channel.ts, extensions/discord/src/probe.ts, src/plugins/plugin-module-loader-cache.ts)
• scoootscooob: Commit 5682ec37fada moved the Discord implementation into extensions/discord/src, so this is relevant background ownership for the channel boundary. (role: historical Discord migration owner; confidence: low; commits: 5682ec37fada; files: extensions/discord/src/channel.ts, extensions/discord/src/probe.ts)

Remaining risk / open question:

• The WSL2/undici timeout behavior from the related report was not live-verified in this read-only review.
• One exact-head Windows Node test check was still in progress at the latest status query.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 86fc9e3279d1.