openclaw - 💡(How to fix) Fix [Bug]: Feishu DM pairing approval lost after npm update (credentials file intact)

Bug type

Channel - Feishu

Summary

After upgrading OpenClaw via npm i -g openclaw@latest, the Feishu bot (lux account, non-default) shows OpenClaw: access not configured and displays a pairing code, even though the approved allowFrom credentials file is still intact on disk.

Running openclaw pairing approve feishu <CODE> fixes it immediately, but this needs to be done after every npm update.

Steps to reproduce

1. Configure a Feishu channel with a non-default account (e.g. lux) using dmPolicy: "allowlist"
2. Approve a DM sender via openclaw pairing approve feishu <CODE>
3. Verify credentials/feishu-lux-allowFrom.json contains the approved user ID
4. Run npm i -g openclaw@latest to upgrade
5. Restart Gateway
6. Send a DM from the approved user to the Feishu bot

Expected behavior

The bot should recognize the previously approved sender (stored in credentials/feishu-lux-allowFrom.json) and process messages normally.

Actual behavior

The bot replies with OpenClaw: access not configured and a pairing code, as if the sender was never approved. The credentials file (feishu-lux-allowFrom.json) still exists and contains the correct user ID.

Workaround

Run openclaw pairing approve feishu <CODE> after each update.

OpenClaw version

2026.5.22 (issue also observed with earlier versions after updates)

Operating system

Windows 11 x64

Install method

npm install -g openclaw

Channel configuration

• feishu channel with 2 accounts (lux + daily_notice)
• dmPolicy: allowlist
• accounts.lux with allowFrom stored in credentials/feishu-lux-allowFrom.json
• accounts.default with allowFrom in openclaw.json

Relevant logs / evidence

• credentials/feishu-lux-allowFrom.json persists correctly across updates (not deleted/modified)
• openclaw pairing approve resolves the issue each time
• The daily_notice account (separate appId) is not affected

Additional context

This appears to be a regression where the Gateway/feishu plugin does not properly read the existing credentials/<channel>-<accountId>-allowFrom.json after a version update + restart, even though the file is untouched. The pairing state should survive npm updates since the credentials/ directory is under .openclaw (user data), not in the npm installation directory.