登入、OAuth、API key 與供應商授權相關的官方 issue。 資料來自官方 GitHub repo，狀態由官方 label 推導，每筆附原始連結與最後檢查日期。
當 Hermes Dashboard 綁定在非 loopback 位址（如 0.0.0.0）且只設定 basic_auth 時，造訪根目錄會被導向 /auth/login?provider=basic 並呼叫 start_login()，但 basic auth provider 是密碼制而非 SSO，呼叫時會拋出 NotImplementedError 導致 500 錯誤，破壞了官方文件推薦的「零基礎設施」設定方式。
當 auxiliary.title_generation 設定為 minimax-oauth provider 時，Hermes 仍會嘗試讀取 MINIMAX-OAUTH_API_KEY 環境變數，即使該 provider 應該透過 hermes auth add 的 OAuth token 認證，導致標題產生功能報錯。
錯誤訊息本身建議可暫時用 hermes model 切換到其他 provider 以避開此錯誤。
當 Dashboard 已透過 Nous Portal OAuth 完成登入後，若在 dashboard 內點擊 provider（Nous Portal）登入，前端會因為要求 window.__HERMES_SESSION_TOKEN__（在 gated 認證模式下本來就不存在）而在呼叫後端之前就先失敗。
已通過 Signal adapter 層過濾（正確群組 + 有效 mention）的群組訊息，會在 authz_mixin.py 的授權層被判定為未授權，因為 platform_group_user_env_map 字典中沒有列出 Platform.SIGNAL 對應的環境變數，導致寄件者只會被拿去跟 SIGNAL_ALLOWED_USERS（通常只是 bot 自己的號碼）比對。
agent/redact.py 的 SendGrid 遮罩正規表示式在遇到第二個句點就停止匹配，導致三段式 SendGrid API key（SG.<key-id>.<key-secret>）中真正包含密鑰熵值的 key-secret 段完全沒有被遮罩，會在 log、對話紀錄等地方以明碼留存。回報者提出加入可選的第三段比對群組來修正此問題。
當 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 端點運作正常，可作為暫時繞過此重新導向錯誤的方式。
回報者指出 hermes_cli/config.py 中的 get_env_value_prefer_dotenv() 函式，當 get_secret(key) 找不到對應密鑰時會直接回傳 None，而不會如預期退回檢查 os.environ，導致透過 Bitwarden Secrets Manager 注入到環境變數、但未寫入 .env 或 secret scope 的密鑰無法被憑證解析流程找到。
回報者指出在非互動式的 hermes gateway run 情境下，即使已有 OAuth token 檔案，只要 refresh 或授權失敗就會落入需要瀏覽器回呼的流程，導致 gateway 在訊息平台啟動前卡住整個 callback timeout，且重試會因為連接埠被佔用而失敗。此 issue 已關閉。
此 issue 回報 hermes_cli/dashboard_auth/audit.py 在寫入 dashboard-auth.log 時使用純 append 方式，沒有設定檔案大小上限或輪替（rotation），與系統中其他 log（如 agent.log、errors.log）不同。作者指出在高流量的 dashboard 環境下，此檔案會隨著 install 的生命週期無限成長。
此 issue 回報啟用 security.redact_secrets: true 時，看起來像機密的字串會被替換成 *** ，但這個替換發生在真正交給 shell / interpreter 執行的指令文字本身，而不只是在 transcript 和 log 中。任何合法帶有類似密鑰格式字串的指令（例如 Authorization header 或內嵌常數）執行後會損毀，出現看似程式錯誤的失敗，作者提供了跨 8 週、至少 14 個 session 的觀察案例。
從另一台機器（如筆電連區網上的 Mac）存取遠端 desktop / dashboard 時，session 會在下一個 access token 更新窗口附近反覆過期，UI 只提供 Retry / Repair install / Use local 等選項，重新登入後撐不久又斷。
此 issue 回報 hermes_cli.auth._codex_device_code_login() 與 dashboard 的 Codex 完整登入 worker，在讀取 OpenAI Codex 裝置授權流程回傳的 JSON 時，使用不限大小的 httpx.Client.post(...).json() 呼叫，對於幾個授權相關端點的 200 回應沒有設定 byte 上限，可能讓惡意或異常的大型回應被完整緩衝解析。
內建的 Anthropic OAuth 登入流程在 token 交換階段失敗並回傳 404，根因是 Anthropic 現在會封鎖所有帶有 claude-cli/ 開頭 User-Agent 的 token 交換請求，不論版本號為何；回報者測試多種 User-Agent 字串驗證了這個結論。此 issue 已關閉。
回報者指出使用 OAuth 型 provider（如 openai-codex）的 cron 排程工作，在憑證池耗盡時會直接以 HTTP 429 錯誤失敗，而不會像一般 gateway/CLI 主對話那樣自動切換到設定好的 fallback_providers 備援鏈，因為 cron/scheduler.py 走的是不同的程式路徑。
Hermes 錯誤地將所有 openai-codex 帳號池憑證標記為已達速率限制，包含實際上仍有可用額度的第三個帳號；回報者懷疑是帳號池內部的重置時間戳記狀態管理有誤。
執行 hermes auth reset openai-codex 後 Hermes 立即恢復運作，並成功選到第三個可用的憑證。
Hermes 目前支援 Bitwarden Secrets Manager 作為外部機密來源，官方文件也表示歡迎提出其他後端需求。Proton Pass 最近推出 AI Access Tokens，提供唯讀 vault 存取、可設定過期時間、稽核紀錄與端對端加密，此 issue 提議將其新增為 Hermes 的機密來源後端。
回報者指出多個 profile 模式的 Hermes worker 各自使用獨立的 HERMES_HOME，導致 OAuth 憑證分散儲存，在使用會輪替或單次使用 refresh token 的 OAuth 服務時容易發生憑證衝突或更新失敗。提案是新增獨立的 HERMES_AUTH_HOME 環境變數，讓 profile 狀態隔離但共用同一個憑證儲存區。
目前 Hermes 的 MCP OAuth 只支援 http://127.0.0.1:8765/callback 這種本機 HTTP callback，許多 OAuth 服務（如 Salesforce 官方 MCP 流程）不接受這種格式。issue 提議在 config 增加 redirect_uri 覆寫選項以支援 HTTPS。
回報者在本機 macOS（非 Docker、非 WSL、非遠端主機）設定 xAI Grok OAuth 時，瀏覽器已顯示「xAI authorization received」的成功畫面，但 Hermes 仍拋出 xAI authorization timed out 的錯誤，且沒有任何 xAI 憑證被儲存；回報者指出這與文件中說明的遠端/SSH 情境（callback 根本傳不到 loopback listener）不同。
這個 issue 指出 xai-oauth provider 對持有一般 SuperGrok 訂閱（非 Heavy）的使用者，在推論時持續回傳 HTTP 403，OAuth 登入與 token 儲存流程本身正常，問題出在 xAI 後端目前似乎只放行 SuperGrok Heavy 方案，與官方公告及 Hermes 文件描述不符。此 issue 已關閉。
回報者指出更新 Hermes 後，Kanban 看板載入失敗並回傳 401 Unauthorized 錯誤，導致完全無法透過 dashboard 存取既有的 Kanban 工作佇列；回報者推測與同一波更新中出現的 Telegram 配對問題及 64K context 下限錯誤可能是同一批變更造成的。
使用者持有 Claude Max 20x 訂閱，並使用 ~/.claude/.credentials.json 中有效的 OAuth access token，但透過 Hermes 呼叫原生 Anthropic API（provider: anthropic）時，每個請求都收到 HTTP 400 錯誤，訊息顯示「額外用量已用完，請至 claude.ai/settings/usage 加購」。此 issue 已關閉，狀態為已修復。
Hermes 目前沒有可用的 Google Cloud Vertex AI 整合路徑，設定 google-vertex provider 時因缺少 OAuth 驗證機制而在每次 cron 執行時靜默失敗。回報者提到自己寫了一個 standalone proxy 處理服務帳號驗證與 token 更新，並透過現有 custom_providers 機制與 Hermes 整合，希望能將此方案貢獻回專案。
回報者提供了一個 standalone proxy（127.0.0.1:8787），處理 GCP 服務帳號驗證與 token 更新，透過 custom_providers 機制串接使用。
回報者在 Docker/Coolify 部署環境下，CLI 使用 openai-codex provider 可正常運作且 hermes status 顯示已登入，但透過 Telegram gateway 使用同一組憑證時卻收到「No Codex credentials stored」的錯誤。此 issue 已關閉。
Hermes 已有危險指令核准機制，但目前需要核准的指令樣式寫死在 tools/approval.py 原始碼中，使用者無法在不修改原始碼的情況下把特定於自己環境的指令（例如重啟 gateway 服務）標記為需要核准，也無法針對非系統層級危險、但在特定部署中具破壞性的操作設定規則。
目前只能在本機修改原始碼並維護 dirty diff、自建外部 runtime overlay/wrapper，或單純依賴 agent 的 memory / 指示來遵守規則。
此提案指出現有的 env scoping（#3628）與 PID namespace isolation（#4432）雖降低憑證外洩風險，但子行程仍可能存取到真實憑證值本身；提案建議在 HTTP 傳輸層攔截，讓真實憑證值永遠不出現在 agent 可存取的任何位置，才能從架構上根本防止 agent 讀取憑證。
這個 issue 指出 Hermes Agent 目前的 gateway 授權是二元制（全部允許或完全阻擋），沒有權限層級概念。提案為 Telegram、Discord、WhatsApp、Slack 等 gateway 平台導入分層權限系統（Owner、Admin、User、Guest），讓部署者能與他人共用 agent 卻不必開放完整終端機存取等高風險能力。