When credentials had a refresh_token but credentials.expired was False
(e.g., token=None with no stored expiry), the refresh was skipped and
the server would start a new OAuth flow instead. This changes the
condition to attempt refresh whenever credentials are not valid and a
refresh_token is available, regardless of the expired flag.
When `create_oauth_flow()` is called without an explicit `code_verifier`
(i.e. during the initial auth flow in `start_auth_flow()`), the function
never sets `autogenerate_code_verifier=True` on the Flow constructor.
oauthlib 3.2+ automatically adds `code_challenge` to the authorization
URL at the session level, so Google expects a matching `code_verifier`
during the token exchange. However, since `Flow.code_verifier` remains
`None`, that `None` gets stored in the session store and later passed
back during the callback — causing Google to reject the token exchange
with `(invalid_grant) Missing code verifier`.
The fix adds `autogenerate_code_verifier=True` in the else branch so
the Flow object generates and exposes a proper PKCE code verifier that
gets stored and reused during the callback token exchange.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The store_session call in the OAuth 2.1 credential refresh path (get_credentials)
omits token_uri, client_id, client_secret, and issuer. These are stored as None,
causing subsequent refresh attempts to fail and forcing full re-authentication.
The correct pattern already exists in three other store_session calls in the same
file (lines 151, 522, 750) — this aligns the refresh path to match.
- Add WORKSPACE_MCP_CREDENTIALS_DIR as primary env var (preferred)
- Keep GOOGLE_MCP_CREDENTIALS_DIR for backward compatibility
- Add os.path.expanduser() to handle ~ in paths
- Add logging to show which credentials directory is being used
- Display credentials directory in startup configuration
This enables running multiple MCP instances with different Google
accounts by configuring separate credential directories.
Fixes#373
