Summary

• Problem: Three gaps in Feishu group policy enforcement: (1) groupConfig.enabled: false was parsed but never checked, so disabled groups still received messages; (2) the group allowlist rejection log emitted the sender's open_id instead of the group ID and policy, making it hard to diagnose; (3) the sender-level allowFrom check merged in DM pairing store entries, allowing DM-paired users to bypass explicit group admission config.
• Why it matters: Operators who disable a group or restrict group senders via groups.<id>.allowFrom could not trust those settings to be enforced. The store merge also created an inconsistency: group message admission used a merged list while group command authorization used config-only, so the same sender could pass message gating but fail command auth.
• What changed: (1) Added early return when groupConfig.enabled === false; (2) fixed rejection log to show group ID + groupPolicy; (3) removed readAllowFromStore merge from group sender check — groups.<id>.allowFrom is now config-only, matching command authorization behavior.
• What did NOT change (scope boundary): DM admission logic is untouched. readAllowFromStore is still used for DM dmPolicy and command authorization checks. groupPolicy / groupAllowFrom (group-level admission) logic is untouched.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #

User-visible / Behavior Changes

• Groups with enabled: false in config are now silently dropped (previously ignored).
• Senders not listed in groups.<id>.allowFrom are now blocked even if they have a DM pairing entry. Operators who relied on the store-merge behavior (unintentional) will need to add those users explicitly to allowFrom.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 / Bun
• Model/provider: —
• Integration/channel (if any): Feishu
• Relevant config (redacted):

  {
    "channels": {
      "feishu": {
        "groupAllowFrom": ["oc_xxx"],
        "groups": {
          "oc_xxx": {
            "enabled": false,
            "allowFrom": ["ou_admin"]
          }
        }
      }
    }
  }

Steps

1. Send a message to a group with enabled: false → should be dropped.
2. Send a message to a group with allowFrom: ["ou_admin"] as a user not in the list → should be blocked.
3. Send a message to the same group as ou_admin → should pass through.

Expected

• Case 1: message silently dropped, log emits group <id> is disabled.
• Case 2: message dropped, log emits sender <id> not in group <id> sender allowlist.
• Case 3: message delivered normally.

Actual

• All three cases behave as expected after this patch.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

pnpm test extensions/feishu/src/bot.test.ts — 7 tests pass.

Human Verification (required)

• Verified scenarios: enabled: false early return; sender blocked when not in allowFrom; sender allowed when in allowFrom; DM path unaffected.
• Edge cases checked: group with no allowFrom set (sender check skipped entirely); groupPolicy: open with no groupAllowFrom (group admitted, sender check skipped).
• What you did not verify: live Feishu webhook end-to-end with a real bot token.

Compatibility / Migration

• Backward compatible? No — operators who inadvertently relied on DM-paired users passing group sender checks will need to add them explicitly to groups.<id>.allowFrom.
• Config/env changes? No
• Migration needed? No — config schema unchanged; only enforcement tightened.

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert extensions/feishu/src/bot.ts to previous commit.
• Files/config to restore: extensions/feishu/src/bot.ts, extensions/feishu/src/bot.test.ts.
• Known bad symptoms: legitimate group users suddenly blocked → check if they need to be added to groups.<id>.allowFrom.

Risks and Mitigations

• Risk: operators with existing DM-paired users in groups may see those users blocked.
  • Mitigation: the old behavior was unintentional and undocumented; a clear migration note is included above. Operators can add users to allowFrom explicitly.