GitHub Repo
Hermes Agent 社群回報 MCP 權杖更新時機缺口,閒置閘道可能須重新登入
10 月 19 日的 Hermes Agent 社群回報指出,當 MCP 服務的存取與更新權杖同時到期,閒置連線可能錯過更新時機。回報者已提出草稿修補,但上游 CI 尚未驗證,也未確認正式修復版本。

Hermes Agent 社群於 10 月 19 日提出 MCP OAuth 連線問題:若遠端服務發出的存取權杖與輪替式更新權杖同時到期,客戶端等到存取權杖過期才更新,就可能連更新授權也一併失去。對無人值守的代理閘道而言,下一次工具呼叫可能無法自行恢復,必須重新完成互動式登入。這是新公開的缺陷回報,所附實際日誌則來自 10 月 16 日。問題回報
回報者在 Linux 主機連接 Hostinger 託管 MCP 服務時,觀察到兩種權杖的有效期皆為 3,600 秒。日誌顯示,一次更新成功後,下一次嘗試發生在 60 分鐘又 4 秒之後,端點回傳 HTTP 400,後續出現需要瀏覽器授權的錯誤。其重現條件是讓連線保持閒置,直到過期後才由保活訊號或工具請求觸發延遲更新;目前不能據此推定所有 MCP 服務都受影響。回報與重現條件
官方文件說明,Hermes 對 HTTP MCP 服務使用 OAuth 授權流程,將權杖保存並跨工作階段重用,正常情況下會自動更新,更新失敗才重新授權。因此,這個回報揭露的工程問題是更新排程:即使憑證已持久化,長時間沒有流量的連線仍可能錯過有效期限。對依賴遠端工具的背景代理,這意味著登入成功後,仍須驗證跨越權杖期限的可用性。MCP 設定文件
草稿修補主張在請求與閒置期間都提前更新,同時保留跨程序的權杖輪替協調,並於斷線或關閉時取消更新工作。回報者稱本機 903 項 MCP 測試通過,但上游工作流程仍等待維護者核准,不能視為正式驗證。工程團隊接下來應關注草稿是否合併、發布版本,以及提前更新能否兼顧輪替競態與暫時性網路失敗;目前公開證據仍以單一回報及其測試說明為主。修補方向與驗證狀態