Bug 回報（156 筆）

官方標記為 bug 的 issue 總覽。 資料來自官方 GitHub repo，狀態由官方 label 推導，每筆附原始連結與最後檢查日期。

#58345 有暫時解法 P2 comp/agent

[Bug] xAI grok-4.3 在 MCP 工具呼叫中丟失選填多行字串參數，AgentMail 寄出空白信

回報者發現在 provider xai-oauth 配 grok-4.3（codex_responses 模式）時，AgentMail 的 send_message 每次都寄出主旨與內文都空白的信，但工具回報成功，agent 無法自我修正。此 issue 由 AI agent 調查並代表帳號擁有者提交，附可重現的證據。

#58327 已修復 P1 comp/agent

[Bug] context 壓縮打斷 tool 訊息鏈，嚴格 provider 回 400（tool 訊息缺少對應 tool_calls）

長 session 觸發 context 壓縮時，可能把帶 tool_calls 的 assistant 訊息壓掉、留下孤兒 tool 訊息，違反 OpenAI Chat Completions 契約。DeepSeek 等嚴格 provider 會回 HTTP 400，寬鬆的 provider 可能默默吞掉。此 issue 已關閉。

#58322 討論中 P3 comp/plugins

Langfuse 追蹤（trace）在未設定 observability.service_name 時顯示 service.name=unknown_service

啟用 Langfuse observability plugin 但未設定 service name 時，OpenTelemetry 會 fallback 成 unknown_service，導致所有 agent 的 trace 混在同一個無法辨識的來源下。issue 提議讀取 config.yaml 的 observability.service_name，並在缺少設定時明確報錯而非靜默 fallback。

#58320 討論中 P3 comp/tools

web_search / web_extract 失敗時完全沒有提示，使用者可能不知道搜尋功能已失效

當未設定任何 web backend API key 時，web_search 和 web_extract 會靜默失敗或回傳空結果，不會提示使用者搜尋功能不可用，可能導致使用者數週都不知道核心搜尋功能已失效。issue 建議在失敗時回傳明確錯誤訊息與解決步驟。

#58317 有暫時解法 P2 comp/agent

壓縮功能當機：_summarize_tool_result 出現 AttributeError 'dict' object has no attribute 'count'

當 write_file 工具結果的 content 參數被解析成 dict 而非字串時，context compression 會在 _summarize_tool_result 拋出 AttributeError 而當機，導致壓縮功能完全失效，session 持續增長直到超過 context window。

#58309 有暫時解法 P2 comp/desktop

Desktop GUI 每 10 秒就會重新啟動一個 CLI process，導致重複的 plugin discovery

Hermes Desktop GUI 每約 10 秒就會產生一個新的 CLI process，每次都執行完整的 plugin discovery 流程，造成 agent.log 大量洗版以及不必要的 CPU / 磁碟資源消耗。

#58304 有暫時解法 P2 comp/desktop

Bug：使用本機模型端點時，TUI 非正常結束後 Desktop 啟動會無限卡住

當使用者在 TUI/CLI 用 /model 指向本機 loopback 端點（如 llama.cpp / ollama / vLLM）後非正常結束（Ctrl-C、關閉終端機、當機等），對應 session 在 state.db 中的 ended_at 會永遠是 NULL。下次啟動 desktop 時，後端會把這個未結束的 session 當成最新一筆並同步重試已失效的本機端點，導致 uvicorn 事件迴圈被卡住 60 到 100 秒以上，desktop 逾時顯示無法連線。

#58299 有暫時解法 P2 comp/gateway

send_message_tool 在裸平台目標下遺失 home.thread_id，訊息會跑到 DM lobby 而非設定的主題

使用 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> 可正常送達，避免使用裸平台目標。

#58298 有暫時解法 P2 comp/agent

Subagent 委派（delegation）忽略設定，永遠使用 credential pool 裡的 glm-4-flash 模型

即使將 delegation 設定為指定的 provider / 模型（如 NVIDIA NIM 的 deepseek-v4-flash），subagent 仍完全忽略該設定，永遠使用 credential pool 中的 glm-4-flash（Zhipu）。issue 附上 5 次測試皆重現此問題，包含 delegation 設定為空時也未如預期繼承 parent 模型。

#58290 有暫時解法 P2 comp/cli

Bug：用 /model xxx --provider xxx 切換模型時，即使沒加 --global 也會自動改寫 config.yaml

使用者透過飛書（feishu）與 hermes agent 對話，發送 /model xxx --provider xxxx 切換模型時，agent 會自動把這個模型與 provider 設成 config.yaml 的預設值（並回覆「Saved to config.yaml (--global)」），但使用者並未輸入 --global 參數，預期應該只改變當前執行期的模型設定。

學校診斷與解法
#58281 有暫時解法 P2 comp/tools

Bug：停用 coding toolset 會連帶悄悄移除已明確啟用的 terminal / file 工具，導致模型收到 Tools: 0

當 config.yaml 的 agent.disabled_toolsets 包含複合 toolset（如 coding）時，Hermes 會扣除該複合 toolset 底下所有工具，即使使用者已明確啟用 terminal 和 file 這兩個子 toolset，最終結果是模型收到零個工具，過程中沒有任何警告，UI 上（/toolsets、hermes tools）仍顯示 terminal 和 file 是啟用的。

#58277 有暫時解法 P2 comp/cli

Bug：profile 的 config.yaml 中空的 YAML key（terminal:）會讓 load_cli_config 出現 TypeError 而當機

當 profile 的 config.yaml 出現 terminal:（有 key 但沒有值）這種空欄位時，YAML 會解析成 None，導致 load_cli_config() 用 defaults.get("terminal", {}) 拿到的是 None 而非預期的空字典，後續判斷式因此拋出 TypeError，使 agent 在第一輪對話前就直接當機。

學校診斷與解法
#58275 討論中 P3 comp/desktop

Windows 上 hermes desktop 啟動器不會與終端機分離，關閉終端機會殺掉 Electron / Python process 並留下殘留程序

在 Windows 上，hermes desktop 會把 Electron App 當成繼承父層 PowerShell console 的子程序啟動，導致關閉父層終端機視窗時 Electron App 也會一併被砍掉，而且 Electron/Node 的 stdout/stderr（含編碼不一致造成的亂碼錯誤訊息）會洗版使用者的終端機。

#58270 已修復 P1 comp/gateway

fix(telegram)：reconnect 流程中的 updater.stop() 在 CLOSE-WAIT socket 上會卡住，heartbeat loop 可能卡好幾小時

_polling_heartbeat_loop 偵測到 CLOSE-WAIT socket 後會觸發 _handle_polling_network_error，但裡面呼叫 app.updater.stop() 沒有設定 timeout。如果底層 TCP 連線卡在 CLOSE-WAIT，polling task 會卡在 epoll 上永遠不會醒來，導致 stop() 永久掛住，後續 reconnect 永遠不會被觸發，訊息會被靜默丟棄長達數小時直到手動重啟。

#58269 討論中 P3 comp/plugins

[feishu] 移除過時的表格轉純文字 fallback，post(md) 現已支援 GFM 表格

Feishu adapter 偵測到 markdown 表格語法時，會把整則訊息強制轉成純文字類型，連表格以外的格式也一併被去除。這個行為是 2026-04-22 為了避免表格在 Feishu 端顯示空白而加入的，但回報者實測發現用 text 類型送出表格反而完全沒有格式，懷疑目前 post 類型已可正確渲染 GFM 表格，加入這個 fallback 的原始判斷已不再成立。

#58265 有暫時解法 P2 comp/cli

Windows 上設定檔中未知的 provider key 觸發大量警告日誌，導致 log handler 鎖死並卡住 serve / gateway 事件迴圈

在 Windows 上，一個無害的自訂 config key 會讓 _normalize_custom_provider_entry() 在每次 load_picker_context() 呼叫時都印出警告，配合 Windows 上 concurrent-log-handler 的跨程序鎖，大量警告觸發 RuntimeError: Cannot acquire lock after 20 attempts 並重試，佔滿 CPU 並讓 asyncio 事件迴圈卡住約 14 秒，導致所有 desktop / TUI WebSocket 斷線，而 /health 端點仍顯示健康。

學校診斷與解法
#58259 已修復 P2 comp/gateway

Telegram 打字中提示（typing indicator）在 cron job 執行期間會一直顯示，而非只顯示到訊息送達為止（重複回報）

與 #58258 相同的 bug：cron job 透過 deliver: origin 送訊息到 Telegram 時，打字中提示會持續顯示到整個子程序結束，而非訊息送達後就消失，長時間背景工作會讓提示持續 30 到 60 分鐘以上。此 issue 已標記為重複並關閉。

#58258 有暫時解法 P2 comp/gateway

Telegram 打字中提示（typing indicator）在 cron job 執行期間會一直顯示，而非只顯示到訊息送達為止

當 cron job 透過 deliver: origin 送訊息到 Telegram 時，打字中提示會持續顯示到整個 cron job 子程序結束為止，而不是訊息送達後就消失。若 cron job 送出簡短通知後還繼續跑背景工作，使用者的 DM 就會持續顯示打字中長達 30 到 60 分鐘以上。

#58251 討論中 P3 comp/desktop

Desktop：已移除的輸入框附件在切換 session 後會重新出現

使用者在 composer 中點擊附件的關閉按鈕移除附件後，附件會先消失，但切到別的 session 再切回來時，被移除的附件卻會重新出現。根因是 removeComposerAttachment() 只更新記憶體中的 nanostore atom，沒有呼叫 stashSessionDraft() 把變更持久化到 localStorage。

#58237 有暫時解法 P2 comp/dashboard

Bug：只設定 basic auth 時，Dashboard 自動 SSO 導向會出現 500 錯誤

當 Hermes Dashboard 綁定在非 loopback 位址（如 0.0.0.0）且只設定 basic_auth 時，造訪根目錄會被導向 /auth/login?provider=basic 並呼叫 start_login()，但 basic auth provider 是密碼制而非 SSO，呼叫時會拋出 NotImplementedError 導致 500 錯誤，破壞了官方文件推薦的「零基礎設施」設定方式。

#58236 已修復 P1 comp/gateway

Telegram 連線卡在「attempt 1/8」永遠不動：s6 supervision 下 asyncio.wait_for 逾時機制失效

gateway 的 Telegram adapter 連線時卡在「Connecting to Telegram (attempt 1/8)...」，即使等超過 15 分鐘也不會拋出 TimeoutError，也不會重試。回報者在多種情境下做了診斷測試，發現問題只在特定執行環境（s6-overlay supervision）下才會出現。

#58231 有暫時解法 P2 comp/agent

[Bug] minimax-oauth provider 明明是 OAuth，卻仍要求設定 API key 環境變數

當 auxiliary.title_generation 設定為 minimax-oauth provider 時，Hermes 仍會嘗試讀取 MINIMAX-OAUTH_API_KEY 環境變數，即使該 provider 應該透過 hermes auth add 的 OAuth token 認證，導致標題產生功能報錯。

暫時解法

錯誤訊息本身建議可暫時用 hermes model 切換到其他 provider 以避開此錯誤。

#58226 有暫時解法 P2 comp/agent

Anthropic OAuth 用量顯示錯誤：低用量時段被誤算成 100% 已用

/usage 儀表板在 Anthropic OAuth 帳號用量極低（0~1%）時，會誤顯示為 100% 已用、0% 剩餘。原因是程式碼把 API 回傳、本身已是百分比的數值誤判為 0-1 的小數並乘以 100，造成換算錯誤，回報者也指出 Codex 那條路徑並沒有這個問題。

#58215 討論中 P3 comp/tui

Desktop 版：discovered_repos 快取在不同 profile 之間互相洩漏

Hermes Desktop 的檔案系統掃描器會把偵測到的所有 git repo 廣播給每個 profile 各自的資料庫，導致切換 profile 時會看到其他 profile 的 repo；根因是 projects.record_repos 處理常式用 replace=True 覆寫了整份清單。

#58207 有暫時解法 P2 comp/dashboard

[Bug] Dashboard 在 gated 模式下，provider 登入視窗因缺少舊版 session token 而失敗

當 Dashboard 已透過 Nous Portal OAuth 完成登入後，若在 dashboard 內點擊 provider（Nous Portal）登入，前端會因為要求 window.__HERMES_SESSION_TOKEN__（在 gated 認證模式下本來就不存在）而在呼叫後端之前就先失敗。

#58200 有暫時解法 P2 comp/agent

[Bug] 依文件設定 save_trajectories: true 後，Trajectory 檔案仍未產生

官方文件說明可透過 config.yml 設定 agent.save_trajectories: true 來啟用軌跡紀錄檔，但實際測試發現程式碼從未檢查這個設定，導致對話結束後不會產生任何 *.jsonl 軌跡檔案，在 CLI、TUI、Gateway 皆是如此。

#58185 有暫時解法 P2 comp/agent

[Bug] Bedrock 的 /model 選擇器會顯示無法使用的裸模型 ID，選到後還會被永久儲存

Bedrock provider 的 /model 選擇器會同時列出裸 foundation-model ID 與對應的 inference-profile ID，但在 on-demand 帳號下裸 ID 無法呼叫；一旦選到裸 ID 會被寫入 config.yaml 的 model.default，導致之後每次呼叫都收到 HTTP 400 錯誤。回報者指出安裝精靈其實已經有處理這個問題（會過濾掉裸 ID），但 /model 選擇器路徑沒有套用同樣的去重邏輯。

#58184 有暫時解法 P2 comp/gateway

cronjob deliver=origin 不稳定：Yuanbao WS断连时投递失败

## 现象 在 Yuanbao 平台创建 cronjob 时用 `deliver=origin`，投递时好时坏。看日志基本就是两种结果： 1. 正常投递（live adapter 路径命中） 2.

#58175 有暫時解法 P2 comp/gateway

Signal 群組訊息通過 adapter 過濾後，仍被 _is_user_authorized 擋下

已通過 Signal adapter 層過濾（正確群組 + 有效 mention）的群組訊息，會在 authz_mixin.py 的授權層被判定為未授權，因為 platform_group_user_env_map 字典中沒有列出 Platform.SIGNAL 對應的環境變數，導致寄件者只會被拿去跟 SIGNAL_ALLOWED_USERS（通常只是 bot 自己的號碼）比對。

#58172 有暫時解法 P2 comp/cli

[Setup] hermes update 會讓 .git 目錄無限膨脹，長期運行的 VPS 磁碟空間被吃光

每次執行 hermes update 都會新增 git object 但從未清理舊物件，長期運行數月後 .git 目錄膨脹到 884MB（29GB 磁碟），加上 npm 快取與 session 檔案，磁碟使用率一度達 86%，讓後續升級變得有風險。

暫時解法

回報者手動執行 git gc --aggressive 將 .git 目錄從 884MB 縮減到 592MB，但這不在 update 流程中，需要自行定期執行。

學校診斷與解法
#58168 已修復 P1 comp/agent

長時間對話經過多次 context compaction 後，訊息序列變成無效格式，導致 session 永久失效（DeepSeek）

trajectory_compressor 在執行 context compaction 後，會產生不合法的訊息序列（孤兒 tool 訊息），造成 DeepSeek API 以 HTTP 400 拒絕請求，錯誤訊息為「tool 角色訊息必須回應前一則帶 tool_calls 的訊息」；長時間運行、累積大量工具呼叫訊息的 session 在多次壓縮後會完全無法繼續對話。此 issue 已關閉。

#58166 有暫時解法 P2 comp/dashboard

fix(dashboard-auth): Dashboard 設定 basic auth 時，GET /auth/login?provider=basic 回傳 HTTP 500

當 dashboard 設定為使用內建的 basic auth（帳號密碼）provider 時，透過 OAuth 風格的 GET /auth/login?provider=basic 重新導向會回傳 HTTP 500，而不是顯示密碼登入表單；根因是 auth_login() handler 對所有 provider 都統一呼叫 start_login()，但 BasicAuthProvider.start_login() 一律拋出 NotImplementedError。

暫時解法

密碼登入本身的 POST /auth/password-login 端點運作正常，可作為暫時繞過此重新導向錯誤的方式。

#58150 有暫時解法 P2 comp/cli

[Bug] Hermes 在 Windows 上使用系統內建的 Node.js，而非自帶的 Node.js

回報者指出更新 Windows 系統自身的 Node.js 版本後，Hermes 會使用系統的 Node.js 而非內建版本，因版本不同導致終端機視窗持續閃爍。預期行為是 Hermes 應一律使用其內建的 Node.js。

學校診斷與解法
#58149 討論中 P3 tool/web

[Bug] unbroker 技能實測發現：web_extract 功能受限、broker 涵蓋範圍缺口、subagent 紀錄可靠度與缺少的 broker 參考資料

回報者實際對一名菲律賓籍對象執行 unbroker 技能，掃描涵蓋 51 個資料仲介商但遇到多個結構性問題：文件宣稱 web_extract 可直接讀取頁面，但實際後端是僅能搜尋的 DuckDuckGo，無法擷取任意網址內容；51 個仲介商中有 12 個因資料中心 IP 被反機器人機制擋下；部分仲介商缺少對應的 JSON 參考紀錄檔。

#58135 有暫時解法 P2 comp/agent

[Bug] is_container() 在跑 Docker 容器的主機上誤判為容器內部，導致 home_mode: auto 的子行程 HOME 不穩定，使瀏覽器自動啟動出現「找不到 Chrome」

回報者指出 hermes_constants.is_container() 在 cgroup v2 主機上會掃描 /proc/self/mountinfo 尋找 containerd 等關鍵字判斷是否身處容器內，但只要主機上正在執行任何使用 containerd 快照的 Docker 容器，該容器的 overlay 掛載資訊就會誤觸發這個判斷，讓一般 host 被誤判為容器，且此結果會被快取整個程式生命週期，進而造成瀏覽器功能找不到 Chrome。

#58117 有暫時解法 P2 comp/agent

[Bug] Thinking 區塊導致 CLI 模式文字回應變空白，並引發無限心跳迴圈

回報者指出使用 DeepSeek 等預設啟用 thinking 區塊的模型時，agent 的文字回應無法傳送給使用者，只會顯示終端機工具的輸出結果；在 cron/心跳排程情境下，因使用者看不到回應而無法給出新指示，導致 agent 反覆觸發、耗費大量 API 費用並形成無限迴圈。

暫時解法

停用 thinking 區塊可讓文字正常送達，但目前沒有針對此設定提供獨立的開關選項。

#58116 已修復 P2 comp/gateway

[Bug] 即使設定 platforms.weixin.enabled: false，只要環境變數存在 WEIXIN_* 仍會被忽略並照常連線

回報者指出在 config.yaml 設定 platforms.weixin.enabled: false 後，只要 .env 中仍存在 WEIXIN_ACCOUNT_ID、WEIXIN_TOKEN 等環境變數，gateway 啟動時仍會照常連上微信/iLink 平台，未遵守 enabled: false 的設定。此 issue 已關閉。

#58105 有暫時解法 P2 comp/agent

[Bug] 訊息路由錯誤：使用者輸入被送到錯的 session

回報者指出在 Hermes TUI 中，於某個 session（Session A）輸入的訊息卻被錯誤地送到另一個 session（Session B），Session B 的 AI 因此回應了原本要給 Session A 的任務，而 Session A 沒有收到任何回應。

#58100 有暫時解法 P2 comp/cli

[Bug] get_env_value_prefer_dotenv 在 get_secret 回傳 None 時直接回傳 None，而不會退回讀取 os.environ

回報者指出 hermes_cli/config.py 中的 get_env_value_prefer_dotenv() 函式，當 get_secret(key) 找不到對應密鑰時會直接回傳 None，而不會如預期退回檢查 os.environ，導致透過 Bitwarden Secrets Manager 注入到環境變數、但未寫入 .env 或 secret scope 的密鑰無法被憑證解析流程找到。

學校診斷與解法
#58087 有暫時解法 P2 comp/agent

[Bug] Ollama/GLM provider 對簡短完整回應誤判 finish_reason='length'，觸發多餘的續寫重試

回報者指出當 agent 產生很短但完整的最終回應時，對話迴圈的 finish_reason == length 截斷處理邏輯仍會誤判並注入「回應被截斷，請繼續」的系統訊息，導致 agent 在 Telegram 上重複傳送同一則簡短回應 2 到 3 次。

#58081 有暫時解法 P2 comp/gateway

[Bug] Responses API 的壓縮後對話紀錄未正確存入 ResponseStore，導致重複壓縮迴圈

回報者指出使用 POST /v1/responses 搭配 previous_response_id 串接對話時，一旦觸發上下文壓縮，儲存的 conversation_history 會把原始未壓縮紀錄與壓縮後的內容混在一起，導致儲存內容持續膨脹；下一次請求載入這份膨脹過的紀錄後又再次觸發壓縮，形成無限重複壓縮的迴圈。

#58049 有暫時解法 P2 comp/gateway

v0.18.0：QQBot adapter 因缺少 is_reconnect 參數而無法連線

升級到 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 都已支援。

#58032 有暫時解法 P2 comp/gateway

Bug: multiplex_profiles 設為 false 後仍留下孤兒 session，導致訊息路由到錯誤 profile

把 gateway.multiplex_profiles 從 true 改回 false 後，先前在多工模式下建立的 profile session 仍殘留在共用的 state.db 中，gateway 會持續讀到這些過期 session 並把訊息路由到錯誤的 profile，即使該 profile 的 gateway 已停用。

#58010 已修復 P1 comp/gateway

[Bug] AsyncSessionDB 讓 /resume 指令壞掉：slash_commands.py 缺少 await

回報者指出 AsyncSessionDB 把 SessionDB 的每個方法都包成非同步協程，但 slash_commands.py 呼叫這些方法時忘記加上 await，導致執行 /resume 指令時拋出 TypeError: coroutine object is not subscriptable。此 issue 已關閉。

#57903 已修復 P2 comp/agent

[Bug] 非同步 LLM 呼叫透過忙碌輪詢阻塞桌面版 WebSocket 主迴圈

回報者最初懷疑 interruptible_api_call 中 300ms 的忙碌輪詢拖慢主執行緒，但經過超過 4 小時的深入調查，確認真正原因是 Anthropic SDK 串流消費端在解析大量 SSE chunk 時造成的 worker 執行緒 GIL 競爭，導致主執行緒長時間無法取得 GIL。此 issue 已關閉。

#57845 已修復 comp/agent

[Bug] Envelope 快取版面在工具迴圈中的快取斷點失效，造成 OpenRouter 與 Claude 輸入成本增加約兩倍

回報者指出在 OpenRouter/envelope 快取版面下，system_and_3 策略把快取斷點放在 tool 訊息與內容為空的 assistant 訊息上，但這兩種訊息實際上無法有效承載快取標記，導致 agent 迴圈中除了 system prompt 之外的快取斷點全部靜默失效，整段對話每次都以全額輸入價格重新計費。此 issue 已關閉。

#57836 已修復 P2 comp/gateway

[Bug] 無互動模式下 MCP OAuth 因快取過期的 token 卡住 gateway 啟動

回報者指出在非互動式的 hermes gateway run 情境下，即使已有 OAuth token 檔案，只要 refresh 或授權失敗就會落入需要瀏覽器回呼的流程，導致 gateway 在訊息平台啟動前卡住整個 callback timeout，且重試會因為連接埠被佔用而失敗。此 issue 已關閉。

#57749 討論中 P3 comp/dashboard

dashboard-auth.log 沒有輪替機制，檔案會無限成長

此 issue 回報 hermes_cli/dashboard_auth/audit.py 在寫入 dashboard-auth.log 時使用純 append 方式，沒有設定檔案大小上限或輪替（rotation），與系統中其他 log（如 agent.log、errors.log）不同。作者指出在高流量的 dashboard 環境下，此檔案會隨著 install 的生命週期無限成長。

#57740 討論中 P3 comp/agent

Session JSON transcript 匯出功能未過濾 PII（email / SSN 等）

此 issue 回報 agent/redact.py 目前只遮蔽密鑰、token 等機密資訊，但沒有涵蓋一般 PII（如 email 或身分證字號）。作者指出 state.db 本身不做遮蔽是設計上合理的，但選擇性開啟的 JSON transcript 匯出功能（sessions.write_json_snapshots，預設為 False）在寫入 session_{id}.json 時同樣缺少這類 PII 的遮蔽，屬於實際的落差。

#57739 有暫時解法 P2 comp/gateway

[Bug] macOS gateway 陷入重啟迴圈：launchd plist 寫死 --replace，SIGTERM 結束碼錯誤

此 issue 回報在 macOS（Sequoia 15.7.3）上，當外部觸發（如 launchctl kickstart -k）殺掉 Hermes gateway 行程後，gateway 會陷入約 8-10 秒一次的無限重啟迴圈，單一 session 中記錄到超過 400 次 SIGTERM 事件。

#57736 有暫時解法 P2 comp/cron

HERMES_CRON_SESSION 被設成行程全域變數，導致互動式 gateway session 誤套用 cron 核准政策

此 issue 回報 cron/scheduler.py 會將 os.environ["HERMES_CRON_SESSION"] 設為行程層級的全域變數。由於 cron 工作是在長駐的 gateway 行程中執行，此變數一旦被第一個 cron job 設定，就會持續影響到後續所有互動式 session（例如使用者正在使用的 Telegram 對話），使其被核准層誤判為 cron session。在預設的 approvals.cron_mode: deny 下，會導致 execute_code 在真人使用者在場的對話中被永久封鎖。

暫時解法

錯誤訊息中提及可將 approvals.cron_mode 設為 approve 以避免 execute_code 被封鎖，但這只是繞過核准機制的權宜設定，非根本修復。

#57735 有暫時解法 P2 tool/terminal

security.redact_secrets 會改寫實際執行的指令內容，而不只是遮蔽 log

此 issue 回報啟用 security.redact_secrets: true 時，看起來像機密的字串會被替換成 *** ，但這個替換發生在真正交給 shell / interpreter 執行的指令文字本身，而不只是在 transcript 和 log 中。任何合法帶有類似密鑰格式字串的指令（例如 Authorization header 或內嵌常數）執行後會損毀，出現看似程式錯誤的失敗，作者提供了跨 8 週、至少 14 個 session 的觀察案例。

#57705 討論中 P3 comp/cli

[Bug] 新增指定的 address model API 時出現錯誤，無法運作

此 issue 標題回報使用者在嘗試新增某個 address model API 時遇到錯誤且功能無法運作，內文僅附上一個外部文件連結與一張截圖，未提供進一步文字說明。

學校診斷與解法
#57581 已修復 P3 comp/tools

[Bug] 由 plugin 註冊的 web provider 無法透過 web.extract_backend 選用

回報者指出當 web.extract_backend 設定為由 plugin 註冊的 provider 名稱（而非內建後端）時，該設定會被靜默忽略，web_extract() 會轉而使用自動偵測到的其他後端，且不會顯示任何錯誤或警告提示使用者。此 issue 已關閉。

#57228 有暫時解法 P2 comp/agent

MCP stdio 子程序在長時間運作的 worker 中重新連線時會洩漏，孤兒程序持續累積直到 DB 爭用

長時間執行的 Hermes worker 會累積孤兒 MCP stdio 子程序，案例中單一 worker process 累積了 53 個 mimir 子程序，共佔用 1.4GB RSS 與大量檔案描述符，全部搶同一個 SQLite DB，超過約 50 個子程序後會造成 DB handle 爭用，導致 memory 工具呼叫間歇性失敗，但 hermes mcp test mimir 仍顯示健康。

#56058 討論中 P3 comp/desktop

[Bug] 桌面版聊天模型選擇器會寫入全域設定，而非只影響當前 session

回報者指出在 Windows 上使用 Hermes 桌面版狀態列的聊天模型選擇器切換模型時，會直接修改全域的 ~/.hermes/config.yaml，而非按文件所述僅套用於當前 session；預期應該只有透過 Settings → Model 才會變更全域預設值。

#55725 討論中 P3 comp/desktop

[Bug] 側欄建立 worktree 後，session 同時出現在新 worktree 群組與 main 群組

在桌面版側欄用 fork 按鈕建立 worktree 並開始對話後，新 session 會同時顯示在新 worktree 群組和 main 分支群組底下，離開專案視圖再進來才會恢復正常。

暫時解法

離開專案視圖再重新進入，分組會恢復正常。

#55712 有暫時解法 P2 comp/dashboard

[Bug] 遠端 dashboard session 因 refresh token 輪替重放而反覆過期

從另一台機器（如筆電連區網上的 Mac）存取遠端 desktop / dashboard 時，session 會在下一個 access token 更新窗口附近反覆過期，UI 只提供 Retry / Repair install / Use local 等選項，重新登入後撐不久又斷。

#55698 討論中 P3 comp/gateway

[Bug] Telegram 本地 Bot API 的影片檔快取失敗（method not found），變成空白訊息

Telegram gateway 配本地 telegram-bot-api --local 伺服器時，iOS .MOV 等影片文件下載會報 InvalidToken: Not Found: method not found。檔案其實已在本地儲存，但 Hermes 沒把路徑映射回可讀檔案，結果是空白的使用者訊息或只剩 metadata。

#55697 有暫時解法 P2 tool/file

[Bug] read_file 少算 total_lines，檔案結尾沒換行時可能默默丟掉最後一行

read_file 用 wc -l 計算行數，對最後一行沒有換行符的檔案會少算一行；當那一行剛好落在分頁邊界，讀取還會標記完成（truncated=False），模型以為讀完整份檔案，實際上默默漏掉最後一行。

#55677 已修復 P2 comp/agent

[Bug] context 壓縮在第 2、3 次觸發時報 Jinja 模板錯誤並毀損 session

用 LMStudio 自架模型時，內部 context 壓縮流程在第二或第三次觸發時，會因 No user query found in messages 的 Jinja 模板錯誤而崩潰，session 毀損、對話連續性遺失，只能開新 session。此 issue 已關閉。

#55658 有暫時解法 P2 comp/desktop

[Bug] 更新後無法啟動

此 issue 標題回報更新後應用程式無法啟動，內文僅附上一張截圖，未提供文字描述。

#55253 討論中 P3 comp/cli

OpenAI Codex 裝置授權（device-auth）JSON 回應讀取沒有大小上限

此 issue 回報 hermes_cli.auth._codex_device_code_login() 與 dashboard 的 Codex 完整登入 worker，在讀取 OpenAI Codex 裝置授權流程回傳的 JSON 時，使用不限大小的 httpx.Client.post(...).json() 呼叫，對於幾個授權相關端點的 200 回應沒有設定 byte 上限，可能讓惡意或異常的大型回應被完整緩衝解析。

學校診斷與解法
#55248 討論中 P3 comp/plugins

Codex 圖片生成的 SSE 串流解析沒有大小上限

此 issue 回報內建的 openai-codex 圖片生成 provider 在解析成功的 Codex Responses SSE 串流時，使用 iter_lines() 逐行累積 data: 內容，但沒有針對單一 SSE 行、單一累積事件或整體串流內容設定上限，可能導致惡意或異常的串流讓緩衝持續累積直到耗盡記憶體。

#55239 有暫時解法 P2 comp/gateway

Slack 過期的 thread session 會壓抑 reset 後應該重新帶入的 thread context

此 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 歷史內容。

#54220 已修復 P2 comp/agent

追蹤 Issue：Windows 桌面版 GUI 產生子行程時，主控台視窗（cmd/conhost/git/gh/powershell）會閃現

此為彙總約 25 篇回報的追蹤 issue，說明 Windows 桌面版 GUI 在無視窗的 pythonw.exe 後端呼叫 cmd.exe、git.exe、gh.exe、powershell.exe 等主控台子行程時，因未加上無視窗旗標，導致黑色主控台視窗閃現，有時甚至持續閃現；內文整理了曾嘗試並回退的修復方式，以及依實際原始碼與 git 歷史驗證過、目前仍有問題的產生點。

#52914 有暫時解法 P2 comp/gateway

[Bug] QQBot adapter 的 connect() 缺少 is_reconnect 參數，導致無窮重試迴圈

使用者更新到某個 commit 之後的版本，QQBot 的 gateway 進入無窮重試迴圈，無法連線，錯誤訊息顯示 QQAdapter.connect() 收到未預期的關鍵字參數 is_reconnect。此 issue 為開放狀態，處理狀態為 workaround。

#52523 已修復 P2 comp/cron

用 --no-agent --script 建立 cron job 失敗，錯誤「'str' object has no attribute 'exists'」

回報者在 Windows 環境下用 hermes cron create 搭配 --no-agent --script 建立純腳本排程任務時，程式在驗證排程前就因型別錯誤而失敗，回報者認為這是 cron job 建立流程中的 schema 或 runtime 型別問題，而非使用者輸入錯誤。

#52401 有暫時解法 P2 comp/cron

[Bug] macOS 桌面版：非預設 profile 會看到 default profile 的 session 與 cron（跨 profile 資料外洩）

在 macOS 桌面版切到自建 profile（例如只設定 WeChat 的 rucy）時，UI 仍會顯示屬於 default profile 的 sessions、通訊頻道與 cron jobs，屬於 UI 層的跨 profile 資料外洩。

#52318 已修復 P3 comp/tui

[Bug] /agents TUI 指令不更新 subagent 完成狀態，一直卡在 running

用 delegate_task 派出 subagent 後，/agents 面板即使任務已完成並回傳結果，狀態仍固定顯示 running 不會更新成 completed 或 failed。此 issue 已關閉。

#52060 已修復 P2 comp/gateway

Cron 排程訊息投遞到 Telegram 私訊主題時，錯誤地被導向 General 主題

自從某次修正（#22773）後，cron 排程投遞到 Telegram 私訊（DM）forum 主題的訊息會被導向 General/主要主題，而非目標主題，即使 cron 設定的投遞目標本身是正確的；根因是 cron/scheduler.py 對「私訊主題」的分類判斷邏輯有誤。此 issue 已關閉。

#50663 已修復 P2 comp/agent

z.ai 在「尖峰時段」對 hermes agent 做速率限制（429 錯誤）

使用 Max coding plan 搭配 glm-5.2 時，z.ai 在尖峰時段會限制 hermes agent，回傳 429 錯誤（1302/1305），但同帳號下的 opencode 和 claude 不受影響。回報者懷疑是 z.ai 依請求簽章辨識出 hermes 而限速。此 issue 已關閉。

#48534 已修復 P1 comp/agent

Anthropic Max OAuth 登入失敗：token 交換回傳 404（Anthropic 封鎖了 claude-cli/ User-Agent）

內建的 Anthropic OAuth 登入流程在 token 交換階段失敗並回傳 404，根因是 Anthropic 現在會封鎖所有帶有 claude-cli/ 開頭 User-Agent 的 token 交換請求，不論版本號為何；回報者測試多種 User-Agent 字串驗證了這個結論。此 issue 已關閉。

#48056 有暫時解法 P2 comp/gateway

Cron 排程訊息投遞到 Telegram 私訊主題（DM topic）時，常會跳出該主題

當 cron 排程訊息指定投遞到 Telegram 私訊（DM）的特定主題時，由於路徑中只帶有一般的 thread_id、缺少私訊主題所需的中繼資料，Telegram adapter 可能拒絕或改成投遞到主題之外，導致訊息沒有出現在原本指定的主題中。

#47917 已修復 P1 comp/cli

[Bug] 更新後 Desktop build 失敗：electronDist does not exist（快取失效）

這個 issue 指出即使先前 PR #47276 的修復曾經成功，在拉取最新程式碼更新後 Desktop build 又再次失敗，因為更新過程會清除 Electron binary 快取，出現「electronDist does not exist」錯誤，顯示 #47266 的修復並未徹底解決問題。此 issue 已關閉。

學校診斷與解法
#46755 討論中 P3 comp/tui

Desktop 更新按鈕在透過 CLI 重建後仍顯示「請在終端機執行 hermes update」

點擊 Hermes Desktop 的「Update」按鈕有時會顯示要求使用者到終端機執行 hermes update 的對話框，而非直接執行更新。原因是 resolveUpdaterBinary() 找不到已存在的 hermes-setup.exe，因為透過 CLI 執行 hermes update 重建 desktop 時不會重新複製這個檔案。

#46742 已修復 P2 comp/desktop

[Bug] Ubuntu 26.04 桌面版更新時 Build failed，之後無法再啟動

在 Ubuntu 26.04 LTS 按桌面版右下角的更新按鈕後出現 Build failed，terminal 啟動 hermes desktop 報大量錯誤且無法再執行；CLI 的 hermes 指令仍正常。此 issue 已關閉。

#46511 有暫時解法 P2 comp/cron

[Bug] Cron 排程工作在 OAuth 憑證池耗盡時不會切換到備援 provider

回報者指出使用 OAuth 型 provider（如 openai-codex）的 cron 排程工作，在憑證池耗盡時會直接以 HTTP 429 錯誤失敗，而不會像一般 gateway/CLI 主對話那樣自動切換到設定好的 fallback_providers 備援鏈，因為 cron/scheduler.py 走的是不同的程式路徑。

#45058 已修復 P3 comp/tools

Bug：web_search / web_extract 在未經使用者同意下，未設定 API key 也會偷偷把流量導向 Parallel.ai

此 issue 指出某次 commit（PR #43798）改變了 web_search 與 web_extract 在沒有設定任何 backend 時的預設行為：以前預設會落到 firecrawl（沒設 API key 就會在呼叫時失敗），現在則會在使用者完全沒設定 API key、也沒設定 backend 的情況下，靜默把所有搜尋流量導向 Parallel 代管的 search.parallel.ai/mcp 端點，過程沒有任何提示或設定步驟，且後續兩次 commit 又進一步強化這個預設值以防止被覆寫。回報者認為這缺乏使用者同意，也沒有本機/離線 fallback。此 issue 已關閉。

#44562 討論中 P3 comp/desktop

Bug：前端當機，工具回傳非預期資料時出現 tapClientLookup Index out of bounds

在 Hermes Desktop GUI 中使用 skill_manage、memory 或 cronjob 等工具時，若工具回傳的資料結構與前端預期不符，前端會拋出 tapClientLookup: Index out of bounds 錯誤，導致聊天介面白屏或卡死。

#44022 已修復 P2 comp/gateway

桌面版/TUI 續接舊 session 時出現「No LLM provider configured」錯誤（session 只存了 billing_provider，如 custom 供應商）

回報者指出在桌面版（與 TUI gateway）點擊任何舊對話續接時都會失敗並顯示「resume failed: No LLM provider configured」，即使目前設定的預設 provider 完全有效、開新對話也正常；同樣的 session 用 CLI 的 hermes chat --resume 卻能正常續接，僅桌面版/TUI 的 resume 路徑會失敗，回報者已定位到 server.py 中 _stored_session_runtime_overrides() 的 provider 讀取邏輯疑似有問題。

#43747 有暫時解法 P2 comp/agent

[Bug] openai-codex 帳號池誤判健康帳號為額度用盡，執行 hermes auth reset 可恢復

Hermes 錯誤地將所有 openai-codex 帳號池憑證標記為已達速率限制，包含實際上仍有可用額度的第三個帳號；回報者懷疑是帳號池內部的重置時間戳記狀態管理有誤。

暫時解法

執行 hermes auth reset openai-codex 後 Hermes 立即恢復運作，並成功選到第三個可用的憑證。

#42961 有暫時解法 P2 comp/cli

[Bug] local 後端會忽略 terminal.cwd 設定，一律使用程式啟動時的目錄

回報者指出在 config.yaml 中設定 terminal.cwd 對 local 終端機後端完全無效，根因是 cli.py 中有一段無條件覆寫邏輯，當後端為 local 時會直接用 os.getcwd() 蓋掉設定值，導致該設定只在 docker、ssh 等非 local 後端才生效。

學校診斷與解法
#42187 討論中 P3 comp/gateway

修正：Codex gpt-5.5 自動調高上限通知在同一 gateway session 內重複出現

這個 issue 指出 Codex gpt-5.5 壓縮閾值自動調高的說明通知，在 gateway session 因重建（如 gateway 重啟、cache 失效）時會重複顯示給使用者，即使並非開啟新的可見 session。提案讓此通知在同一個持久 gateway session 中只顯示一次。

#40187 有暫時解法 P2 comp/cli

[Bug] 執行 hermes update / hermes desktop 時，桌面應用程式編譯失敗

使用者回報執行 hermes update 或 hermes desktop 進行 Electron 桌面應用程式最後編譯階段時發生錯誤；附上的 log 顯示 electron-builder 正在為 darwin arm64 平台下載並封裝 Electron 執行檔（標題標註為 Windows desktop app，但附上的 log 內容顯示的是 macOS/darwin 封裝流程）。此 issue 為開放狀態，處理狀態為 workaround。

學校診斷與解法
#38855 已修復 P1 comp/cli

桌面版「工作目錄」設定無法覆蓋殘留的舊 workspace cwd 記憶

回報者指出在 Hermes Desktop 中，即使在 Settings 中正確設定了新的 Working Directory 並寫入 config.yaml 的 terminal.cwd，若 renderer 端的 localStorage 已記住舊的 workspace 路徑，新 session 仍會在舊目錄啟動，造成 UI 顯示已設定新路徑但實際行為不一致。

學校診斷與解法
#38448 有暫時解法 P2 comp/cli

hermes -z（oneshot 模式）可能漏掉 MCP 工具，因為工具清單在 MCP 探索完成前就先被快照

在 hermes -z（oneshot 模式）下，即使 MCP server 通過 hermes mcp test 測試且能探索到工具，agent 實際可用的工具清單中卻沒有這些 MCP 工具。原因是 oneshot.py 在建立 AIAgent 時就已解析好工具清單，時間點在 MCP discovery 註冊動態工具之前，導致之後才加入的工具永遠不會被看到。

暫時解法

在 oneshot.py 解析平台工具集前先手動呼叫 discover_mcp_tools()，可讓 MCP 工具正常被找到，回報者確認本機測試有效。

學校診斷與解法
#38435 已修復 P3

Desktop 版貼上截圖時會重複附加兩份相同的圖片

在 Hermes desktop app 貼上截圖到聊天輸入框時，會附加兩份相同的截圖而非一份，回報者懷疑是重複的 paste/drop/clipboard 事件處理常式同時觸發所致。此 issue 已關閉。

#38240 討論中 P3 tool/skills

[skills-index-watchdog] Skills index 自動偵測到過期或降級（degraded）

自動化的 skills index 新鮮度探測失敗，狀態顯示為 degraded，詳細訊息為「github: 0 < 30」。此 issue 由 GitHub Actions 自動開啟，用來追蹤 /docs/api/skills-index.json 的重建是否正常，若問題未解決會持續重新開啟，目前狀態為調查中。

學校診斷與解法
#38129 討論中 P3 comp/cron

[Bug] Cron 排程工作會顯示 memory 工具，但實際執行時無法使用

回報者指出 cron 排程工作中 memory 工具雖然出現在可用工具清單，但實際呼叫時會失敗並顯示「Memory is not available」。原因是 cron 排程用 skip_memory=True 建立 AIAgent，但預設工具集仍繼承包含 memory 的核心工具，導致工具存在但無法使用。

#37906 有暫時解法 P2

[Bug] WhatsApp 的 send_message 工具無法識別 @lid JID、會誤傳到預設頻道，且原始電話號碼會觸發 jidDecode 錯誤

回報者指出 WhatsApp 傳訊功能有三個相關問題：聯絡人名稱解析出的 @lid JID 未被辨識，導致訊息被靜默轉發到預設聊天頻道；未加 + 號或無事先訊息紀錄的原始電話號碼會讓 Baileys 的 jidDecode 失敗並回傳 500 錯誤；_send_whatsapp 直接呼叫 bridge API，而非透過已具備完整處理邏輯的 live adapter。

#35876 有暫時解法 P2 comp/agent

修正（vision）：_resolve_single_provider 的 kwargs 回歸問題導致 Gemini 額度錯誤時 fallback_chain 靜默失敗

此 issue 回報當 Gemini 回傳 HTTP 429（額度用盡）時，vision fallback chain 嘗試透過 _resolve_single_provider 建立 xiaomi-tp、ollama 等備援 provider 的 client，但該函式沒有正確把 explicit_base_url / explicit_api_key 等參數轉傳給 resolve_provider_client，導致整個 fallback chain 對所有 provider 都靜默回傳 None，使用者只會看到原始的 Gemini 錯誤，看不到任何備援。

#34871 有暫時解法 P2 tool/mcp

執行 hermes mcp serve 出現 ModuleNotFoundError 找不到 mcp_serve 模組

標準 pip 安裝後啟動 MCP server 會因為模組路徑問題崩潰。官方標為 P2,代表有暫時解法可繞過。

暫時解法

確認以完整套件方式安裝,必要時重裝並清掉殘留快取再重啟。改完設定後記得重置 session 讓 MCP 重新載入。

學校診斷與解法
#34860 有暫時解法 P3 tool/skills

內建 skill 同步後會留下過期的 .bak 備份資料夾

Skill 同步留下殘留備份目錄,屬於 P3 低優先的清理性問題,不影響功能。

暫時解法

可手動清除殘留的 .bak 目錄,不影響 skill 正常運作。

學校診斷與解法
#34821 尚無解法 P1 comp/cli

Windows 安裝腳本 install.ps1 直接執行時報錯,無法同時使用 -Ensure 與 -Stage

Windows 安裝腳本在裸執行時參數衝突,官方標為 P1,代表這是會擋住安裝且目前沒有官方 workaround 的重大問題。

學校診斷與解法
#34071 已修復 P1

[Bug] v0.15.0 Docker image 缺少 stage2-hook.sh / main-wrapper.sh，container_boot 模組也被移除，導致啟動失敗

官方 nousresearch/hermes-agent:latest（v0.15.0）Docker image 啟動時發生三個初始化錯誤並以 exit code 127 結束：找不到 /opt/hermes/docker/stage2-hook.sh 與 main-wrapper.sh（原始碼中存在但未進到建置後的 image 裡），以及呼叫已在 v0.15.0 重構時被移除的 hermes_cli.container_boot 模組。此 issue 已關閉，狀態為已修復。

#33932 已修復 P1 comp/agent

OpenAI Codex provider 當機，錯誤「'NoneType' object is not iterable」（HTTP None）

回報者指出切換到 gpt-5.5（透過 OpenAI Codex provider，以 OAuth 訂閱登入）後，傳送第一則訊息就會立即觸發「Non-retryable error (HTTP None): 'NoneType' object is not iterable」的當機。雖然會自動 fallback，但 Codex provider 本身無法使用，回報者認為問題可能出在回應解析路徑。

#33334 已修復 P3 comp/plugins

[Bug] Kanban 資料庫損毀問題導致系統崩潰

使用者回報 Hermes 在處理大型任務並使用 Kanban 看板時會崩潰，經過數天排查後認為根因是 Kanban 使用的 SQLite 對檔案鎖定處理不佳：當多個 subagent 同時對同一筆看板資料（例如同一張母票）寫入更新時，資料庫會損毀，嚴重時資料庫會直接關閉，而 Hermes 的狀態也存放在同一個資料庫中，導致整個系統無法運作。此 issue 已關閉，狀態為已修復。

#33237 已修復 P3 comp/agent

[Bug] openai-codex 服務商每次請求都因 TypeError（'NoneType' object is not iterable）而崩潰（chatgpt.com 回傳的 output 為 null）

使用者回報在 gateway 重啟後，openai-codex 服務商每一次請求都會因 TypeError 崩潰，重新登入也無法解決，因為憑證池雖然重新填入卻立刻再次被抑制。根因是 chatgpt.com 的 Codex 端點在 response.completed 事件中回傳 output: null，OpenAI SDK 2.24.0 的 parse_response() 對 null 值做迴圈導致例外，此例外未被現有的錯誤處理攔截，被記錄為 HTTP None 並導致憑證池被抑制、耗盡。此 issue 已關閉，狀態為已修復。

#33075 已修復 P3 comp/agent

[Bug] Hermes v0.14.0 中 openai-codex/gpt-5.5 仍不穩定：subagent 幾乎都會連線逾時，官方 Codex CLI 卻正常

回報者指出在 Hermes v0.14.0 中使用 openai-codex/gpt-5.5 仍非常不穩定，主要 agent 約有五成機率遇到連線失敗，多個 subagent 同時執行時幾乎必定失敗，但同一台機器、同一網路、同一 ChatGPT/Codex 帳號下的官方 Codex CLI 卻能正常使用，導致 Hermes 的委派功能幾乎無法用這個 provider。此 issue 已關閉。

#32956 已修復 P3 comp/agent

Codex Responses 串流當機，錯誤 TypeError: 'NoneType' object is not iterable（openai-codex / chatgpt.com backend）

回報者透過外部檔案與截圖回報 Codex Responses 串流功能發生 TypeError: 'NoneType' object is not iterable 的當機，issue 本文未附詳細文字說明，細節放在附件檔案中。此 issue 被標記為重複（duplicate）。

#32903 已修復 P3 comp/agent

Bug：openai-codex provider 崩潰，SDK 的 parse_response 無法處理 Codex 後端回傳的 null output

此 issue 指出 Hermes v0.14.0 在使用 openai-codex provider 搭配 gpt-5.5 時，每次呼叫 hermes chat 都會噴出 'NoneType' object is not iterable。根因是 ChatGPT Codex 後端在 response.completed 的 SSE 串流事件中回傳 output: null，而 OpenAI Python SDK 的 parse_response()（openai/lib/_parsing/_responses.py:61）沒有做 null 檢查就直接對 response.output 跑迴圈，在 Hermes 自己的回填邏輯執行前就讓 stream parser 先崩潰。作者指出這會影響 2.38.0（含）以前的所有 OpenAI SDK 版本，並已在 openai-python 上游回報。此 issue 已關閉。

暫時解法

body 提供了直接修補已安裝 SDK 的 sed 指令，把 parse_response() 裡 for output in response.output: 改成加上 or [] 的 null 防護；但作者提醒此修補會被 hermes update 或 pip install openai 覆蓋掉。

#32892 已修復 P3 comp/agent

Bug：Hermes 使用 OpenAI Codex（ChatGPT）時噴出 'NoneType' object is not iterable 錯誤

此 issue 回報在使用 Provider 為 openai-codex、Model 為 gpt-5.5 時，透過 Telegram 或 CLI 傳送任何訊息都會噴出 'NoneType' object is not iterable 錯誤，並被當成不可重試的用戶端錯誤中斷。回報者認為 Hermes 呼叫 ChatGPT Codex 後端 API 端點時應妥善處理所有分支，不應因 Python 端的 None 值而直接出錯。此 issue 已關閉。

#32883 已修復 P2 comp/agent

修正 Codex stream 回傳 None 時的還原機制

此 issue 描述 OpenAI Codex Responses 後端在串流結束時可能回傳 response.output 為 None，導致 OpenAI SDK 的 stream parser 直接崩潰、被 Hermes 誤判為不可重試的用戶端錯誤。作者提出修補方式，包含從已串流的 output items / text delta / reasoning delta 回填缺漏的 output、在 SDK stream parser 崩潰時改用 responses.create(stream=True) 作為 fallback，並針對 output_text 的存取加上防護與新增回歸測試。此 issue 已關閉。

#32373 已修復 P2 comp/agent

套用 #31967/#32016 修復後，openai-codex / gpt-5.5 仍反覆卡在沒有 first byte

回報者指出即使已套用先前針對 Codex timeout 的修復（#31967、#32016），openai-codex / gpt-5.5 仍經常在串流開始前卡住，出現「No first byte from provider in 45s」的重試與斷線訊息，且此問題與舊有的 context 為 0 或 300 秒 stale timeout 不同。

#28823 有暫時解法 P2 comp/gateway

WhatsApp：回覆訊息的 quotedMessageId / context 沒有傳給 agent，導致回覆情境遺失

使用者在 WhatsApp 回覆（引用）特定訊息時，bridge 有擷取到 quotedMessageId 等 metadata，但 whatsapp.py adapter 會捨棄這些資訊，agent 只收到新的文字內容，看不到被引用的原始訊息。issue 指出這與 #27946（Matrix 的同類問題）屬於同一類 bug。

#27385 已修復 P2 comp/cli

macOS 上 xAI OAuth loopback：瀏覽器已收到回呼，但 Hermes 仍逾時

回報者在本機 macOS（非 Docker、非 WSL、非遠端主機）設定 xAI Grok OAuth 時，瀏覽器已顯示「xAI authorization received」的成功畫面，但 Hermes 仍拋出 xAI authorization timed out 的錯誤，且沒有任何 xAI 憑證被儲存；回報者指出這與文件中說明的遠端/SSH 情境（callback 根本傳不到 loopback listener）不同。

學校診斷與解法
#27282 已修復 P1 comp/gateway

--tui 模式下 gateway 會在對話中途因 stdin EOF 意外退出

回報者指出在 macOS 的 --tui 模式下，即使使用內建 memory（未啟用 byterover），Python gateway 仍會在對話進行到一半時因「stdin EOF (TUI closed the command pipe)」而退出，12 小時內發生三次，回報者判斷此問題與另一個因 byterover 記憶外掛觸發 SIGPIPE 的既有 issue（#14036）不同。

#26879 討論中 P3 comp/agent

[Bug] 同時設定 provider、base_url 與 api_key 時，auxiliary task 的 provider 身分會遺失

回報者指出當 auxiliary 任務（如 auxiliary.vision）同時設定 provider、base_url 和 api_key 時，provider 名稱會被系統忽略並強制改為 custom，導致原本針對特定 provider 的處理邏輯（如 ZAI vision 的 max_tokens 略過、Anthropic transport 偵測等）被跳過，引發後續錯誤。

#26847 已修復 P3

[Bug] xAI OAuth（xai-oauth）對一般 SuperGrok 訂閱者回傳 HTTP 403，後端疑似只放行 Heavy 方案

這個 issue 指出 xai-oauth provider 對持有一般 SuperGrok 訂閱（非 Heavy）的使用者，在推論時持續回傳 HTTP 403，OAuth 登入與 token 儲存流程本身正常，問題出在 xAI 後端目前似乎只放行 SuperGrok Heavy 方案，與官方公告及 Hermes 文件描述不符。此 issue 已關閉。

#26425 已修復 P2 comp/agent

Bug：「Response truncated due to output length limit」在 #7237 修復後仍然發生（重新開啟已關閉的 issue）

此 issue 指出「Response truncated due to output length limit」錯誤在先前 #7242 與 #9525 的修復（回應 #7237）之後仍然持續出現。#7237 曾被維護者以「這不是 bug，是 context window 限制」為由關閉，但作者指出關閉後累積的 10 多則留言與大量測試，在不同模型（包含 414k、131k token，甚至 Gemini 1.5 的 2M token）上都能重現此問題，顯示輸入 context 可能足夠，但輸出 token 上限或長工具輸出/摘要的接續邏輯可能有問題。作者附上針對大型 context 模型的新鮮 session 重現資料。此 issue 已關閉。

#26083 討論中 P3 comp/gateway

Microsoft Teams 平台外掛在內建 Python 3.11 環境下無法載入（microsoft-teams-apps 需要 Python 3.12 以上）

回報者依官方文件設定 Teams 平台後，gateway 始終無法綁定 3978 埠，原因是 Teams 外掛匯入的 microsoft-teams-apps 套件需要 Python 3.12 以上，但 Hermes 安裝程式建立的虛擬環境是 Python 3.11，即使系統上已有 Python 3.13 也未被 Hermes 使用。

#25495 已修復 P1 comp/gateway

[Bug] 官方 Docker image 中的 Matrix/Synapse 功能故障

使用者回報官方 Docker image 中 Matrix/Synapse 的 gateway 從某個版本之後開始故障，log 卡在「fixing ownership :1000」不再往下跑，但 bot 仍能發送訊息到 Matrix，只是不會回應頻道內的提示。使用者同時建議原生支援 Matrix 加密功能（可能缺少 mautrix 等套件）。此 issue 已關閉，狀態為已修復。

#24443 有暫時解法 P2 comp/agent

[Bug] MiMo 推理模型的 reasoning_content 未被保留，導致多輪對話失敗

回報者指出 MiMo 推理（thinking）模型在多輪對話中，前一輪 assistant 訊息的 reasoning_content 欄位沒有被保留並回傳給 API，而 MiMo 的 API 要求在 thinking 模式下必須回傳此欄位，因此後續請求會收到 400 錯誤。

#24186 已修復 P3 comp/plugins

Hermes 更新後 Kanban 版面載入出現 401 Unauthorized

回報者指出更新 Hermes 後，Kanban 看板載入失敗並回傳 401 Unauthorized 錯誤，導致完全無法透過 dashboard 存取既有的 Kanban 工作佇列；回報者推測與同一波更新中出現的 Telegram 配對問題及 64K context 下限錯誤可能是同一批變更造成的。

#24140 已修復 P1 comp/agent

所有模型被拒絕，錯誤「context window below minimum 64,000 tokens」，Telegram 完全癱瘓

回報者指出 Telegram bot 因 MiniMax-M2.7 與 kimi-k2.6（皆為 32,768 context）被 Hermes Agent 判定 context window 低於 64K 門檻而全面拒絕，導致 Telegram bot 與 cron job 同時失效。這些模型先前皆可正常運作，使用者並未變更任何設定。

#23402 已修復 P2 comp/tui

[Bug] 以 HERMES_UID 啟動 Docker 時，Dashboard 的 Chat 功能出現權限錯誤

使用者依照官方 Docker 文件更新 Unraid 範本，設定 HERMES_UID / HERMES_GID 並掛載共用磁碟區後，嘗試使用 Dashboard 內建的 Chat 功能時遇到權限被拒絕（permission denied）的錯誤。此 issue 已關閉，狀態為已修復。

#22714 已修復 P1 comp/gateway

Matrix gateway 缺乏頻內管道，讓下游 dispatcher 能做逐則訊息的 LLM 調度

回報者描述其部署架構在 Hermes 之後接了一個自訂的 OpenAI 相容 LLM dispatcher，依規則（如 context 大小、佇列優先權、安全邊界）在本地與雲端 LLM 之間路由請求；回報者指出目前 Matrix room 中使用者輸入的 /model 指令無法把路由決策帶給下游 dispatcher，缺少一個頻內管道能讓 dispatcher 依每則訊息做出正確的模型調度判斷。

#21444 已修復 P2 comp/agent

openai-codex / gpt-5.5 作為主要模型時，每次呼叫都會靜默卡住直到 stale timeout

回報者指出當主要模型設為 openai-codex / gpt-5.5 時，每次對話都會在約 300 秒的 non-streaming stale timeout 期間完全沒有任何回饋（無 token、無錯誤、無提示），之後才會觸發 fallback。同樣設定改用 gpt-5.4-codex 則能立即正常運作，顯示問題出在 Hermes 對 gpt-5.5 在 Codex 端點的請求建構方式。

#20500 已修復 P2 comp/tui

Docker 映像檔中 Dashboard 的 Chat 分頁因權限問題（EACCES）失敗

回報者在官方 Docker 映像檔中發現，Dashboard 的內嵌 Chat 分頁首次連線會顯示「Chat unavailable: 1」，根因是 dashboard 以非 root 的 hermes 使用者執行，但 /opt/hermes/ui-tui/ 目錄及其 dist 內容在映像檔中屬於 root，導致首次建置 TUI bundle 時 esbuild 因權限不足（EACCES）寫入失敗。

#18449 討論中 P3 comp/tui

TUI 快速調整終端機視窗大小後仍可能出現殘留 / 錯位的文字亂碼

hermes --tui 在快速拖拉調整終端機視窗大小後，畫面仍可能出現殘留或錯位的文字，這與先前 #14640 修復的同類 resize 問題相似，但在部分終端機環境下仍可重現。

#17199 有暫時解法 P2 comp/cli

deepseek provider：模型名稱正規化與 base_url 覆寫機制會破壞自訂端點（如 Volcengine ARK）設定

設定 Hermes 使用 deepseek provider 搭配自訂 OpenAI-compatible 端點（如 Volcengine ARK）時有兩個 bug：非標準模型名稱會被強制正規化成 deepseek-chat 導致遠端回傳 404；credential pool 的 base_url 每次啟動都會被硬編碼預設值覆寫，忽略 config.yaml 或 auth.json 中的自訂設定。

暫時解法

目前只有設定 DEEPSEEK_BASE_URL 環境變數能讓自訂端點生效，但官方文件並未將其列為正式設定方式。

學校診斷與解法
#15895 有暫時解法 P2 comp/agent

[Bug] google-gemini-cli 服務商觸發 429 錯誤，但 gquota 額度顯示正常

使用者更新到最新版 Hermes，且 /gquotas 顯示 Gemini AI Pro 額度充足，但使用 google-gemini-cli 服務商搭配 gemini 3.1 pro 模型測試訊息時仍收到 429 錯誤，額度顯示接近 98%。此 issue 為開放狀態，處理狀態為 workaround。

#15717 已修復 P2 comp/agent

[Bug] DeepSeek API 出現 400 錯誤：思考模式下的 reasoning_content 必須被送回 API

使用者回報搭配支援思考模式的 DeepSeek 模型（如 deepseek-v4-flash）時，Hermes 出現 HTTP 400 錯誤，訊息指出思考模式下的 reasoning_content 必須在後續請求中送回 API，但 Hermes 目前並未正確處理並回傳先前的 reasoning_content。此 issue 已關閉，狀態為已修復。

#15080 已修復 P1

[Bug] Claude Max 20x 訂閱搭配有效 OAuth token 呼叫原生 Anthropic API 時全部回傳 HTTP 400

使用者持有 Claude Max 20x 訂閱，並使用 ~/.claude/.credentials.json 中有效的 OAuth access token，但透過 Hermes 呼叫原生 Anthropic API（provider: anthropic）時，每個請求都收到 HTTP 400 錯誤，訊息顯示「額外用量已用完，請至 claude.ai/settings/usage 加購」。此 issue 已關閉，狀態為已修復。

#14420 已修復 P2 comp/agent

Hermes agent 無法根據先前的對話內容準確回答問題

使用者回報使用 hermes chat 搭配 ollama 自訂端點與 gemma4:e4b 本地模型時，agent 無法記住並根據先前對話（例如使用者告知的名字）回答後續問題，對話紀錄顯示前後回答不一致且答非所問。此 issue 已關閉，狀態為已修復。

#13834 有暫時解法 P2 comp/agent

在官方 Codex CLI 仍可正常運作的同一台機器/網路上，Hermes 的 openai-codex 服務商卻失敗

使用者回報在同一台 macOS 機器與同一個網路環境下，官方 codex CLI 用 ChatGPT 登入仍可正常完成回應，但 Hermes 設定為 openai-codex 服務商時卻反覆出現 APIConnectionError / APITimeoutError，最終顯示連線錯誤，顯示 Hermes 的 openai-codex 相容層與官方 Codex CLI 的傳輸方式並不等價。此 issue 為開放狀態，處理狀態為 workaround。

#12614 已修復

[Bug] 全新 Matrix 環境設定完成後，bot 收不到任何訊息（sync 停滯）

使用者在更新到最新版本後，於全新的 Debian 環境設定 Matrix bot，bot 能成功加入房間，但在關閉加密的情況下依然完全收不到或處理不了任何訊息，debug 模式下也沒有任何 inbound event 的 log，懷疑 sync 迴圈在約 30 秒後停滯或斷線。此 issue 已關閉，狀態為已修復。

#12058 已修復 P1 comp/cli

[Bug] OpenAI Codex OAuth 在 CLI 可正常登入，但 Telegram gateway 回報「未儲存 Codex 憑證」

回報者在 Docker/Coolify 部署環境下，CLI 使用 openai-codex provider 可正常運作且 hermes status 顯示已登入，但透過 Telegram gateway 使用同一組憑證時卻收到「No Codex credentials stored」的錯誤。此 issue 已關閉。

學校診斷與解法
#11179 已修復 P2 comp/agent

[Bug] 當終端 response.output 為 null 時，Responses 串流會崩潰

當某個 OpenAI 相容 provider 傳回有效的串流事件、但最終 response.completed 的 response.output 是 null 而非空陣列時，Hermes 既有針對空陣列的復原邏輯無法涵蓋這種情況，stream.get_final_response() 會在 Hermes 能補回串流輸出內容之前就先拋出例外。此 issue 與 #5879、#5689、#5730 屬於同一類 provider 相容性問題。此 issue 已關閉。

#10980 已修復 P2 comp/cli

[設定問題] 使用 Copilot 服務商時出現 APIConnectionError（API 呼叫失敗）

使用者在 MacBook M5、python3 3.9.6 環境下，用 hermes setup 設定好 Copilot 服務商後，於 hermes chat 中對話時反覆出現 APIConnectionError，重試 3 次後仍連線失敗。此 issue 已關閉，狀態為已修復。

暫時解法

使用者提到執行 `hermes update` 之後問題就解決了。

學校診斷與解法
#10210 已修復

[Bug] 使用 MiniMax M2.7 時持續出現 HTTP 529「伺服器叢集負載過高」錯誤

使用者回報透過 Hermes 呼叫 MiniMax M2.7（api.minimax.io/anthropic 端點）時，即使是中等使用量與短提示，也反覆收到 HTTP 529 Overloaded 錯誤，Hermes 內建的重試機制持續打到同樣的 529 錯誤，嚴重影響可用性，詢問這是否為 MiniMax 端的容量或路由問題。此 issue 已關閉，狀態為已修復。

#10149 已修復

Bug：已設定 OPENROUTER_API_KEY，卻仍收到「未設定 auxiliary LLM provider」警告

回報者在 .hermes/.env 中已設定 OPENROUTER_API_KEY，但執行 hermes 時仍收到「未設定 auxiliary LLM provider」的警告訊息（並附上截圖）。重現步驟是先用 hermes setup 把 model 設為 arcee-ai/trinity-large-preview:free，再設定 OpenRouter key，環境為 WSL Ubuntu 22.04、Hermes 版本 0.9.0。此 issue 已關閉。

#9792 已修復 P2 comp/cli

[Bug] virtualenv 遷移後，外部互動式 shell 找不到 hermes 指令

PR #8226 將 hermes 改裝進 /opt/hermes/.venv/ 這個 virtualenv 後，透過 entrypoint 啟動的主程式運作正常，但用 docker exec -it 等外部互動式 shell 進入 container 時，venv 未被啟用、PATH 也沒有加入 venv 路徑，導致出現「hermes: command not found」。此 issue 已關閉。

暫時解法

直接執行完整路徑 /opt/hermes/.venv/bin/hermes 可正常運作。

學校診斷與解法
#9549 有暫時解法 P2 comp/gateway

Feishu 訊息中的 Markdown 表格無法正確顯示

回報者指出 Feishu 不支援在訊息中渲染 markdown 表格，表格會以未轉換的原始文字顯示；因為 gateway/platforms/feishu.py 的 _build_markdown_post_payload() 只是把原始 markdown 包進 md 標籤，而 Feishu 的 md 標籤不支援表格語法，因此提議比照舊版 OpenClaw 的做法，把表格轉換成條列或程式碼區塊格式。

#9153 已修復 P2 comp/cli

Docker 映像檔缺少 'dashboard' 指令（最新映像檔無法使用 web UI）

nousresearch/hermes-agent:latest 這個 Docker Hub 映像檔沒有包含 dashboard（或 web）子指令，導致在 Coolify 等容器化環境中無法執行 web UI。回報者指出該指令已存在於 main 分支原始碼中，推測 Docker Hub 映像檔是用較舊的 commit 建置的。此 issue 已關閉。

學校診斷與解法
#8270 已修復 P1

所有 OpenRouter 模型都回傳 HTTP 400，但用 curl 測試同一組 API key 正常

回報者指出在全新安裝的 Hermes（WSL2 Ubuntu）中，所有 OpenRouter 模型呼叫都回傳 HTTP 400，hermes doctor 也顯示 OpenRouter API 為 HTTP 400，但用同一組 API key 以 curl 測試則能拿到正常回應。

#7893 已修復

[Bug] 使用原生 Gemini 服務商時出現 HTTP 400「收到多組驗證憑證」錯誤

使用者在 ~/.hermes/.env 設定 GEMINI_API_KEY 使用內建 Gemini 服務商時，Google AI Studio 端點回傳 HTTP 400 錯誤；改用一般 Google Cloud API key（AIzaS 開頭）而非 Vertex AI 產生的金鑰（AQ.Ab8 開頭）才能正常運作。此 issue 已關閉，狀態為已修復。

暫時解法

使用者提到的暫時解法是將金鑰改命名為 OPENAI_API_KEY，並改用單一 Bearer header 的方式設定 provider。

#7734 討論中

Feishu 外掛的兩個問題：授權按鈕錯誤，以及 topic 群組中錯誤建立新主題

回報者指出兩個 Feishu 相關問題：點擊 Feishu 授權卡片上的按鈕會出現錯誤；在已開啟 topic 的 Feishu 群組中，部分 Hermes 訊息仍會另外建立新的 topic 回覆，而非在既有 topic 內回覆。

#7556 討論中

[Bug] API server adapter 未遵守 display.show_reasoning 設定

這個 issue 指出 Hermes 的 display.show_reasoning 設定在 CLI 與訊息 gateway adapter 會正確顯示模型的推理過程，但 API server adapter（gateway/platforms/api_server.py）完全沒有實作這個邏輯，導致透過 OpenAI 相容介面（如 Open WebUI）連線的使用者永遠看不到推理內容。

#7237 已修復

[Bug] 錯誤訊息：Response truncated due to output length limit（回應因長度限制被截斷）

這個 issue 指出使用 Hermes Agent 進行 CLI 聊天或 gateway 訊息（Telegram/Discord/Slack）時，產生長篇回應常會遇到「Response truncated due to output length limit」錯誤，導致回應中途被截斷、破壞對話流程。此 issue 已關閉。

#6893 已修復

[Bug] 透過飛書/Lark gateway 核准危險指令時出現錯誤碼 200340

透過飛書 (Feishu/Lark) gateway 使用 Hermes 時，當需要人工核准的危險指令（例如刪除保護路徑下的檔案）觸發核准卡片後，點擊「Allow Once」「Session」「Always」「Deny」任一按鈕都會失敗並顯示錯誤碼 200340，任務因此卡住；同樣情境下改用 CLI/TUI 模式核准則能立即正常運作。此 issue 已關閉。

暫時解法

同樣情況下切換到 CLI/TUI 模式核准可以正常運作。

#6843 已修復

[Bug] 使用 zai/glm-5.1 對話時出現 UnicodeEncodeError

使用者在使用 zai 服務商的 glm-5.1 模型對話時，API 呼叫連續三次都因 UnicodeEncodeError 失敗，錯誤訊息顯示 ascii 編碼無法處理特定位置的字元，重試三次後最終失敗。此 issue 已關閉，狀態為已修復。

#6607 已修復 P3 comp/tools

checkpoint_manager 的 subprocess.run cwd 可能指向不存在的目錄，導致 FileNotFoundError

回報者指出 tools/checkpoint_manager.py 的 _run_git() 在呼叫 subprocess.run 時使用 Path(working_dir).resolve() 當作 cwd，但在 Linux/macOS 上即使目錄不存在，resolve() 仍會執行成功，導致 subprocess.run 拋出 FileNotFoundError；此錯誤雖被靜默捕捉並記錄，但代表 checkpoint 功能會在該目錄不存在時被悄悄停用。

#6147 已修復 P2 comp/cli

安裝程式卡在「Install ripgrep / ffmpeg [Y/n]」提示，鍵盤輸入無反應

回報者在 Windows 11 上以 curl | bash 安裝 Hermes 時，安裝程式進行到是否安裝 ripgrep 與 ffmpeg 的確認提示後卡住，終端機不接受任何鍵盤輸入（Enter、Y、n 皆無效），回報者已嘗試重開終端機、換終端機、重跑安裝程式皆無效。

學校診斷與解法
#5884 已修復 P1 comp/cli

[設定問題] OSError: [Errno 22] Invalid argument，prompt_toolkit 造成 hermes chat 崩潰

使用者啟動 hermes chat 後，畫面顯示歡迎訊息並提示 tirith 安全掃描器不可用，接著程式直接印出 Goodbye 並拋出例外，追溯訊息顯示是 asyncio selector 在處理檔案描述子時發生 KeyError，接著在 main.py 中引發另一個例外導致程式崩潰。此 issue 已關閉，狀態為已修復。

學校診斷與解法
#5819 已修復

[Bug] Matrix bot 能同步舊訊息，但完全不回應新訊息（無任何 log 輸出）

使用者設定 matrix.org bot 帳號後，bot 能成功登入、加入房間並同步舊訊息，但收到新訊息時完全沒有回應，即使開啟 DEBUG 等級的 log 也沒有任何輸出，改用 Access Token 登入方式同樣無效。此 issue 已關閉，狀態為已修復。

#5674 已修復

[Bug] Codex 突然開始回傳「empty/malformed response」錯誤

回報者原本使用 openai/codex 模型一整天都正常，但之後每則訊息都收到「Empty/malformed response，切換到 fallback」的錯誤，即使切換其他 OpenAI 模型也一樣，只有 Anthropic 等其他 provider 正常。回報者嘗試重新登入 codex、更新 Hermes、重啟 gateway 等方式都無法解決。此 issue 已關閉。

#5200 有暫時解法 P2 comp/agent

[文件] Context 檔案（AGENTS.md/SOUL.md）的說明文件與實際程式碼行為不一致

這個 issue 指出文件描述的三項行為與程式碼實作不符：AGENTS.md 文件說會遞迴合併子目錄設定，但程式碼只讀當前目錄；SOUL.md 文件說會先檢查 cwd 再 fallback 到 ~/.hermes/，但程式碼完全不讀 cwd；文件描述的 terminal.cwd 設定在 gateway/訊息模式下實際會被覆寫成 home 目錄。這導致 Telegram、Feishu、Discord 等訊息平台使用者無法真正使用 context 檔案。

#4807 已修復 P3 comp/cli

[Bug] CLI 在淺色/米色終端機背景下難以閱讀，缺少淺色模式支援

Hermes CLI 在淺色或米色背景的終端機上幾乎無法閱讀，所有內建 skin（default、ares、mono、slate、poseidon、sisyphus、charizard）都採用為深色背景設計的淺色文字，導致 banner、歡迎訊息、提示符號與使用者輸入文字幾乎看不見。此 issue 已關閉。

學校診斷與解法
#4178 已修復

從 0.5.0 升級到 0.6.0 時 python-olm 建置失敗

回報者在把 Hermes 從 0.5.0 更新到 0.6.0 的過程中，python-olm 套件因 CMake 版本相容性問題建置失敗，但回報者表示這個錯誤似乎沒有實際影響 Hermes agent 的運作。

#3002 有暫時解法 P2 comp/cli

設定精靈啟用 NeuTTS 時安裝失敗，錯誤「No module named pip」

回報者在全新安裝 Hermes 並於設定精靈中啟用 NeuTTS 後，安裝過程因虛擬環境內找不到 pip 模組而失敗，回報者推測系統可能只有 pip3 可用。

學校診斷與解法
#2943 已修復

[Bug] Discord gateway 出現 API 錯誤，cron 排程訊息無法送達

使用者回報排定的 cron job 無法將訊息送達指定的 Discord 頻道，不論是自動執行還是手動觸發都一樣；但透過在 Discord 上強制產生討論或手動測試訊息時卻可以正常送達。Gateway log 顯示 Discord API 回傳 404 錯誤。此 issue 已關閉，狀態為已修復。

#1083 已修復

[Bug] 設定 OpenRouter / Nvidia 自訂模型後，hermes chat 出現 BadRequestError（API 呼叫失敗）

使用者回報將 hermes 設定為透過 OpenRouter 使用自訂模型（如 minimax-m2.5）後，執行 hermes chat 時 API 呼叫失敗，出現 400 BadRequestError，且判定為不可重試的用戶端錯誤。此 issue 已關閉，狀態為已修復。

#747 已修復

Hermes agent 經常「忘記」自己有 shell 存取權限

回報者指出使用 ChatGPT/Codex 時，Hermes agent 會誤以為自己沒有 shell 存取權限，需要使用者不斷提醒才會執行本可直接用 shell 完成的任務，回報者質疑是否需要手動把「你有 shell 存取權限」寫進記憶體才能解決。

#464 已修復

[Bug] 游標閃爍或表情符號切換導致終端機提示框線一直閃爍

使用者反映在 ghostty 搭配 tmux（一般終端機也會發生）環境下使用 Hermes，游標閃爍會讓提示輸入框的邊框線跟著閃爍，希望能關閉游標閃爍或思考中表情符號輪播動畫。此 issue 已關閉。

其他分類

回官方 Issue 精選問答．看學校解法卡．常見問題排解