[RFC] feat(oauth): proactive token refresh to avoid re-auth on every session

[vincenzopalazzo]

Problem

Every time a new chat session starts, goose creates a fresh ExtensionManager that reconnects to all configured MCP extensions. For OAuth-protected servers (e.g. RUbe), the connection logic always attempts an unauthenticated request first, receives a 401, and then triggers the full browser-based OAuth flow — even when valid refresh tokens are already stored in the keyring.

This means users must re-authenticate via the browser on every single new chat, making OAuth MCP servers impractical to use.

Root Cause

The connection flow was:

New Session → ExtensionManager → connect (no auth) → 401 → oauth_flow() → browser popup

The oauth_flow() function already had the logic to load stored credentials and silently refresh tokens, but it was only ever called after getting a 401 rejection — never proactively.

Fix

Added a credential check before the unauthenticated connection attempt:

New Session → has_stored_credentials? 
  → YES: oauth_flow() → silent refresh → connect (authed) ✅
  → NO:  connect (no auth) → 401 → oauth_flow() → browser popup (same as before)

If the proactive refresh fails (e.g., network issue), it gracefully falls back to the existing unauthenticated → 401 → browser flow. No new failure modes.

Changes

1. oauth/persist.rs — Added has_stored_credentials() to check if OAuth credentials exist for an extension
2. extension_manager.rs — Before connecting, check for stored credentials and attempt silent refresh
3. extension_manager.rs — Extracted connect_with_auth() helper to eliminate duplicated auth client construction (was in 2 places)
4. oauth/mod.rs — Added diagnostic logging to surface refresh outcomes and token metadata

Diagnostic Logging

The new logging will tell you exactly what is happening:

Log	Meaning
Token refresh succeeded - has_refresh_token: true	Silent refresh works, no browser needed ✅
Token refresh succeeded - has_refresh_token: false	Access token refreshed, but no refresh token in response
Token refresh failed: No refresh token available	Server did not issue a refresh token — browser auth required every time
No stored credentials found	First time connecting to this server

Important Caveat

This fix is necessary but may not be sufficient for all OAuth MCP servers. The silent refresh only works if the server issues refresh tokens (long-lived tokens that can be exchanged for new access tokens). Some servers may only issue short-lived access tokens without refresh tokens — in that case, the diagnostic logging will show has_refresh_token: false and we will know a different approach is needed (e.g., persisting the full authorization session state, or background token refresh).

Testing

• cargo build -p goose ✅
• cargo clippy --all-targets -- -D warnings ✅ zero warnings
• cargo fmt ✅
• cargo test -p goose -- extension_manager ✅

[DOsinga]

Hey @vincenzopalazzo — nice idea here! The proactive token refresh to skip the unnecessary 401 → browser cycle is a real UX improvement. The connect_with_auth extraction is a clean DRY win too. A few things to tighten up before this is ready:

Logging is a bit heavy. There are 8 new log lines and several just narrate what the code is about to do (e.g. "Stored credentials found, attempting proactive token refresh", "No stored credentials found, starting browser OAuth flow"). The debug! block that logs has_refresh_token, expires_in, and scopes after browser auth is diagnostic info that's useful during development but not something we want in production. I'd keep the warn! on refresh failure (that's genuinely useful) and drop most of the rest.

has_stored_credentials duplicates existing logic. It reaches directly into Config::global() to do the same thing GooseCredentialStore::load() already does. Could you reuse the existing CredentialStore trait instead? Something like instantiating a GooseCredentialStore and calling .load().await — that way if the storage mechanism ever changes, there's only one place to update.

Looking forward to the next iteration!

[vincenzopalazzo]

Re: review feedback from @DOsinga

Fixed in f44795c.

Two changes:

1. Logging trimmed. Dropped 6 info!/debug! lines that narrate control flow. Kept only the warn! on refresh failure — that one's genuinely useful.

2. has_stored_credentials removed. Replaced with GooseCredentialStore::new(name).load().await which reuses the existing CredentialStore trait. If the storage mechanism changes, there's one place to update.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity for 23 days.

What happens next?

• If no further activity occurs, this PR will be automatically closed in 7 days
• To keep this PR active, simply add a comment, push new commits, or add the keep-open label
• If you believe this PR was marked as stale in error, please comment and we'll review it

Thank you for your contribution! 🚀