Remote MCP Server sessions refresh automatically and add a redirect confirmation step

The Remote MCP Server's OAuth flow has had several reliability and security improvements, changing how MCP client sessions stay authenticated.

Sessions refresh instead of expiring

Previously, a session was tied to a fixed 7-day refresh token, after which an MCP client had to go through the full interactive authorization flow again. Sessions are now refreshed continuously in the background: access tokens are short-lived (1 hour) and refresh tokens roll forward for up to 30 days of continued use, so an actively used agent no longer hits a hard weekly re-authentication wall.

Clients that use Dynamic Client Registration (DCR) get a similar improvement to their client registration. Previously, a registration could expire on a fixed schedule even while a client was in active use. Now, each successful token refresh extends the registration's lifetime, so long-running agents no longer lose access mid-session.

Transient upstream errors (rate limits, timeouts) no longer force a re-authentication either. The server now retries these automatically and only asks a client to re-authenticate when the underlying Buildkite session has genuinely expired.

New: confirm the redirect before returning to your MCP client

Authorizing an MCP client now shows a confirmation page with the client's name and redirect URL before completing the flow. You can confirm or deny the request from there.

Note: if your MCP client automates the authorization redirect, it should expect this extra confirmation step in the flow.

New: rate limiting on the token endpoint

The OAuth token endpoint now rate limits requests per client and grant type to protect against excessive or misbehaving retries. Clients that exceed the limit receive an HTTP 429 response and should back off and retry shortly after.

For more information, see the Remote MCP Server documentation.