[Bug]: Discord guild mentions ignore pairing-approved users unless the Discord allowlist is populated

[KarmicDaoist]

Bug Description

A Discord user who is approved via Hermes pairing can still be silently ignored when they @mention the bot in a guild/server text channel unless they are also present in the Discord allowlist (DISCORD_ALLOWED_USERS / discord.allow_from).

This appears to be a real upstream inconsistency rather than something specific to one local deployment:

• the gateway auth layer treats pairing as a first-class auth grant
• Discord slash auth also honors pairing directly
• but Discord guild on_message intake fail-closes at the adapter before the pairing-aware gateway auth union can help

I also compared the relevant files in a local checkout against origin/main; for this behavior the code paths are effectively the same upstream, so this does not look like local patch drift.

Steps to Reproduce

1. Configure a Discord bot with normal mention behavior (require_mention: true is sufficient).
2. Do not populate DISCORD_ALLOWED_USERS / discord.allow_from for the target user.
3. Approve that Discord user through Hermes pairing so they are present in the pairing store.
4. Have that user send a normal @bot message in a guild/server text channel.

Expected Behavior

If a Discord user is explicitly approved via Hermes pairing, that approval should be honored consistently across Discord surfaces, including normal guild text mentions, unless some stronger explicit deny policy blocks them.

In practice, pairing should work consistently for:

• DMs
• slash commands
• normal guild @bot text messages

Actual Behavior

A pairing-approved Discord user can:

• work in DMs
• pass slash auth

but still be ignored for normal guild @bot messages when they are not also in DISCORD_ALLOWED_USERS / discord.allow_from.

Affected Component

• Gateway (Telegram/Discord/Slack/WhatsApp)
• Configuration (config.yaml, .env, hermes setup)

Messaging Platform

• Discord

Debug Report

hermes debug share --local summary:

version:          0.18.0 [88d1d620] (2026-07-02)
os:               Linux 6.8.0-1059-azure x86_64
python:           3.11.15
openai_sdk:       2.24.0
profile:          default
gateway:          running (systemd (user), pid 102064)
platforms:        telegram, discord, whatsapp

Additional verification performed:

hermes version
Hermes Agent v0.18.0 (2026.7.1) · upstream 66c3d595
Update available: 102 commits behind — run 'hermes update'

python3 --version
Python 3.11.15

Even though the local checkout is 102 commits behind overall, I diffed the relevant files against origin/main and did not find a material difference for this behavior:

• gateway/authz_mixin.py
• gateway/pairing.py
• plugins/platforms/discord/adapter.py
• related Discord auth tests

Operating System

Ubuntu 24.04 / Linux 6.8.0-1059-azure x86_64 GNU/Linux

Python Version

3.11.15

Hermes Version

0.18.0 (2026.7.1) / local HEAD 88d1d620, upstream 66c3d595

Root Cause Analysis (optional)

The relevant code paths appear to disagree about whether pairing alone is sufficient authorization:

1. Gateway auth treats pairing as a first-class auth grant

   • gateway/authz_mixin.py
   • the auth layer returns authorized when the pairing store says the user is approved

2. Pairing sync mirrors into the allowlist only when an allowlist already exists

   • gateway/pairing.py
   • this intentionally avoids creating a new allowlist on open gateways, so a pairing-approved user may exist only in the pairing store

3. Discord guild on_message intake fail-closes before pairing union can help

   • plugins/platforms/discord/adapter.py
   • guild message intake checks _is_allowed_user(...) and returns early if false
   • that means a normal guild text message can be rejected before the later pairing-aware gateway auth path runs

4. Discord slash auth already honors pairing directly

   • plugins/platforms/discord/adapter.py
   • the slash authorization path explicitly checks the pairing store and allows pairing-approved users
   • there are tests covering that slash behavior

This creates an inconsistent trust model across Discord surfaces:

• pairing works in DM auth paths
• pairing works in slash auth paths
• pairing does not work the same way for normal guild text mentions

Proposed Fix (optional)

One likely fix would be to make Discord guild on_message auth mirror the same pairing-aware union used by the gateway auth layer / slash auth path.

For example, if _is_allowed_user(...) fails for a guild message, check whether the user is approved in the pairing store before returning early.

A regression test would also help, covering:

• pairing-approved Discord user
• no DISCORD_ALLOWED_USERS
• normal guild text mention
• expected: message proceeds instead of being dropped

Are you willing to submit a PR for this?

Yes — if this is accepted as a bug, I can work on a PR with a regression test.

[KarmicDaoist]

Thank you for your hard work @teknium1 u guys are making an awesome product ❤️