[Plugin] Fix intermittent re-auth from cross-process refresh-token rotation

[pragati-agrawal-glean]

Problem

The plugin can intermittently ask the user to authenticate again — find_skills or run_tool returns [SETUP_REQUIRED] — even though another live plugin process has already refreshed the shared OAuth grant.

Root cause: cross-process refresh-token rotation

Each MCP session runs its own plugin process, but those processes share one credential file. The OAuth server rotates refresh tokens on every refresh and invalidates the presented refresh token. A sibling process can therefore retain a revoked refresh token in memory:

process A: refreshes R0 → receives A1/R1 → persists A1/R1
process B: still holds R0 → refreshes → invalid_grant or invalid_request

Without coordination, the losing process can clear the shared store and surface [SETUP_REQUIRED], potentially taking down the process that already has the valid rotated grant.

Fix

1. Treat the credential file as the source of truth. tokens() reloads credentials from disk on every access through syncTokensFromDisk(). Correctness no longer depends on file mtime, and there is no mtime-based synchronization or environment override.
2. Wait before clearing tokens. invalidateCredentials("tokens") waits for a sibling's changed access token for a fixed two-second grace period, polling every 100 ms. If the sibling grant appears, it is adopted; only an unchanged store is cleared.
3. Retry connect-level refresh failures. createRemoteClient() observes whether a newer access token appeared on disk and retries the connection once. It also handles raw structured OAuth errors with errorCode invalid_request or invalid_grant, rather than matching human-readable error messages.
4. Keep retries bounded and conservative. A retry requires a changed token and is limited to one attempt, so unrelated OAuth errors and repeated failures are not hidden or retried indefinitely.
5. Preserve atomic, private credential writes. Credential updates continue to use temp-file-plus-rename writes, with chmodSync(tmpPath, FILE_MODE) applied before the rename so temporary files are 0600 as well.

The registered OAuth client is not replaced during a sibling retry; the new MCP connection reuses the same provider and the newly persisted grant. DCR client reuse remains covered separately by #45.

Verification

Against the non-production SST endpoint:

https://salessavvy-test-be.glean.com/mcp/gateway/proxy

with client_api.oauth.accessToken.defaultExpiryMinutes=2:

• Two separate Claude Code processes were launched with --strict-mcp-config.
• Both processes used the candidate plugin MCP server and one shared test credential file.
• A newly issued access token reported expires_in=120 and the credential file remained mode 0600.
• After access-token expiry, both real MCP calls succeeded without [SETUP_REQUIRED].
• Local fingerprints confirmed that both the access token and rotated refresh token changed, while the registered client ID stayed stable.
• No raw credentials are included here.

Files

• src/auth-provider.ts: direct disk synchronization, fixed grace-window sibling adoption.
• src/remote-client.ts: structured OAuth-error handling and bounded sibling retry.
• src/token-store.ts: atomic credential persistence and temp-file permission hardening.
• Corresponding auth-provider, remote-client, and token-store tests.

— sent via Glean Desktop

[pragati-agrawal-glean]

Before changes:

After changes:

[pragati-agrawal-glean]

Simplified the implementation - removed the modified time based logic and added logic to always read the disk stored tokens before using them to ensure a process always has the latest tokens (This assumes new tokens will be written to disk within 2 seconds and the disk write will execute successfully)