Agent cannot read Telegram group chat history via t.me/c/ URLs (HTTP 403)

[howardpen9]

Summary

When asking the Hermes agent to fetch a message from a Telegram group it is already a member of, the agent fails with HTTP 403 and falls back to browser_navigate, which also cannot access t.me/c/... private group links. As a result, the agent has no way to read historical messages from groups it belongs to.

Repro

1. Add the Hermes bot (e.g. howard_BOT) to a private Telegram group/supergroup.
2. In a DM with the bot, send a private message link from that group, e.g.:

   can you got this info? https://t.me/c/3712897238/712/1031
   

3. Observe the agent response.

Actual behavior

The agent returns:

⚠️ Non-retryable error (HTTP 403) — trying fallback...
🔄 Primary model failed — switching to fallback: gpt-5.3-codex via openai-codex
🌐 browser_navigate: \"https://t.me/c/3712897238/712/1031\"

• The primary fetch path returns 403 instead of using the bot's existing membership in the group.
• The fallback is browser_navigate, but t.me/c/<internal_id>/... links are only resolvable inside an authenticated Telegram client, so the browser fallback cannot retrieve the message either.
• The agent never reaches the message content and cannot answer the question.

Screenshot of the failure:
(attached in the issue thread)

Expected behavior

When the bot is already a member of the target chat, the agent should be able to read historical messages from that chat. Specifically:

• Recognize https://t.me/c/<internal_chat_id>/<thread_id>/<message_id> as a Telegram private group/supergroup link.
• Resolve the internal chat id to a real chat_id the bot has access to.
• Fetch the message (and ideally surrounding context) via the Telegram Bot API or MTProto, instead of attempting a public HTTP GET that always 403s on private chats.
• Only fall back to browser_navigate for genuinely public web URLs, not Telegram deep links.

Why this matters

We want the agent to be able to use the Telegram group chat as a historical knowledge base — falling back to past messages in the group when answering questions, building context, or checking prior decisions. Without the ability to read history from groups the bot is already in, this whole fallback / long-term memory pattern is blocked.

This is a fairly common pattern for Telegram-based assistants: the bot is in a working group, users reference older messages by link, and the bot is expected to read them. Right now Hermes cannot do that at all.

Environment

• Repo: NousResearch/hermes-agent
• Telegram client: macOS desktop
• Bot: howard_BOT (member of the target supergroup)
• Primary model failed → fallback gpt-5.3-codex via openai-codex (so this is not model-specific; it's the fetch layer)
• Link format: https://t.me/c/3712897238/712/1031 (private supergroup, message in a topic/thread)

Suggested direction

A few options, roughly in order of effort:

1. Bot API path — when the URL matches t.me/c/<id>/..., call getChat / forwardMessage / copyMessage against chat_id = -100<id> using the bot token, instead of HTTP GET. This works for any chat the bot is already a member of.
2. MTProto path — if richer history access is needed (search, scrollback beyond what Bot API exposes), use an MTProto client (e.g. Telethon / Pyrogram / grammers) under a user or bot session, and let the agent query message history as a tool.
3. Tool registration — expose this as an explicit telegram_get_message(chat, message_id) / telegram_search_history(chat, query) tool so the agent picks it deliberately instead of relying on a generic URL fetcher that will always 403 on t.me/c/.

Happy to help test a fix against the same group if useful.

[helix4u]

this issue is valid.

Hermes does have Telegram thread/topic support in the gateway, but it does not currently have a Telegram-native fetch path for t.me/c/... message links. Right now there is no built-in resolver that recognizes those private Telegram links and turns them into a bot-accessible message lookup, so the agent falls back to generic URL fetch/browser behavior instead. For private t.me/c/... links, that is not sufficient, which is why you end up with the 403 + browser fallback dead end.

So the bug here is not model-specific. It is that Hermes treats a Telegram private message link like a normal web URL instead of routing it to a Telegram-aware retrieval path.

Your suggested direction makes sense at a high level, especially the first part: detect t.me/c/<id>/... as a Telegram deep link and stop sending it to the generic web/browser layer. The exact retrieval mechanism still needs implementation work, but the issue itself is real and the current fallback behavior is wrong for this URL class.

[txhno]

ive fixed it here: #10203

[GottZ]

This was generated by AI during triage.

Summary

One PR addresses #10020. #10203 detects private Telegram deep links, prevents generic browser fetching, and resolves messages already captured in Hermes state, but it does not provide the Telegram-native retrieval needed for older messages that Hermes never observed.

Related pull requests

• fix(telegram): resolve private t.me/c links from session history #10203 best fix — (+498/-35) — partial fix and best existing fix: the diff adds t.me/c/... parsing, browser/web short-circuiting, inbound-message metadata persistence, and local-state lookup. Consistent with the contributor's keep_open review, it requires adaptation because current main already has the platform_message_id contract and the resolver returns an error for accessible messages absent from the local database, leaving the core arbitrary-history case in Agent cannot read Telegram group chat history via t.me/c/ URLs (HTTP 403) #10020 unresolved.

Suggested consolidation

Keep open with a salvage path: #10203 is the best existing fix, and its deep-link parser plus Telegram-specific web/browser routing are worth preserving. Adapt the implementation to main's existing platform_message_id schema and add a gateway-to-state or Telegram-native retrieval path for messages not previously observed by Hermes, as required by the contributor's keep_open review; there are no duplicate PRs to close.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I10020(["issue #10020 (open)"])
    P10203["PR #10203 (open)"]
    P10203 -->|best fix| I10020
    class I10020 open
    class I10020 target
    class P10203 open
    class P10203 best
    click I10020 "https://github.com/NousResearch/hermes-agent/issues/10020"
    click P10203 "https://github.com/NousResearch/hermes-agent/pull/10203"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 36 kB of PR diffs, 5 kB of issue/PR text, 6 kB of discussion (7 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.