[rmcp-client] Reread persisted OAuth credentials before refresh

[stevenlee-oai]

Codex Thread 019edd6d-6f14-74e2-853c-345d1803d4a6

Important

This PR belongs to the superseded MCP OAuth stack. Please review and merge the replacement stack beginning with openai/codex#30292. This PR remains available only as historical/reference context.

Replacement review order:

1. openai/codex#30292 — shared File/Secrets store locking
2. openai/codex#30293 — authoritative serialized refresh
3. openai/codex#30294 — Codex-owned transport refresh and one-shot 401 recovery
4. openai/codex#30295 — login/logout transaction serialization
5. openai/codex#30296 — diagnostic-only Auto store drift reporting

This is part 2 of an eight-PR stack that prevents concurrent MCP OAuth refreshers from replaying a rotating refresh token or overwriting newer credentials.

Review order

1. openai/codex#29017 — refresh transaction and lifecycle-local store pinning
2. openai/codex#29020 — authoritative reread after lock acquisition (this PR)
3. openai/codex#29019 — serialize login and logout with refresh
4. openai/codex#29021 — lock aggregate File and Secrets stores
5. openai/codex#30090 — retain refreshed credentials after a persistence failure
6. openai/codex#30091 — add Codex-owned proactive and 401 recovery
7. openai/codex#29018 — make Codex the exclusive refresh owner for all RMCP traffic
8. openai/codex#30089 — end-to-end transport recovery coverage

Why this layer exists

Serialization alone is insufficient if a waiter decides from credentials it read before acquiring the lock. The first process may already have rotated A to B. A later waiter must reread the selected durable store after it owns the transaction and adopt B instead of sending A to the provider again.

What changes

• Reread the lifecycle-pinned credential store only after acquiring the per-credential transaction lock.
• Adopt a newer durable credential snapshot into the authorization manager and skip the duplicate provider refresh.
• Treat confirmed deletion as authoritative rather than resurrecting the caller's stale in-memory credentials.
• Propagate read failures from the selected store; do not consult the other Auto store.

Decisions reviewers should preserve across the stack

• Auto resolution is lifecycle-local and not durably persisted. Once resolved, the client never hot-switches stores.
• The post-lock reread, not the caller's pre-lock snapshot, is authoritative unless a later layer has an unpersisted successful refresh in memory.
• Provider timeout releases the lock with an unknown outcome and allows a later serialized retry.
• In the final stack, public request/notification recovery remains at RmcpClient; RMCP-owned response/GET/DELETE recovery lives in the transport wrapper.
• The original openai/codex#28647 and its branch are untouched.

Review focus

Review the ordering: acquire transaction lock, reread the already-resolved store, adopt/clear/refresh, then persist before release. This PR does not change login/logout yet.

Non-goals

• Durable Auto selection, cross-CODEX_HOME keyring coordination, or backend migration.
• Login/logout serialization; that is part 3.

Validation

• just test -p codex-rmcp-client: 100 passed, 5 skipped.
• Cross-client coverage proves only one provider refresh occurs and the waiter adopts the winner.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3817102633

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[stevenlee-oai]

[from Codex]: Superseded by the compact five-PR stack. The authoritative-reread behavior from this slice is now folded into #29017 so the persistor is reviewed once. New order: #29017 → #29019 → #29021 → #29018 → #30089.