訊息路由、session 與各平台訊息收發相關的官方 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 分鐘以上。
Hermes 0.18 會在訊息送達（transform_llm_output 之後）的多個地方把對話內容寫入磁碟，卻都沒有提供 redaction hook 或保留期限（TTL）設定，包括 rich_sent_index.json 和 delivery mirror。對於使用 PII tokenization plugin（在送達時才還原 PII）的部署來說，這些是還原後 PII 唯一會落地到磁碟的地方。
gateway 的 Telegram adapter 連線時卡在「Connecting to Telegram (attempt 1/8)...」，即使等超過 15 分鐘也不會拋出 TimeoutError，也不會重試。回報者在多種情境下做了診斷測試，發現問題只在特定執行環境（s6-overlay supervision）下才會出現。
目前沒有辦法讓 assistant 直接操作即時開啟的 Excel 活頁簿，重度使用試算表的使用者（如會計、財務）必須先把資料匯出或貼出再貼回結果。提案建立 apps/excel/ 側車，透過 Office.js 工作窗格與零相依的 Node 橋接程式連到既有的 api_server，並嚴格限制只能透過結構化 JSON 動作合約讀寫試算表資料；作者提到此功能已在另一個 PR（#44356）實作並運作中。
本機 llama.cpp / vLLM 類伺服器只有在新請求與先前快取狀態的 prompt 前綴完全一致時才能重複使用 KV 快取，否則每個新 session 都要重新處理共用前綴（通常 1~2 萬 token），造成延遲。提案是新增一個選用的 gateway watcher，定期重放最小化請求讓共用前綴保持在快取中；作者提到此功能已在另一個 PR（#57019）實作並運作中。
BlueBubbles/iMessage 可能進入一種局部假健康的狀態：Messages.app 顯示已讀、gateway process 仍在跑、連接埠也開著，但 Hermes 實際上收不到任何 iMessage webhook 也不會回應。提案希望新增產品層級的健康檢查與分類後的復原機制，而非只依賴現有零散的個案修補。
## 现象 在 Yuanbao 平台创建 cronjob 时用 `deliver=origin`，投递时好时坏。看日志基本就是两种结果： 1. 正常投递（live adapter 路径命中） 2.
已通過 Signal adapter 層過濾（正確群組 + 有效 mention）的群組訊息，會在 authz_mixin.py 的授權層被判定為未授權，因為 platform_group_user_env_map 字典中沒有列出 Platform.SIGNAL 對應的環境變數，導致寄件者只會被拿去跟 SIGNAL_ALLOWED_USERS（通常只是 bot 自己的號碼）比對。
回報者指出在 config.yaml 設定 platforms.weixin.enabled: false 後，只要 .env 中仍存在 WEIXIN_ACCOUNT_ID、WEIXIN_TOKEN 等環境變數，gateway 啟動時仍會照常連上微信/iLink 平台，未遵守 enabled: false 的設定。此 issue 已關閉。
回報者指出使用 POST /v1/responses 搭配 previous_response_id 串接對話時，一旦觸發上下文壓縮，儲存的 conversation_history 會把原始未壓縮紀錄與壓縮後的內容混在一起，導致儲存內容持續膨脹；下一次請求載入這份膨脹過的紀錄後又再次觸發壓縮，形成無限重複壓縮的迴圈。
升級到 v0.18.0 後，QQ Bot adapter 啟動失敗並報錯「QQAdapter.connect() got an unexpected keyword argument 'is_reconnect'」，導致 gateway 啟動時沒有任何平台連線成功；根因是 gateway/run.py 會傳入 is_reconnect 參數給所有平台 adapter 的 connect()，但 QQ Bot adapter 尚未更新支援這個參數，其他平台的 adapter 都已支援。
把 gateway.multiplex_profiles 從 true 改回 false 後，先前在多工模式下建立的 profile session 仍殘留在共用的 state.db 中，gateway 會持續讀到這些過期 session 並把訊息路由到錯誤的 profile，即使該 profile 的 gateway 已停用。
回報者指出 AsyncSessionDB 把 SessionDB 的每個方法都包成非同步協程，但 slash_commands.py 呼叫這些方法時忘記加上 await，導致執行 /resume 指令時拋出 TypeError: coroutine object is not subscriptable。此 issue 已關閉。
回報者指出在非互動式的 hermes gateway run 情境下，即使已有 OAuth token 檔案，只要 refresh 或授權失敗就會落入需要瀏覽器回呼的流程，導致 gateway 在訊息平台啟動前卡住整個 callback timeout，且重試會因為連接埠被佔用而失敗。此 issue 已關閉。
此 issue 提出功能需求：目前 desktop 與 TUI 狀態列的 context window 使用量儀表只在 message.complete 時才更新，導致長時間的 agentic turn 期間畫面會凍結在前一輪的數值，直到結束才跳動一次。作者指出底層資料其實在每次內部 API 呼叫後都已更新，只是 gateway 沒有在 turn 進行中就傳遞出去。
此 issue 回報在 macOS（Sequoia 15.7.3）上，當外部觸發（如 launchctl kickstart -k）殺掉 Hermes gateway 行程後，gateway 會陷入約 8-10 秒一次的無限重啟迴圈，單一 session 中記錄到超過 400 次 SIGTERM 事件。
Telegram gateway 配本地 telegram-bot-api --local 伺服器時，iOS .MOV 等影片文件下載會報 InvalidToken: Not Found: method not found。檔案其實已在本地儲存，但 Hermes 沒把路徑映射回可讀檔案，結果是空白的使用者訊息或只剩 metadata。
此 issue 回報 SlackAdapter._has_active_session_for_thread() 只檢查 session key 是否存在於 SessionStore._entries，並沒有考慮該 session 是否已依 reset 政策（daily / idle / suspended）過期。實際訊息處理路徑呼叫 get_or_create_session() 時可能會把同一個 session key 換成全新的 session id，導致 Slack thread 在 session 重置後的第一輪對話，沒有依規則重新帶入先前的 thread 歷史內容。
此為彙總約 25 篇回報的追蹤 issue，說明 Windows 桌面版 GUI 在無視窗的 pythonw.exe 後端呼叫 cmd.exe、git.exe、gh.exe、powershell.exe 等主控台子行程時，因未加上無視窗旗標，導致黑色主控台視窗閃現，有時甚至持續閃現；內文整理了曾嘗試並回退的修復方式，以及依實際原始碼與 git 歷史驗證過、目前仍有問題的產生點。
使用者更新到某個 commit 之後的版本，QQBot 的 gateway 進入無窮重試迴圈，無法連線，錯誤訊息顯示 QQAdapter.connect() 收到未預期的關鍵字參數 is_reconnect。此 issue 為開放狀態，處理狀態為 workaround。
自從某次修正（#22773）後，cron 排程投遞到 Telegram 私訊（DM）forum 主題的訊息會被導向 General/主要主題，而非目標主題，即使 cron 設定的投遞目標本身是正確的；根因是 cron/scheduler.py 對「私訊主題」的分類判斷邏輯有誤。此 issue 已關閉。
回報者指出目前使用者在不同平台切換時，只有長期記憶與已儲存事實會延續，實際對話紀錄仍侷限在原本發生的平台上，導致上下文片段化，使用者必須重複資訊或手動請 agent 查詢過去 session。提案希望能有機制，讓其他平台/session 的相關對話內容可自動或依需求注入目前 session。
當 cron 排程訊息指定投遞到 Telegram 私訊（DM）的特定主題時，由於路徑中只帶有一般的 thread_id、缺少私訊主題所需的中繼資料，Telegram adapter 可能拒絕或改成投遞到主題之外，導致訊息沒有出現在原本指定的主題中。
這個 issue 指出 Telegram Bot API 10.1 新增了 RichMessage 等豐富訊息格式（標題、清單、表格、LaTeX 等區塊），提案讓 Hermes 的 Telegram gateway 支援這些新 API，取代目前 plain/MarkdownV2 訊息與逐則編輯的串流方式，讓輸出呈現更完整。
回報者指出在桌面版（與 TUI gateway）點擊任何舊對話續接時都會失敗並顯示「resume failed: No LLM provider configured」，即使目前設定的預設 provider 完全有效、開新對話也正常；同樣的 session 用 CLI 的 hermes chat --resume 卻能正常續接，僅桌面版/TUI 的 resume 路徑會失敗，回報者已定位到 server.py 中 _stored_session_runtime_overrides() 的 provider 讀取邏輯疑似有問題。
目前 gateway 在正規化收到的訊息時會捨棄 Telegram 原生的轉發訊息中繼資料（如 forward_origin），導致 agent 無法分辨使用者是自己輸入還是轉發他人訊息。提案新增一個平台中立的標註層來保留這類上下文。
這個 issue 指出 Codex gpt-5.5 壓縮閾值自動調高的說明通知，在 gateway session 因重建（如 gateway 重啟、cache 失效）時會重複顯示給使用者，即使並非開啟新的可見 session。提案讓此通知在同一個持久 gateway session 中只顯示一次。
當 Hermes Desktop 連到遠端 Hermes 後端時，目前只能看到 profile 清單，實際生效的 profile 仍取決於遠端後端啟動時的 HERMES_HOME/HERMES_PROFILE，Desktop 的 Profiles 頁面無法真正切換後端使用的 profile。此 issue 提議讓 Desktop UI 能直接切換遠端使用中的 profile。
這個 issue 指出 Hermes 目前的 memory 操作會繞過 hook 系統，導致無法在不修改核心程式碼的情況下做到租戶隔離。作者團隊釋出了開源專案 Hermes Swarm Map，擴充現有 Hermes 模式以支援多租戶環境下的權限控管，並提案將相關修改回饋（upstream）到 Hermes 核心。
作者表示已在正式環境自行維運修正版本數月，並釋出開源專案 Hermes Swarm Map 作為現階段的替代方案。
使用者在 WhatsApp 回覆（引用）特定訊息時，bridge 有擷取到 quotedMessageId 等 metadata，但 whatsapp.py adapter 會捨棄這些資訊，agent 只收到新的文字內容，看不到被引用的原始訊息。issue 指出這與 #27946（Matrix 的同類問題）屬於同一類 bug。
回報者指出在 macOS 的 --tui 模式下，即使使用內建 memory（未啟用 byterover），Python gateway 仍會在對話進行到一半時因「stdin EOF (TUI closed the command pipe)」而退出，12 小時內發生三次，回報者判斷此問題與另一個因 byterover 記憶外掛觸發 SIGPIPE 的既有 issue（#14036）不同。
回報者依官方文件設定 Teams 平台後，gateway 始終無法綁定 3978 埠，原因是 Teams 外掛匯入的 microsoft-teams-apps 套件需要 Python 3.12 以上，但 Hermes 安裝程式建立的虛擬環境是 Python 3.11，即使系統上已有 Python 3.13 也未被 Hermes 使用。
使用者回報官方 Docker image 中 Matrix/Synapse 的 gateway 從某個版本之後開始故障，log 卡在「fixing ownership :1000」不再往下跑，但 bot 仍能發送訊息到 Matrix，只是不會回應頻道內的提示。使用者同時建議原生支援 Matrix 加密功能（可能缺少 mautrix 等套件）。此 issue 已關閉，狀態為已修復。
回報者描述其部署架構在 Hermes 之後接了一個自訂的 OpenAI 相容 LLM dispatcher，依規則（如 context 大小、佇列優先權、安全邊界）在本地與雲端 LLM 之間路由請求；回報者指出目前 Matrix room 中使用者輸入的 /model 指令無法把路由決策帶給下游 dispatcher，缺少一個頻內管道能讓 dispatcher 依每則訊息做出正確的模型調度判斷。
提案根據 Telegram 於 2026 年 5 月 7 日釋出的一批新 AI bot 功能，建議 Hermes 導入其中幾項：Guest AI Bot（無需加入群組即可被 @mention 使用）、Bot-to-Bot 通訊（讓多 agent 工作流可直接在 Telegram 上互相對話協作）等，以強化 Hermes 的多 agent 與團隊協作情境。
此 issue 要求讓 Hermes 支援 TrueConf Server / Enterprise 平台作為訊息 gateway，使 TrueConf 使用者能直接與 Hermes agent 溝通，不需透過第三方 gateway。回報者指出 Python 已有現成的 python-trueconf-bot 函式庫，實作上應該相對直接。
Slack 的 mrkdwn 格式不支援 GitHub Flavored Markdown 的 pipe 表格語法，導致 Hermes 在 Slack 回覆包含表格的內容（例如工具比較）時，表格會以純文字管線符號顯示而非正常表格。此 issue 已關閉。
使用者反映 Hermes dashboard 目前是獨立行程，在 WSL 重啟或 gateway 當機後不會自動恢復，需手動重啟才能再次使用。提案建立獨立的 systemd 服務，讓 dashboard 在 gateway 之後自動啟動。
使用者提出功能需求，希望 Hermes 能有一套通用、跨平台的方式讓訊息附加互動式動作按鈕（尤其是 Telegram 的 inline keyboard），而不是針對特定功能（如模型選擇、指令核准）各自寫死邏輯，讓 agent 產生的訊息或排程訊息都能附上「是/否」「部署/取消」等按鈕選項。此 issue 為開放狀態，處理狀態為調查中。
使用者在同一個 Discord 頻道跑 3 個各自獨立的 Hermes agent 實例，遇到 agent 之間看不到彼此訊息、且容易觸發連鎖回覆的問題。issue 分享了作者自行實作的頻道歷史注入與連鎖回覆防止（mention-gating）解法，希望能貢獻回上游專案。
提案指出 Hermes 目前所有影像分析都會繞道經過輔助視覺模型（如 qwen3-vl），即使主模型本身具備原生視覺能力（如 gpt-4o、glm-5v-turbo、claude-sonnet-4）也是如此，造成額外延遲、成本與資訊流失；回報者提供了一套修改 4 個檔案的原生 vision bypass 參考實作，並在過程中發現了多個會影響任何多模態內容的 pipeline 問題。
回報者在 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 為開放狀態，處理狀態為調查中。
回報者指出 Feishu 不支援在訊息中渲染 markdown 表格，表格會以未轉換的原始文字顯示；因為 gateway/platforms/feishu.py 的 _build_markdown_post_payload() 只是把原始 markdown 包進 md 標籤，而 Feishu 的 md 標籤不支援表格語法，因此提議比照舊版 OpenClaw 的做法，把表格轉換成條列或程式碼區塊格式。
提案指出 Hermes 目前每個 agent 都需要獨立的 profile 與 gateway 行程，若要同時跑多個不同用途的 agent 就要開多個 process，各自佔用資源；提案參考 OpenClaw 的單一 daemon 架構，讓多個 agent 共用同一個 daemon 行程，各自擁有獨立 workspace 與記憶，並依 session key（含群組內 topic）路由訊息。
這個 issue 指出 Slack adapter 目前用舊版 mrkdwn 格式傳送訊息，不支援表格，且需要手動把標準 markdown 轉換成 Slack 的舊格式語法。Slack 現已提供原生支援標準 markdown（含表格）的 markdown block type，提案改用新格式，並同時修改 send()、edit_message()（串流訊息用）與 send_message_tool.py 三處。
目前在 CLI、Telegram、iMessage 等不同平台使用 Hermes 時，各平台的 session 是各自獨立、互不相通的，使用者無法把在 CLI 進行到一半的工作接續到 Telegram 上，反之亦然。此 issue 提議建立內建的「交接」機制，讓使用者能在平台間保留任務描述與進度等狀態並無縫接續。
目前 Hermes 只能透過 /background 讓同一 agent 平行處理多個任務，但這個方式複雜任務下達麻煩、無法中途互動、且仍是單一佇列序列執行。此 issue 提議讓同一 Telegram 帳號下的多個 bot 各自連到同一個 gateway/agent，建立獨立 session，讓使用者能同時對不同任務進行完整互動。
目前只能用 /background 指令，但有下達任務麻煩、無法中途互動、且仍序列執行等限制。
此 issue 提議讓 Hermes 支援原生多 agent 架構，讓單一 gateway process 能同時服務多個具名 agent，各自擁有獨立的 session、人格、記憶與工具設定，類似 OpenClaw 的多 agent 架構。作者指出目前 Hermes 是單一 agent 系統：session key 寫死帶 agent:main: 前綴（gateway/session.py:477-484）、SOUL.md 只從單一全域路徑（~/.hermes/SOUL.md）載入、記憶也是全域共用（~/.hermes/memories/），導致使用者同時討論多個不相關主題時 context 會混在一起、增加 token 消耗、降低推理品質，也無法讓使用者擁有各自專精不同領域的獨立 agent。
此 issue 提出功能需求：希望在 gateway 新增 Linear 平台的 adapter（gateway/platforms/linear.py），讓使用者可以直接在 Linear issue 留言中 @提及 agent 來調查問題、彙整相關 issue、更新狀態或提問，不需要切換到 Slack / Telegram / Discord。作者提出的方案包含 webhook 伺服器、HMAC-SHA256 簽章驗證、以及透過 GraphQL API 回覆留言等設計。
Hermes 的 cron 排程工作會在獨立的 session 中執行，執行結果送到 origin/home channel 時只有人類看得到，並附註「agent 無法看到這則訊息」，不會被寫進主要 gateway session 的對話紀錄，導致主 agent 常常不記得自己執行過排程任務，使用者得主動詢問才知道任務有沒有完成。
目前只能靠檔案系統交接（cron 把結果寫進共享的 .md 檔案），再由使用者手動要求主 agent 去讀這個檔案。
此 issue 描述把 Dreaming 打造成 Hermes 的正式一級功能，讓對話總結、分析與洞察產生這個反思模式能在 CLI 與 gateway（包含 Telegram 傳送）兩種執行路徑上穩定運作。內容包含讓 Dreaming 在正確的 runtime 設定下執行、不依賴工具呼叫、即使底層 agent 發生錯誤也能回傳可用的回應；具體改動包含新增專屬 Dreaming 流程、讓 Dreaming 同步執行、停用 Dreaming 的工具集使其保持反思與確定性、把 runtime/provider 設定傳入 Dreaming、移除傳入 AIAgent.run_conversation 的無效 session_id，並新增錯誤呈現機制與回歸測試。
這個 issue 指出文件描述的三項行為與程式碼實作不符：AGENTS.md 文件說會遞迴合併子目錄設定，但程式碼只讀當前目錄；SOUL.md 文件說會先檢查 cwd 再 fallback 到 ~/.hermes/，但程式碼完全不讀 cwd；文件描述的 terminal.cwd 設定在 gateway/訊息模式下實際會被覆寫成 home 目錄。這導致 Telegram、Feishu、Discord 等訊息平台使用者無法真正使用 context 檔案。
此 issue 提議讓使用者能定義多個具名「角色」（例如營養師、開發者、財務顧問），各自擁有專屬 session 與系統提示，並用一個輕量分類器（如 Gemini Flash）自動把訊息路由到對應角色，藉此解決目前 Hermes 所有話題共用單一 session、單一人格，導致不同主題互相污染 context、無法給予特定領域專長、且需要使用者手動用 /title、/resume 管理 session 的問題。作者註記此提案在 2026 年 5 月已針對 v0.14.0 架構大幅重寫為 v2 版本，取代舊版有缺陷的做法，改用更乾淨的 contextual classifier 與誤路由回復機制，原始 v1 提案保留在摺疊區塊作為歷史紀錄。
這個 issue 指出目前用同一個 gateway 跑多個 Telegram 群組或 Discord 伺服器時，所有 session 都共用同一組人格、system prompt、CLAUDE.md 與工作目錄，無法針對不同群組或討論串客製化。提案在 config.yaml 新增 topic_configs 區塊，依平台與聊天室 ID 對應各自的設定覆寫。
回報者希望 Hermes 能新增 Rocket.Chat 作為訊息 gateway 通道。
提案指出目前 gateway 對所有頻道只能使用同一組全域模型與 system prompt，但 Discord 或 Telegram 群組中不同頻道常有不同用途（如低成本摘要頻道、程式開發頻道、閒聊頻道），因此建議新增 channel_overrides 設定，讓每個頻道可個別指定模型、provider 與 system prompt，並定義優先順序（/model 指令高於 channel_overrides，channel_overrides 高於全域設定）。
這個 issue 指出 Hermes Agent 目前的 gateway 授權是二元制（全部允許或完全阻擋），沒有權限層級概念。提案為 Telegram、Discord、WhatsApp、Slack 等 gateway 平台導入分層權限系統（Owner、Admin、User、Guest），讓部署者能與他人共用 agent 卻不必開放完整終端機存取等高風險能力。
回報者希望 Hermes 能原生支援 Matrix 協定作為訊息 gateway，讓使用者可以透過任何 Matrix 客戶端（如 Element、FluffyChat）並連到自架的 homeserver 與 agent 互動，但表示自己目前沒時間貢獻程式碼實作。此 issue 已關閉。