Desktop 版:discovered_repos 快取在不同 profile 之間互相洩漏
Hermes Desktop 的檔案系統掃描器會把偵測到的所有 git repo 廣播給每個 profile 各自的資料庫,導致切換 profile 時會看到其他 profile 的 repo;根因是 projects.record_repos 處理常式用 replace=True 覆寫了整份清單。
終端機介面顯示與互動相關的官方 issue。 資料來自官方 GitHub repo,狀態由官方 label 推導,每筆附原始連結與最後檢查日期。
Hermes Desktop 的檔案系統掃描器會把偵測到的所有 git repo 廣播給每個 profile 各自的資料庫,導致切換 profile 時會看到其他 profile 的 repo;根因是 projects.record_repos 處理常式用 replace=True 覆寫了整份清單。
提案新增兩項目前 Hermes CLI/TUI 缺少、但 Claude Code 已有的體驗:滑鼠支援(點擊移動游標、展開收合區塊、捲動)以及選取文字自動複製到系統剪貼簿,藉此減少操作 CLI 時的摩擦。
回報者指出目前 hermes kanban ls 只能顯示靜態結果,需要手動重新執行才能看到進度,也沒有明顯區分「閒置」與「執行中」任務的視覺提示。提案新增 CLI 的自動刷新模式、TUI 看板中執行中任務的閃爍提示、狀態變化的 Telegram 通知,以及顯示 worker 的最後心跳時間。
此 issue 提出功能需求:目前 desktop 與 TUI 狀態列的 context window 使用量儀表只在 message.complete 時才更新,導致長時間的 agentic turn 期間畫面會凍結在前一輪的數值,直到結束才跳動一次。作者指出底層資料其實在每次內部 API 呼叫後都已更新,只是 gateway 沒有在 turn 進行中就傳遞出去。
用 delegate_task 派出 subagent 後,/agents 面板即使任務已完成並回傳結果,狀態仍固定顯示 running 不會更新成 completed 或 failed。此 issue 已關閉。
點擊 Hermes Desktop 的「Update」按鈕有時會顯示要求使用者到終端機執行 hermes update 的對話框,而非直接執行更新。原因是 resolveUpdaterBinary() 找不到已存在的 hermes-setup.exe,因為透過 CLI 執行 hermes update 重建 desktop 時不會重新複製這個檔案。
提案讓 Hermes Desktop 支援類似瀏覽器的「尋找」功能,可在聊天紀錄與 SOUL.md 等編輯器/設定介面中搜尋文字,具備反白標示、上一筆/下一筆導覽與符合筆數顯示等功能。
回報者指出在桌面版(與 TUI gateway)點擊任何舊對話續接時都會失敗並顯示「resume failed: No LLM provider configured」,即使目前設定的預設 provider 完全有效、開新對話也正常;同樣的 session 用 CLI 的 hermes chat --resume 卻能正常續接,僅桌面版/TUI 的 resume 路徑會失敗,回報者已定位到 server.py 中 _stored_session_runtime_overrides() 的 provider 讀取邏輯疑似有問題。
Hermes Desktop 目前對許多已知 provider 有內建 API key 欄位,但對自訂的 OpenAI 相容端點(如 AI Router、LiteLLM、自架 gateway 等)只有部分 UI 支援,使用者只能借用其他 provider 的欄位或手動編輯設定檔,容易造成混淆並限制模型清單。此 issue 提議在 Providers 設定中直接加入「Custom provider」選項,只需填 Base URL 與 API key。
目前只能借用 LM Studio 等其他 provider 的欄位,或手動編輯設定檔/環境變數。
這個 issue 指出 Hermes Desktop 目前聊天訊息的顯示欄位偏窄,在大螢幕上留下大量空白,在小螢幕上又容易造成過度換行,對有視力需求的使用者也不友善。提案新增可自訂的文字縮放與內文寬度設定。
回報者指出在 Hermes Desktop 中,即使在 Settings 中正確設定了新的 Working Directory 並寫入 config.yaml 的 terminal.cwd,若 renderer 端的 localStorage 已記住舊的 workspace 路徑,新 session 仍會在舊目錄啟動,造成 UI 顯示已設定新路徑但實際行為不一致。
這個 issue 指出目前與 Hermes Agent 的互動只能靠文字(CLI/TUI/IM 平台),沒有像真人對話般的即時語音互動方式。提案在終端機/TUI 中加入麥克風輸入、即時語音轉文字、低延遲回應與語音合成輸出的完整語音對話模式。
回報者指出在 macOS 的 --tui 模式下,即使使用內建 memory(未啟用 byterover),Python gateway 仍會在對話進行到一半時因「stdin EOF (TUI closed the command pipe)」而退出,12 小時內發生三次,回報者判斷此問題與另一個因 byterover 記憶外掛觸發 SIGPIPE 的既有 issue(#14036)不同。
使用者依照官方 Docker 文件更新 Unraid 範本,設定 HERMES_UID / HERMES_GID 並掛載共用磁碟區後,嘗試使用 Dashboard 內建的 Chat 功能時遇到權限被拒絕(permission denied)的錯誤。此 issue 已關閉,狀態為已修復。
回報者在官方 Docker 映像檔中發現,Dashboard 的內嵌 Chat 分頁首次連線會顯示「Chat unavailable: 1」,根因是 dashboard 以非 root 的 hermes 使用者執行,但 /opt/hermes/ui-tui/ 目錄及其 dist 內容在映像檔中屬於 root,導致首次建置 TUI bundle 時 esbuild 因權限不足(EACCES)寫入失敗。
hermes --tui 在快速拖拉調整終端機視窗大小後,畫面仍可能出現殘留或錯位的文字,這與先前 #14640 修復的同類 resize 問題相似,但在部分終端機環境下仍可重現。
此 issue 提議在 Hermes CLI/TUI 的輸入框中新增 Shift+Enter 作為換行按鍵。目前官方支援的多行輸入按鍵是 Alt+Enter 與 Ctrl+J,Enter 用於送出訊息;作者認為對許多終端機使用者來說,Shift+Enter 是更直覺、更符合聊天 App 習慣的「換行不送出」按鍵,並提議在終端機支援時新增此綁定,同時保留 Alt+Enter / Ctrl+J 作為備援。此 issue 已關閉。