Problem

When a Discord guild config includes a channels block to set per-channel overrides (e.g., requireMention: true on specific channels), all non-listed channels are implicitly denied. This is documented behavior ("if a guild has channels configured, non-listed channels are denied"), but it creates an impractical configuration model.

What we want

• Bot listens and responds in all channels in the guild (groupPolicy: "open")
• Two specific channels (#system-administration, #agent-design) have requireMention: true — the bot only responds there when @mentioned
• All other channels use the guild-level defaults (requireMention: false)

What happens

Adding a channels block with those two channel overrides causes every other channel in the guild to be silently denied. The only workaround is to explicitly list every channel in the config, which:

1. Breaks when new channels are created — they are omitted by default until manually added to the config
2. Requires a config update + gateway restart for every new channel
3. Is error-prone — forgetting to add a channel means the bot silently ignores it with no obvious error
4. Scales poorly — a guild with 20+ channels needs 20+ config entries just to override 2

Expected behavior

The channels block should act as additive per-channel overrides on top of the guild-level config, not as an implicit allowlist. Non-listed channels should inherit the guild-level defaults (groupPolicy, requireMention, users, etc.) rather than being denied.

Suggested config semantics

{
  "guilds": {
    "<guild_id>": {
      "requireMention": false,
      "groupPolicy": "open",
      "channels": {
        "<channel_id_1>": { "requireMention": true },
        "<channel_id_2>": { "requireMention": true }
      }
    }
  }
}

In this model:

• Channels listed in channels get their settings merged with guild defaults
• Channels not listed inherit guild defaults and are not denied
• The channels block is purely for overrides, not for access control

Current workarounds

1. Remove the channels block entirely — loses the ability to set per-channel overrides
2. List every channel explicitly — fragile, does not scale, breaks on new channel creation
3. Use bot-level NO_REPLY logic — unreliable (see related issue with internal monologue leaking)

Related issues

• #69748 (access lists with per-channel overrides) — broader scope, addresses user-level overrides
• #39661 (per-user mention policy) — addresses per-user granularity
• #8972 (pattern-based channel allowlist) — addresses dynamic channel matching

This issue is specifically about the default deny semantics of the channels block, which is a prerequisite behavior change that would benefit all of the above.

Environment

• OpenClaw version: current main (fork)
• Channel: Discord
• Config: groupPolicy: "open" with guild-level requireMention: false