Bug Description

Bot commands fail when message contains Unicode em dash (—) instead of ASCII hyphen (-)

When the assistant posts messages that include a Unicode em dash (U+2014) or en dash (U+2013), BotFather (or Telegram command parser) treats them differently and rejects or does not recognise the command/format. The expected behavior is that the parser should accept a simple hyphen-minus (-), or at least BotFather should normalise common dash characters.

Steps to Reproduce

Reproduction steps:

1. Send a message from the assistant to a bot that includes an em dash, e.g.: "Hermes Agent — Status: ONLINE" (em dash U+2014 between "Agent" and "Status").
2. Try to use this message where BotFather or Telegram expects a hyphen (for example, creating a command or parsing a flag).
3. Observe that BotFather/Telegram rejects or mis-parses the input because it expects ASCII hyphen-minus.

Expected Behavior

Success! Command list updated. /help

Actual Behavior

Sorry, the list of commands is invalid. Please use this format:

command1 - Description
command2 - Another description

You can also send /empty to clear the list or keep it empty.

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

Telegram

Operating System

Debian 13

Python Version

3.11.15

Hermes Version

v0.4.0 (2026.3.23)

Relevant Logs / Traceback

## Telegram bot status (getMe/getWebhookInfo/getUpdates)
{
  "ok": true,
  "result": {
    "id": 8645695827,
    "is_bot": true,
    "first_name": "Hermes",
    "username": "jello_h_bot",
    "can_join_groups": true,
    "can_read_all_group_messages": false,
    "supports_inline_queries": false,
    "can_connect_to_business": false,
    "has_main_web_app": false,
    "has_topics_enabled": false,
    "allows_users_to_create_topics": false
  }
}
{
  "ok": true,
  "result": {
    "url": "",
    "has_custom_certificate": false,
    "pending_update_count": 0
  }
}
{
  "ok": true,
  "result": []
}

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

Suggested fixes:

• Server-side (Telegram): Accept and normalise U+2013/U+2014 to U+002D when parsing commands or flags.
• Client-side (our poller/assistant): Normalise dashes before sending text to Telegram (replace U+2014 and U+2013 with U+002D). This is a safe immediate mitigation.

I have patched the poller to normalise dashes before sending messages; this issue documents the problem and suggests upstream parsing normalisation as an improvement.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR