Telegram 平台整合相關的官方 issue。 資料來自官方 GitHub repo，狀態由官方 label 推導，每筆附原始連結與最後檢查日期。
使用 hermes send --to telegram（未指定 chat id）時，程式只複製 home.chat_id，卻遺漏 home.thread_id，導致在 Telegram DM topic mode 且已設定 TELEGRAM_HOME_CHANNEL_THREAD_ID 的情況下，所有裸目標的 hermes send（CLI、cron 派送、agent 工具呼叫、外部自動化）都會送到 DM 根目錄而非設定好的主題。
改用明確帶 thread_id 的目標格式 telegram:<chat_id>:<thread_id> 可正常送達，避免使用裸平台目標。
_polling_heartbeat_loop 偵測到 CLOSE-WAIT socket 後會觸發 _handle_polling_network_error，但裡面呼叫 app.updater.stop() 沒有設定 timeout。如果底層 TCP 連線卡在 CLOSE-WAIT，polling task 會卡在 epoll 上永遠不會醒來，導致 stop() 永久掛住，後續 reconnect 永遠不會被觸發，訊息會被靜默丟棄長達數小時直到手動重啟。
與 #58258 相同的 bug：cron job 透過 deliver: origin 送訊息到 Telegram 時，打字中提示會持續顯示到整個子程序結束，而非訊息送達後就消失，長時間背景工作會讓提示持續 30 到 60 分鐘以上。此 issue 已標記為重複並關閉。
當 cron job 透過 deliver: origin 送訊息到 Telegram 時，打字中提示會持續顯示到整個 cron job 子程序結束為止，而不是訊息送達後就消失。若 cron job 送出簡短通知後還繼續跑背景工作，使用者的 DM 就會持續顯示打字中長達 30 到 60 分鐘以上。
gateway 的 Telegram adapter 連線時卡在「Connecting to Telegram (attempt 1/8)...」，即使等超過 15 分鐘也不會拋出 TimeoutError，也不會重試。回報者在多種情境下做了診斷測試，發現問題只在特定執行環境（s6-overlay supervision）下才會出現。
Telegram gateway 配本地 telegram-bot-api --local 伺服器時，iOS .MOV 等影片文件下載會報 InvalidToken: Not Found: method not found。檔案其實已在本地儲存，但 Hermes 沒把路徑映射回可讀檔案，結果是空白的使用者訊息或只剩 metadata。
自從某次修正（#22773）後，cron 排程投遞到 Telegram 私訊（DM）forum 主題的訊息會被導向 General/主要主題，而非目標主題，即使 cron 設定的投遞目標本身是正確的；根因是 cron/scheduler.py 對「私訊主題」的分類判斷邏輯有誤。此 issue 已關閉。
當 cron 排程訊息指定投遞到 Telegram 私訊（DM）的特定主題時，由於路徑中只帶有一般的 thread_id、缺少私訊主題所需的中繼資料，Telegram adapter 可能拒絕或改成投遞到主題之外，導致訊息沒有出現在原本指定的主題中。
這個 issue 指出 Telegram Bot API 10.1 新增了 RichMessage 等豐富訊息格式（標題、清單、表格、LaTeX 等區塊），提案讓 Hermes 的 Telegram gateway 支援這些新 API，取代目前 plain/MarkdownV2 訊息與逐則編輯的串流方式，讓輸出呈現更完整。
目前 gateway 在正規化收到的訊息時會捨棄 Telegram 原生的轉發訊息中繼資料（如 forward_origin），導致 agent 無法分辨使用者是自己輸入還是轉發他人訊息。提案新增一個平台中立的標註層來保留這類上下文。
提案根據 Telegram 於 2026 年 5 月 7 日釋出的一批新 AI bot 功能，建議 Hermes 導入其中幾項：Guest AI Bot（無需加入群組即可被 @mention 使用）、Bot-to-Bot 通訊（讓多 agent 工作流可直接在 Telegram 上互相對話協作）等，以強化 Hermes 的多 agent 與團隊協作情境。
使用者提出功能需求，希望 Hermes 能有一套通用、跨平台的方式讓訊息附加互動式動作按鈕（尤其是 Telegram 的 inline keyboard），而不是針對特定功能（如模型選擇、指令核准）各自寫死邏輯，讓 agent 產生的訊息或排程訊息都能附上「是/否」「部署/取消」等按鈕選項。此 issue 為開放狀態，處理狀態為調查中。
回報者在 Docker/Coolify 部署環境下，CLI 使用 openai-codex provider 可正常運作且 hermes status 顯示已登入，但透過 Telegram gateway 使用同一組憑證時卻收到「No Codex credentials stored」的錯誤。此 issue 已關閉。
使用者提出功能需求，希望單一 Telegram bot 能依照論壇主題（topic/thread）將訊息分派給不同的 Hermes profile，讓每個主題可由擁有各自模型、skills、記憶與系統提示詞的專屬 agent 處理，取代目前需要為每個 profile 各自跑一個 bot token 與 gateway 行程的作法。此 issue 為開放狀態，處理狀態為調查中。
目前在 CLI、Telegram、iMessage 等不同平台使用 Hermes 時，各平台的 session 是各自獨立、互不相通的，使用者無法把在 CLI 進行到一半的工作接續到 Telegram 上，反之亦然。此 issue 提議建立內建的「交接」機制，讓使用者能在平台間保留任務描述與進度等狀態並無縫接續。
目前 Hermes 只能透過 /background 讓同一 agent 平行處理多個任務，但這個方式複雜任務下達麻煩、無法中途互動、且仍是單一佇列序列執行。此 issue 提議讓同一 Telegram 帳號下的多個 bot 各自連到同一個 gateway/agent，建立獨立 session，讓使用者能同時對不同任務進行完整互動。
目前只能用 /background 指令，但有下達任務麻煩、無法中途互動、且仍序列執行等限制。
這個 issue 指出目前用同一個 gateway 跑多個 Telegram 群組或 Discord 伺服器時，所有 session 都共用同一組人格、system prompt、CLAUDE.md 與工作目錄，無法針對不同群組或討論串客製化。提案在 config.yaml 新增 topic_configs 區塊，依平台與聊天室 ID 對應各自的設定覆寫。