WeChat channel start+rebuild crash-loops the whole sandbox with uncaught WECHAT_BOT_TOKEN placeholder-refresh error

[lyral-commits]

Description

On a sandbox with WeChat previously paired via QR, running channels stop wechat + rebuild followed by channels start wechat + rebuild crash-loops the entire sandbox. The container repeatedly restarts and never reaches Ready, and the crash blocks even non-destructive recovery (state backup for a subsequent recreate attempt fails because the container cannot start).

Platform scope: Reproduced on Ubuntu 26.04 only; other platforms not tested.
Regression: Unknown — earlier versions not tested.
OpenShell issue: No — root cause is NemoClaw's own WeChat account placeholder refresh script (nemoclaw-wechat-account-placeholder.js), not the OpenShell CLI/runtime.

Environment

Device:        Ubuntu x86_64 server, no GPU
OS:            Ubuntu 26.04 LTS
Architecture:  x86_64
Node.js:       v22.23.2 (inside sandbox)
Docker:        29.6.1
OpenShell CLI: 0.0.106
NemoClaw:      v0.0.117
OpenClaw:      2026.7.1

Steps to Reproduce

1. Onboard an OpenClaw sandbox: nemoclaw onboard --name {sandbox}.
2. Pair WeChat via QR: nemoclaw {sandbox} channels add wechat (scan the rendered QR with WeChat on phone). Confirm pairing with nemoclaw {sandbox} channels status — WECHAT_ACCOUNT_ID / WECHAT_USER_ID show [ok].
3. Send a DM from the paired account and confirm the bot replies (sanity check the channel is genuinely live).
4. Stop the channel and rebuild:

   nemoclaw {sandbox} channels stop wechat
   nemoclaw {sandbox} rebuild --yes

   Rebuild completes successfully; channels status correctly reports the channel as registered-but-paused.
5. Send another DM — correctly receives no reply (channel is paused, as expected).
6. Re-enable and rebuild:

   nemoclaw {sandbox} channels start wechat
   nemoclaw {sandbox} rebuild --yes

7. Observe the rebuild's own log and docker ps -a / docker logs for the sandbox's container.

Expected Result

Per the product documentation (Manage Messaging Channels > Pause and Resume a Channel): "A later channels start wechat plus rebuild revives the bridge against the same iLink account without a fresh QR scan. The bot token remains in the OpenShell provider across the stop and start cycle." The sandbox should reach Ready with WeChat active again, and a DM sent from the same account should receive a reply — no new QR scan required.

Actual Result

The step-6 rebuild reports success ("✓ Sandbox rebuild completed... Now running: OpenClaw v2026.7.1"), but the underlying container immediately enters a crash-restart loop (docker ps -a shows Restarting (1) Ns ago, repeating indefinitely). nemoclaw {sandbox} status subsequently reports Phase: Error. Any further attempt to rebuild or recover the sandbox fails at the state-backup step because the crash-looping container cannot be exec'd into:

State backup failed — aborting recreate to prevent data loss.

The sandbox is left in an unusable state requiring manual docker rm -f + nemoclaw {sandbox} destroy --yes + full re-onboarding + a brand-new QR scan — directly contradicting the documented no-fresh-QR-scan guarantee.

Reproduced twice independently on two separate freshly-onboarded sandboxes with two separate QR pairings — not a one-off flake.

Logs

[channels] Messaging channels active (baked at build time):
[channels]   wechat
[channels] Installing WeChat diagnostics (provider readiness + inference errors)
[channels] WeChat diagnostics installed (NODE_OPTIONS updated)
[gateway] openclaw gateway launched (pid 489)
[gateway] auto-pair watcher launched (pid 527)
[SECURITY] Refusing WeChat provider placeholder refresh — WECHAT_BOT_TOKEN is missing from the runtime environment
/tmp/nemoclaw-wechat-account-placeholder.js:29
        throw new Error("[SECURITY] WeChat account placeholder refresh failed.");
        ^

Error: [SECURITY] WeChat account placeholder refresh failed.
    at refreshWechatAccountPlaceholder (/tmp/nemoclaw-wechat-account-placeholder.js:29:15)
    at Object.<anonymous> (/tmp/nemoclaw-wechat-account-placeholder.js:32:1)
    at Module._compile (node:internal/modules/cjs/loader:1781:14)
    at Object..js (node:internal/modules/cjs/loader:1913:10)
    at Module.load (node:internal/modules/cjs/loader:1505:32)
    at Function._load (node:internal/modules/cjs/loader:1309:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:254:19)
    at Module.require (node:internal/modules/cjs/loader:1527:12)
    at node:internal/modules/cjs/loader:2071:12
    at loadPreloadModules (node:internal/process/pre_execution:756:5)

Node.js v22.23.2
2026-09-01T09:14:35.941Z OCSF PROC:TERMINATE [INFO] unknown(0) [exit:1]

Separately, the onboard/rebuild step that queues the channels start change logged (before the crash-loop began):

No host inputs configure wechat; disabling the channel and its network egress.

This message describes a graceful-disable intent that the actual sandbox startup script does not honor — instead of disabling WeChat gracefully, the startup script throws an uncaught exception that kills the entire OpenClaw gateway process, not just the WeChat bridge.

Related Bugs / not duplicate of

#10079 is the closest related issue (messaging bridge credentials not injected into sandbox for Discord/Google Chat/Slack) but is closed, and its follow-up fix (adding OpenShell-to-Hermes runtime credential aliases) was scoped to Hermes WeChat and Microsoft Teams only — this report is the OpenClaw WeChat stop/start/rebuild path, which remains broken on v0.0.117 and additionally crash-loops the whole sandbox rather than just failing to start the channel.