Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix Telegram bot-menu slash commands (`/cmd@botname`) dropped in groups with require_mention=true [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#15415•Fetched 2026-04-25 06:22:45
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
1
Author
alblezalblez
Participants
alblezalblezcami-sosacami-sosa
Timeline (top)
labeled ×4commented ×1cross-referenced ×1subscribed ×1

In Telegram groups with require_mention: true, tapping a slash command (e.g. /new) from the bot command menu does not start a new session. The only workaround is to type the command manually with a space before the @botname (/new @hermes_bot), which is semantically wrong — that variant doesn't disambiguate from other bots sharing the command name in the same group.

Root Cause

Telegram parses slash commands server-side and attaches a single bot_command entity covering the whole /cmd@botname span. No separate mention entity is emitted for the @botname suffix in that case.

TelegramAdapter._message_mentions_bot (gateway/platforms/telegram.py) only inspects mention and text_mention entity types, so the menu form fails the group-mention gate in _should_process_message and the command never reaches _handle_command (the downstream get_command() parser in gateway/platforms/base.py already handles the @botname suffix correctly — the bug is purely in the gate).

The "type a space" workaround works accidentally: the space splits the token, so Telegram emits two entities — a bot_command for /new and a regular mention for @hermes_bot — and the mention branch of the gate catches it.

The existing test tests/gateway/test_telegram_group_gating.py::test_group_messages_can_require_direct_trigger_via_config encodes the incorrect fixture: it attaches a mention entity to /status@hermes_bot, which Telegram does not emit for the menu form. That's why the bug wasn't caught.

Fix Action

Fix

Recognize a bot_command entity whose @botname suffix matches self._bot.username (case-insensitive) as a direct mention of the bot, alongside the existing mention / text_mention checks. Reject commands addressed to other bots (/cmd@other_bot).

PR to follow with a regression test that uses the correct entity shape.

PR fix notes

PR #15417: fix(telegram): accept /cmd@botname from bot menu in groups

Description (problem / solution / changelog)

What / why

In Telegram groups with require_mention: true, slash commands tapped from the bot command menu (e.g. /new, /reset, /help) never start a new session. Users have to type /new @hermes_bot with a literal space — which is the wrong form, since it fails to disambiguate between multiple bots in the same group that share the same command name.

Root cause (full analysis in #15415): Telegram parses /cmd@botname as a single bot_command entity covering the whole span — no separate mention entity is emitted. _message_mentions_bot only inspected mention / text_mention entities, so the menu form failed the group-mention gate and was dropped by _should_process_message before reaching _handle_command. The downstream get_command() parser in gateway/platforms/base.py already strips @botname correctly — the bug is purely in the gate.

The existing test fixture at tests/gateway/test_telegram_group_gating.py::test_group_messages_can_require_direct_trigger_via_config hid the bug by attaching a mention entity to /status@hermes_bot, which Telegram does not actually emit for the menu form.

Change

  • gateway/platforms/telegram.py::_message_mentions_bot — accept bot_command entities whose @botname suffix matches self._bot.username (case-insensitive) as a direct mention of this bot. Still reject /cmd@other_bot.
  • tests/gateway/test_telegram_group_gating.py — add a _bot_command_entity helper, update the existing test to use the correct entity shape, and add regression cases for /cmd@other_bot (rejected) and bare /cmd in groups (still rejected under require_mention=true).

How tested

cd /tmp/hermes-pr/hermes-agent
source ~/.hermes/hermes-agent/venv/bin/activate
PYTHONPATH=/tmp/hermes-pr/hermes-agent python -m pytest \
    tests/gateway/test_telegram_group_gating.py \
    tests/gateway/test_telegram_mention_boundaries.py \
    -o 'addopts=' -v

All 27 telegram-gating / mention-boundary tests pass. Wider tests/gateway suite unchanged (pre-existing failures in test_status.py, test_webhook_adapter.py, and test_weak_credential_guard.py are unrelated to this change — they fail identically on pristine main).

Platforms

Verified on macOS 14 + Python 3.11.14. The change is platform-agnostic (entity inspection only, no OS-specific code paths).

Scope

Single logical change, no refactor, no behavior change for DMs or for groups with require_mention=false (that path returns True before the mention check is reached).

Fixes #15415.

Changed files

  • gateway/platforms/telegram.py (modified, +20/-0)
  • tests/gateway/test_telegram_group_gating.py (modified, +37/-4)
RAW_BUFFERClick to expand / collapse

Summary

In Telegram groups with require_mention: true, tapping a slash command (e.g. /new) from the bot command menu does not start a new session. The only workaround is to type the command manually with a space before the @botname (/new @hermes_bot), which is semantically wrong — that variant doesn't disambiguate from other bots sharing the command name in the same group.

Reproduction

  1. Add the bot to a Telegram group with at least one other user/bot.
  2. Enable telegram.require_mention: true (or leave the default when another bot is present in the group).
  3. Tap / in the compose bar → select /new from the menu. The sent text is /new@<hermes_bot_username>.
  4. Expected: the current session is reset.
  5. Actual: the message is silently dropped; no session reset.

DMs are unaffected. Typing /new @hermes_bot (with a literal space) also works, but for the wrong reason — see root cause.

Root cause

Telegram parses slash commands server-side and attaches a single bot_command entity covering the whole /cmd@botname span. No separate mention entity is emitted for the @botname suffix in that case.

TelegramAdapter._message_mentions_bot (gateway/platforms/telegram.py) only inspects mention and text_mention entity types, so the menu form fails the group-mention gate in _should_process_message and the command never reaches _handle_command (the downstream get_command() parser in gateway/platforms/base.py already handles the @botname suffix correctly — the bug is purely in the gate).

The "type a space" workaround works accidentally: the space splits the token, so Telegram emits two entities — a bot_command for /new and a regular mention for @hermes_bot — and the mention branch of the gate catches it.

The existing test tests/gateway/test_telegram_group_gating.py::test_group_messages_can_require_direct_trigger_via_config encodes the incorrect fixture: it attaches a mention entity to /status@hermes_bot, which Telegram does not emit for the menu form. That's why the bug wasn't caught.

Fix

Recognize a bot_command entity whose @botname suffix matches self._bot.username (case-insensitive) as a direct mention of the bot, alongside the existing mention / text_mention checks. Reject commands addressed to other bots (/cmd@other_bot).

PR to follow with a regression test that uses the correct entity shape.

extent analysis

TL;DR

Update the TelegramAdapter._message_mentions_bot method to recognize bot_command entities with a matching @botname suffix as direct mentions.

Guidance

  • Review the gateway/platforms/telegram.py file and locate the TelegramAdapter._message_mentions_bot method to understand the current implementation.
  • Modify the method to check for bot_command entities and verify if the @botname suffix matches the bot's username (case-insensitive).
  • Add a regression test to tests/gateway/test_telegram_group_gating.py to cover the corrected scenario, ensuring the test uses the correct entity shape emitted by Telegram.
  • Consider updating the existing test test_group_messages_can_require_direct_trigger_via_config to reflect the correct behavior.

Example

def _message_mentions_bot(self, message):
    # ... existing code ...
    for entity in message.entities:
        if entity.type == 'bot_command' and entity.text.endswith('@' + self._bot.username):
            # Recognize as direct mention
            return True
    # ... existing code ...

Notes

The fix relies on correctly identifying the bot_command entity and its @botname suffix. Ensure the updated method handles case-insensitive matching and rejects commands addressed to other bots.

Recommendation

Apply the workaround by updating the TelegramAdapter._message_mentions_bot method, as this will correctly handle the bot_command entity and fix the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#prompt issue#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING