GitHub Repo
Hermes Agent Community Reports a Gap in MCP Token Refresh Timing; Idle Gateways May Need to Log In Again
A Hermes Agent community report on October 19 says idle connections may miss the refresh window when an MCP service’s access and refresh tokens expire at the same time. The reporter has proposed a draft patch, but upstream CI has not validated it and no fixed release has been confirmed.
On October 19, the Hermes Agent community reported an MCP OAuth connection issue: if a remote service’s access token and rotating refresh token expire at the same time, a client that waits until the access token expires to refresh may lose the authorization needed to refresh it as well. For unattended agent gateways, the next tool call may not recover on its own, requiring interactive login again. This is a newly published bug report; the attached logs are from October 16. Issue report
While connecting from a Linux host to a Hostinger-hosted MCP service, the reporter observed that both tokens had a lifetime of 3,600 seconds. The logs show that after a successful refresh, the next attempt occurred 60 minutes and 4 seconds later. The endpoint returned HTTP 400, followed by an error requiring browser authorization. The reported reproduction condition is to leave the connection idle until expiration, then have a keepalive signal or tool request trigger a delayed refresh. The report does not establish that all MCP services are affected. Report and reproduction conditions
The official documentation says Hermes uses OAuth authorization for HTTP MCP services, stores tokens for reuse across sessions, and normally refreshes them automatically; if refresh fails, it reauthorizes. The engineering issue raised by this report is therefore refresh scheduling: even with credentials persisted, a connection with no traffic for an extended period may miss the expiration window. For background agents that rely on remote tools, this means availability across token expiration still needs to be verified after login succeeds. MCP configuration documentation
The draft patch proposes refreshing early both during requests and while idle, while preserving cross-process coordination of token rotation and canceling refresh work on disconnect or shutdown. The reporter says 903 MCP tests passed locally, but the upstream workflow is still awaiting maintainer approval, so this should not be treated as official validation. Engineering teams should next watch whether the draft is merged, whether a release is published, and whether early refresh handles rotation races and transient network failures. The public evidence currently consists mainly of a single report and its description of testing. Proposed fix and validation status