[Plugin] Reuse the DCR client instead of re-registering on setup and abandoned sign-ins

[pragati-agrawal-glean]

Stacked on #44 (uses its syncFromDisk rails).

Problem

One user accumulated 34 "Glean Claude Code Plugin" clients in their authorized-apps list. Server side, /oauth/register never dedupes (it's a NoUserAuth endpoint — no user identity in scope, always mints name[:16]_uuidv4), and StaleOAuthClientDeleter reaps clients with no token issuance after 7 days — so every needless client-side registration either piles up as a UI row (consent lives 180d) or becomes a future invalid_client loop.

Log correlation proved the client-side triggers: every setup.configured / setup.reset was followed by a new client_id 6–9 seconds later (6 wipes → 6 clients on one day alone).

Fixes

1. Ordinary setup reuses the DCR client. Re-running setup with the same server and no reset — the dominant trigger, fed by the [SETUP_REQUIRED] → agent-calls-setup loop — keeps the existing client_id and does not burn another registration.
2. reset=true is an explicit full reset. It clears the saved URL, grant, remote-tool cache, and registered DCR client. The next setup intentionally registers a new client. This matches reset semantics for a clean reconfiguration.
3. Abandoned sign-ins retry the existing client (abandonPendingSignIn budget) instead of invalidateCredentials("all") → fresh DCR. Full re-registration remains the escalation path after repeated failures with the same client — the signature of a client actually rejected server-side (e.g. reaped as never-used).
4. clientInformation() syncs from the shared store, so concurrently-starting sessions can't both register (the SDK registers whenever it returns undefined).
5. Registrations are now logged ([auth] Registered OAuth client: ) — they were previously invisible, which is why this needed forensic log correlation to find.

Verification

Automated checks

• 8 auth-hardening unit tests added in this branch; 224 tests passed.
• npm run typecheck passed.
• npm test passed.
• npm run build passed.
• git diff --check passed.

Existing E2E verification

• E2E on exp pod 117: one client (…0ae0d4a0) survived a full day of refresh-race testing — sign-in, a bug-induced token wipe, re-sign-in, six refresh rotations — zero new registrations (see [Plugin] Fix intermittent re-auth from cross-process refresh-token rotation #44 for the race E2E itself).

Local DCR validation

The local validation used the current PR branch at commit 815f4d8, installed from the local marketplace, and an isolated store:

• SST MCP endpoint: https://salessavvy-test-be.glean.com/mcp/gateway/proxy.
• SST OAuth issuer: https://salessavvy-test-be.glean.com/oauth.
• Credential store: ~/.glean-dcr-reuse-check/.
• Initial setup registered client Glean_Claude_Cod_a1afb446-4f30-4c99-af72-fc83665b90b5.
• Repeated setup with no reset preserved that same client ID.
• After the implementation change, setup({reset:true}) removed mcp-credentials.json entirely.
• The next setup registered a new client, Glean_Claude_Cod_9dc48be2-3b8d-45e5-a70d-9e55f82ff516.
• New access and refresh tokens were present after the new setup.
• No raw access or refresh tokens were recorded in the PR.

Local OAuth race validation

The intended race procedure compared the pre-fix baseline with this PR:

• Baseline plugin: commit 41763ed.
• Candidate plugin: commit 815f4d8.
• Baseline and candidate credential stores were isolated.
• Fresh access-token JWT claims were inspected locally: issuer, audience, scope, iat, exp, JWT lifetime, and presence of the refresh token. SST issued 120-second access tokens with stored_expires_in=120.
• The intended procedure was to invalidate only the access token while retaining the refresh token, confirm mcp_status=401, then invoke the local find_skills tool concurrently in two independent sessions.

Current race-test limitation

• In the final SST rerun, /oauth/revoke returned 200, but the subsequent MCP probe also returned 200; the gateway therefore did not enter the required 401 refresh path.
• Natural JWT expiry was not a reliable trigger because the MCP gateway accepted expired JWTs.
• Consequently, this final rerun does not claim a completed baseline or candidate race result. The remaining validation blocker is making SST revocation deterministic across the OAuth issuer and MCP gateway, including any cross-node revocation-cache propagation.

Follow-ups (not here): collapse the PLUGIN_DATA_DIR / ~/.glean store split; DCR self-recovery on invalid_client.

🤖 Generated with Claude Code

[eshwar-sundar-glean]

Abandoned sign in approach makes sense, but I am not sure about tieing setup to instance URL for reset, what if the user wants to just change email? This might not be a common scenario, but better to check with Roshan

[eshwar-sundar-glean]

This might not be common but what if they want to clear setup for logging in as a different email ?