@JiwaniZakir Thanks for the thorough review — both points are spot-on.

On the magic prefix: Extracted NEXU_INTERNAL_ACCOUNT_PREFIX as a shared exported constant from channel-binding-compiler.ts. The config writer now imports it directly instead of relying on a hardcoded string. The prewarm account IDs are also derived from this prefix via template literals, so any future internal accounts will be automatically filtered.

On the dual index mutation: Agreed — the rollback path's cleanupWechatAccountState no longer touches accounts.json. Index reconciliation is now exclusively owned by the authoritative config writer during syncAll(). The cleanup method only removes credential and sync files (which is appropriate since a failed connect produces useless credentials). This makes the ownership boundary clear: files → direct cleanup, index → writer.

Both changes are in 7f4f126. Thanks for catching these!

The three-pronged decomposition here is solid — each fix is independently correct and the combined effect makes sense. One thing worth confirming: the prewarm account approach for WeChat mirrors the Feishu pattern, so make sure the config subtree key used during prewarm doesn't collide with a real user account prefix if someone happens to register a WeChat ID matching it. Also, dropping the initial getUpdates() timeout to something short (< 5s) is the right call, but verify the fallback behavior if the first poll returns empty — you don't want a tight retry loop burning CPU before the channel is fully authenticated.

@JiwaniZakir Good points to double-check — both are covered:

1. Prewarm ID collision: The prewarm sentinel is __nexu_internal_wechat_prewarm__ (prefixed with __nexu_internal_), while real account IDs are cuid2-generated (e.g. a4946e575b9e-im-bot). No realistic collision risk, and the config writer now explicitly filters by the shared NEXU_INTERNAL_ACCOUNT_PREFIX constant as an extra guard.

2. Short-poll empty response: The monitor has a RETRY_DELAY_MS = 2_000 sleep between each poll iteration regardless of response content, and initialPollsRemaining only decrements on successful (non-error) responses. So an empty first poll just waits 2s and retries — no tight loop.

Thanks for keeping an eye on these edge cases!

The NEXU_INTERNAL_ACCOUNT_PREFIX extraction is the right call — relying on a hardcoded string in two separate places for collision avoidance was a latent bug waiting to happen. One thing worth double-checking: the readiness wait added to connectWechat() should have a bounded timeout rather than blocking in, otherwise a failed prewarm (e.g. network issue during initial sync) would hang the connect flow instead of surfacing an error. If that's already handled upstream in the caller, ignore this.

@JiwaniZakir Already handled — waitForWechatReady() has a 30s deadline (Date.now() + 30_000). If it times out, connectWechat() rolls back the channel and throws, so the caller gets a clear error instead of a hang.

on the prewarm account leaking into syncWeixinAccountIndex() — the fix should filter it out at the merge boundary, similar to how internal sentinel values are excluded elsewhere. Adding a guard like if (accountId.startsWith('__nexu_internal_')) continue; in syncWeixinAccountIndex() before the merge would prevent it from persisting without requiring callers to be aware of the internal ID. Alternatively, if the prewarm account needs to stay out of the index entirely, the cleaner approach is to give it a dedicated config subtree that OpenClaw recognizes for hot-reload matching but never passes to the account sync path.

@chatgpt-codex-connector This is already addressed in the latest commits:

1. syncWeixinAccountIndex() is now authoritative — it only keeps IDs present in the current config, and explicitly filters out any ID starting with NEXU_INTERNAL_ACCOUNT_PREFIX (__nexu_internal_). The prewarm ID never lands in accounts.json.

2. The writer also runs an orphan file sweep on openclaw-weixin/accounts/, removing credential files for accounts no longer in the authoritative set — so listStoredWeixinAccountIds() can't resurrect them either.

See commits f799947 and 7f4f126.

To use Codex here, create an environment for this repo.

The bounded timeout on the readiness wait is the critical piece here — without it, a failed prewarm silently blocks connectWechat() in. Worth confirming the fallback path when the timeout fires actually surfaces an error to the caller rather than swallowing it and returning a false-ready state. Also, dropping the initial getUpdates() timeout from 35s to something shorter is a good fix, but make sure the reduced value is configurable or at least documented, since aggressive polling on reconnect could interact poorly with WeChat's rate limits in high-restart scenarios.

The three-pronged approach makes sense — each fix is independently valid, but together they compound nicely just like the original delays did. One thing worth verifying: the reduced initial long-poll timeout (presumably dropping from 35s to something much shorter) should have a fallback or backoff strategy to avoid hammering the WeChat endpoint if the channel is genuinely idle at startup. Also worth confirming the prewarm account pattern mirrors exactly what Feishu does so the two code paths don't diverge in maintenance burden over time.