openclaw - 💡(How to fix) Fix [Bug]: openclaw-weixin v2.4.1 has two critical bugs on Node.js 22 / OpenClaw 2026.5.5 [1 comments, 2 participants]

Bug type

Behavior bug

Summary

The @tencent-weixin/openclaw-weixin plugin v2.4.1 has two critical bugs that prevent login and runtime initialization on Node.js 22.x with OpenClaw 2026.5.5 on Linux:

1. Login fails with TypeError: fetch failed caused by manually setting Content-Length HTTP header, which Undici 8.2.0 (bundled with Node.js 22) rejects with UND_ERR_INVALID_ARG: invalid content-length header.
2. Weixin runtime initialization timeout caused by module isolation — setWeixinRuntime is called from index.js but monitor.js's waitForWeixinRuntime cannot see the runtime because two separate module instances of runtime.js are loaded.

Environment

• OpenClaw version: 2026.5.5
• openclaw-weixin version: 2.4.1
• Node.js version: v22.22.2
• Operating system: Linux 5.10.134-19.2.al8.x86_64 (x64)
• Install method: npm

Bug 1: Login fails with fetch failed / UND_ERR_INVALID_ARG

Steps to reproduce

1. Install @tencent-weixin/[email protected] into OpenClaw 2026.5.5 on Node.js 22
2. Run openclaw channels login --channel openclaw-weixin
3. The login command fails immediately

Expected behavior

A QR code URL is generated for scanning.

Actual behavior

Failed to start login: TypeError: fetch failed
Channel login failed: Error: Failed to start login: TypeError: fetch failed

The underlying error (found via debug logging):

UND_ERR_INVALID_ARG: invalid content-length header

Root cause

In ~/.openclaw/extensions/node_modules/@tencent-weixin/openclaw-weixin/api.js (and the same file under ~/.openclaw/npm/node_modules/@tencent-weixin/openclaw-weixin/api.js), the HTTP request code manually sets a Content-Length header:

headers['Content-Length'] = Buffer.byteLength(body);

Node.js 22 uses Undici 8.2.0 as its HTTP client, which does not allow manually setting the Content-Length header — it calculates it automatically. Setting it manually causes a header conflict and the request is rejected.

Fix applied locally

Removed the line that manually sets Content-Length in api.js (both copies). Login then works correctly and the QR code URL is returned.

Bug 2: Weixin runtime initialization timeout

Steps to reproduce

1. Successfully complete login (after fixing Bug 1)
2. Restart the Gateway (openclaw gateway restart)
3. Check Gateway logs

Expected behavior

The Weixin channel starts and processes inbound messages.

Actual behavior

Gateway logs show:

Weixin runtime initialization timeout

Inbound messages are not processed.

Root cause

The plugin is loaded from two different paths by the Gateway:

• ~/.openclaw/npm/node_modules/@tencent-weixin/openclaw-weixin/
• ~/.openclaw/extensions/node_modules/@tencent-weixin/openclaw-weixin/

This causes module isolation: runtime.js is loaded as two separate module instances. When index.js calls setWeixinRuntime(runtime), it sets the runtime on one instance. But when monitor.js calls waitForWeixinRuntime(), it reads from a different instance and never sees the runtime — resulting in a timeout.

The call sequence:

1. index.js → setWeixinRuntime(runtime) ✅ succeeds (instance A)
2. channel.js → monitor.js → waitForWeixinRuntime() ❌ timeout (instance B)
3. Even though setWeixinRuntime continues to be called during the 10-second wait, monitor.js never sees it

Fix applied locally

Modified monitor.js to bypass the broken waitForWeixinRuntime global variable lookup and instead use opts.runtime which is passed directly from the channel initialization:

// monitor.js — instead of waiting for global pluginRuntime
// Use the runtime passed directly via opts
const runtime = opts.runtime || await waitForWeixinRuntime(10000);

Impact

• Severity: Critical — the plugin is completely non-functional without these fixes
• Affected users: Anyone using openclaw-weixin v2.4.1 with Node.js 22+
• Frequency: 100% reproducible

Additional notes

• These bugs have been confirmed fixed locally with the patches described above
• There may be other copies of the plugin in other paths that also need the api.js fix
• The module isolation issue (Bug 2) suggests the plugin loading mechanism should ensure only one copy of the plugin is loaded, or the runtime sharing should use a mechanism that works across module boundaries