openclaw - 💡(How to fix) Fix OpenClaw 2026.5.7 regressions: Weixin runtime race, undici Content-Length failure, Codex Computer Use marketplace registration

Summary

After updating to OpenClaw 2026.5.7, two regressions showed up in the external openclaw-weixin channel plugin and one Codex Computer Use setup sharp edge surfaced in isolated Codex homes.

Environment observed:

• OpenClaw: 2026.5.7 (eeef486)
• macOS: Darwin 25.4.0 arm64
• Node: 24.15.0
• Channel plugin: local external openclaw-weixin long-poll plugin
• Codex CLI: /Applications/Codex.app/Contents/Resources/codex, codex-cli 0.128.0-alpha.1

Issue 1: external Weixin channel monitor can fail with Weixin runtime initialization timeout

Symptoms

After gateway restart / update, both configured Weixin accounts repeatedly failed to start:

openclaw-weixin <account>: enabled, configured, stopped, health:not-running, error:Weixin runtime initialization timeout

The gateway log showed repeated provider auto-restarts and the monitor waiting for the plugin runtime.

Local root cause / workaround

The monitor path was relying on a module-global plugin runtime initialized from register(api). In this runtime path, ChannelGatewayContext already provides ctx.channelRuntime, but the monitor was not using that startup-safe runtime surface, so it could race/fail waiting for the module-global runtime.

Local patch that fixed startup:

• pass ctx.channelRuntime from gateway.startAccount() into monitorWeixinProvider()
• in the monitor, prefer the provided channelRuntime and only fall back to the module-global runtime/wait path for legacy hosts

After restart, both Weixin accounts changed from stopped / runtime initialization timeout to running.

Expected behavior

External channel plugins should be able to reliably use the ChannelGatewayContext.channelRuntime surface during provider startup, and plugin examples/docs should discourage depending on a module-global runtime when ctx.channelRuntime is available.

Issue 2: Node/undici rejects manually supplied Content-Length in plugin-hosted fetch

Symptoms

Once the Weixin monitor started, getUpdates failed with:

TypeError: fetch failed
cause: InvalidArgumentError: invalid content-length header
code: UND_ERR_INVALID_ARG

The request had a manually computed Content-Length header even though the body byte count matched. A direct Node fetch without manually setting Content-Length succeeded.

Local root cause / workaround

The plugin API wrapper built POST headers like JSON + auth headers + manual Content-Length. In the OpenClaw plugin-hosted Node/undici fetch path this can throw UND_ERR_INVALID_ARG invalid content-length header.

Local patch that fixed API calls:

• remove manual Content-Length from buildHeaders()
• let Node/undici compute it

After patching, both Weixin accounts successfully called getUpdates.

Expected behavior

OpenClaw channel/plugin examples should avoid manually setting Content-Length for fetch() bodies in Node/undici unless absolutely required, and openclaw-weixin should let the runtime compute it.

Issue 3: Codex Computer Use can be cached/enabled but still marketplace_missing in an isolated Codex home

Symptoms

The Computer Use plugin files were present under the isolated Codex home cache and config had:

[plugins.\"computer-use@openai-bundled\"]
enabled = true

But the Codex plugin status check returned:

{
  \"ready\": false,
  \"reason\": \"marketplace_missing\",
  \"message\": \"No Codex marketplace containing computer-use is registered. Configure computerUse.marketplaceSource or computerUse.marketplacePath, then run /codex computer-use install.\"
}

Other isolated homes that had the marketplace registered were ready. Running the install path registered the bundled marketplace and the same home then reported:

{
  \"ready\": true,
  \"installed\": true,
  \"pluginEnabled\": true,
  \"mcpServerAvailable\": true,
  \"tools\": [\"click\", \"drag\", \"get_app_state\", \"list_apps\", \"perform_secondary_action\", \"press_key\", \"scroll\", \"set_value\", \"type_text\"]
}

Expected behavior

If OpenClaw/Codex can discover the bundled Computer Use marketplace at /Applications/Codex.app/Contents/Resources/plugins/openai-bundled, the status/install flow should make the required remediation clearer. Ideally, when computerUse.enabled=true and the bundled marketplace exists, /codex computer-use status or auto-install should distinguish:

• plugin cache exists but marketplace is not registered for this isolated home
• plugin is enabled but MCP server is missing
• plugin is fully ready

Suggested fixes

1. Update openclaw-weixin startup path to use ctx.channelRuntime in startAccount and monitor processing.
2. Remove manual Content-Length from Weixin API POST fetch headers.
3. Improve Codex Computer Use status/remediation for isolated Codex homes when bundled marketplace/plugin cache exists but marketplace registration is missing.

Verification after local patches

• openclaw channels status --probe: both openclaw-weixin accounts were running.
• Direct getUpdates calls for both Weixin accounts succeeded.
• Codex Computer Use status was ready: true in main, minidora-Codex, and codex-d6 isolated homes after registering the bundled marketplace.