Stale client registration replayed to DCR forever; only --reset recovers

[sourman]

A valid-but-stale client registration (a client_id the provider no longer accepts) makes mcporter auth <server> fail at the DCR step and replay the same dead registration on every retry. Only --reset recovers.

Reproduced flipping a Supabase GoTrue-backed guard server between two project refs. Stale entries pile up in the vault, and auth dies with:

[cause]: ServerError
    at parseErrorResponse (.../auth.js:132)
    at registerClient (.../auth.js:914)
{ errorUri: undefined }

--reset clears it; the flow then completes and a follow-up auth is a no-op.

On main (710840f), unrecoverableOAuthRefreshCode (oauth-persistence.ts:123) is wired in only at the refresh paths (:643, :729), never at registerClient. And oauthErrorCode (:143) needs a structured code or known error name; the bare ServerError from parseErrorResponse has neither. So a DCR failure never clears the stale client_id. #190 and #208 cover refresh failures and corrupt cache, not this.

Fix, in the spirit of #190: in the auth()/attemptTransportConnect error branch, when cached clientInformation exists and the failure is from registerClient, invalidateCredentials('client') and retry DCR once.

mcporter 0.12.3, Node, Linux.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 18, 2026, 8:25 AM ET / 12:25 UTC.

Summary
Keep open. The report identifies a plausible, distinct dynamic-client-registration recovery gap: the related OAuth fixes address structured refresh failures and corrupt credential files, but the supplied current-main trace says a bare DCR ServerError leaves the cached client registration intact. The broad v0.12.0 stale-registration release note is not enough to prove this exact failure path is already handled.

Reproducibility: no. high-confidence local reproduction was completed: the report provides a specific Supabase project-ref switch and current-main code trace, but validating it requires a live provider setup and the review sandbox rejected local read-only inspection commands before execution.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Include the exact command, prompt, or workflow that triggered it.
• Add expected vs actual behavior.

Next step
A maintainer should first validate the exact DCR failure provenance and retry semantics against a real provider before promoting this to an autonomous repair.

Review details

Best possible solution:

Add a narrowly scoped, single-retry DCR recovery path that invalidates only a cached client registration after a confirmed registerClient failure, then prove both successful recovery and preservation of non-DCR or transient-error behavior.

Do we have a high-confidence way to reproduce the issue?

No high-confidence local reproduction was completed: the report provides a specific Supabase project-ref switch and current-main code trace, but validating it requires a live provider setup and the review sandbox rejected local read-only inspection commands before execution.

Is this the best way to solve the issue?

Unclear: a one-time retry after invalidating a cached registration is a maintainable direction, but the implementation should first identify DCR-originated failures rather than treating every unstructured server error as proof that the client registration is stale.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The recovery condition must preserve error provenance: invalidating a cached client on every generic DCR ServerError could unnecessarily discard a valid registration during a transient provider outage.

Codex review notes: model internal, reasoning high; reviewed against 710840fb7dd0.

Label changes

Label changes:

• add P2: A stale provider registration blocks a bounded OAuth authentication flow but does not indicate a system-wide outage or security bypass.
• add impact:auth-provider: The reported failure is in cached OAuth client-registration recovery for an external provider.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: A stale provider registration blocks a bounded OAuth authentication flow but does not indicate a system-wide outage or security bypass.
• impact:auth-provider: The reported failure is in cached OAuth client-registration recovery for an external provider.

Evidence reviewed

What I checked:

• Current-main path reported: The report gives a concrete current-main trace: unrecoverableOAuthRefreshCode is used in refresh paths, while registerClient failures reach neither that recovery logic nor a structured error code; this leaves a stale cached client_id replayed on subsequent authentication attempts. (src/oauth-persistence.ts:123, 710840fb7dd0)
• Related refresh recovery is narrower: Merged OAuth recovery work in fix: harden OAuth vault recovery #190 explicitly clears stale registrations on structured permanent refresh failures, which supports treating this reported DCR-path failure as partial overlap rather than an established duplicate. (src/oauth-persistence.ts, 49dc62b9eec9)
• Corrupt-cache fix is distinct: fix(oauth): degrade to re-auth on corrupt credential cache instead of crashing #208 handles malformed persisted JSON by degrading credential reads to re-auth; it does not establish recovery from a valid cached registration rejected by a provider. (src/oauth-persistence.ts, 53747cac6362)
• Release evidence is insufficient to close: The repository release history notes stale dynamic client-registration cleanup in v0.12.0, but the item reports the exact DCR ServerError scenario on v0.12.3/current main, so that high-level release note cannot prove the requested retry is already present. (f20febe322b6)

Likely related people:

• steipete: Authored and merged the OAuth vault recovery change that added stale client-registration recovery for permanent refresh failures, the closest established recovery boundary. (role: introduced adjacent OAuth recovery behavior; confidence: high; commits: 49dc62b9eec9; files: src/oauth-persistence.ts)
• KrasimirKralev: Authored the recent credential-cache recovery work, which is adjacent persistence behavior but addresses corrupted rather than provider-rejected client registrations. (role: recent OAuth persistence contributor; confidence: medium; commits: 53747cac6362; files: src/oauth-persistence.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[sourman]

Honestly good points

in my case config/mcporter.json contained new configs. that should have cause the invalidation on its own maybe? the DCR failure might be transient, but if the URL of the MCP server changed surely must be called into question. what do you think mister sweeper?