Feishu multi-account runtime drops top-level allowlist fields for accounts.main in 2026.4.23

Environment

• OpenClaw version: 2026.4.23 (a979721)
• Channel: feishu
• Config shape: channels.feishu.accounts.main is present
• Runtime mode: reproduced in a real gateway runtime while handling Feishu group messages

Summary

When channels.feishu.accounts.main is configured, Feishu top-level shared access-control fields appear to be lost from the resolved runtime account config.

Affected fields observed in this setup:

• channels.feishu.allowFrom
• channels.feishu.groupAllowFrom
• channels.feishu.groupSenderAllowFrom

As a result, group messages that should pass the configured allowlist are rejected at runtime.

Moving those same fields from the top-level channels.feishu object into channels.feishu.accounts.main works around the issue immediately.

Expected behavior

Top-level shared Feishu config should apply to accounts unless overridden per-account.

This expectation is consistent with the schema design:

• FeishuSharedConfigShape includes shared fields such as:
  • allowFrom
  • groupAllowFrom
  • groupSenderAllowFrom
• The shared shape is used by both:
  • top-level FeishuConfigSchema
  • per-account FeishuAccountConfigSchema

So a config like this should work:

{
  "channels": {
    "feishu": {
      "defaultAccount": "main",
      "groupPolicy": "allowlist",
      "allowFrom": ["ou_xxx"],
      "groupAllowFrom": ["oc_group_a", "oc_group_b"],
      "accounts": {
        "main": {
          "appId": "cli_xxx",
          "appSecret": "${FEISHU_APP_SECRET}"
        }
      }
    }
  }
}

Actual behavior

At runtime, the message reaches the Feishu monitor, but the resolved runtime account config is missing the top-level allowlist fields.

Observed symptoms:

• Feishu group message is received by the plugin
• access check later rejects the same group as not in groupAllowFrom
• diagnostic logging showed runtime account.config did not include:
  • groupAllowFrom
  • groupSenderAllowFrom
  • allowFrom

Workaround:

• copying those fields into channels.feishu.accounts.main makes the same scenario work immediately

Example workaround:

{
  "channels": {
    "feishu": {
      "defaultAccount": "main",
      "groupPolicy": "allowlist",
      "accounts": {
        "main": {
          "appId": "cli_xxx",
          "appSecret": "${FEISHU_APP_SECRET}",
          "allowFrom": ["ou_xxx"],
          "groupAllowFrom": ["oc_group_a", "oc_group_b"]
        }
      }
    }
  }
}

Why this appears to be a bug

The implementation suggests top-level config should merge into account config:

• mergeFeishuAccountConfig(cfg, accountId) calls resolveMergedAccountConfig(...)
• resolveMergedAccountConfig(...) calls mergeAccountConfig(...)
• mergeAccountConfig(...) does a base-plus-account merge

Relevant local runtime files from 2026.4.23:

• dist/extensions/feishu/accounts-BtXgszRg.js
• dist/account-helpers-YjrnBOFI.js
• dist/extensions/feishu/monitor-*.js

Relevant logic chain:

• runtime account resolution:
  • resolveFeishuRuntimeAccount(...)
  • buildResolvedFeishuAccount(...)
  • mergeFeishuAccountConfig(...)
• runtime group allowlist enforcement:
  • Feishu monitor reads account.config.groupAllowFrom

Schema also explicitly allows these fields at the top level.

That combination makes the observed runtime loss of the top-level fields look like an implementation bug rather than a config error.

Notes from debugging

This was narrowed down step by step:

1. top-level Feishu config contained valid allowlist fields
2. matching logic itself was tested independently and returned allowed
3. merge helper behavior looked correct in isolated inspection
4. runtime diagnostic logging showed the resolved account.config lacked the expected top-level allowlist fields
5. duplicating the same fields under channels.feishu.accounts.main fixed the problem

Impact

This can cause a valid Feishu multi-account configuration to fail closed at runtime for group access control.

Users may reasonably follow the shared top-level config pattern and still get rejected group messages unless they duplicate the same fields inside accounts.main.

Suggested fix

Ensure Feishu runtime account resolution preserves top-level shared fields for account snapshots when accounts.main is used, including at least:

• allowFrom
• groupAllowFrom
• groupSenderAllowFrom

Possible regression test

A good regression test would be:

1. configure channels.feishu.defaultAccount = "main"
2. define allowFrom and groupAllowFrom only at top-level channels.feishu
3. define credentials only in channels.feishu.accounts.main
4. resolve runtime account for main
5. assert that account.config.allowFrom and account.config.groupAllowFrom are present in the resolved runtime account config