Supported revocation mechanism for an indeterminate /auth/fetch SID exchange #1705

Hello Sanity team,

We are reviewing a fail-closed integration around the Sanity browser-based personal authentication flow.

Environment reviewed:

• Locked integration: @sanity/cli 7.18.0
• Also reviewed: @sanity/cli 8.0.0 and the current sanity-io/sdk auth source

Failure model:

1. The browser callback supplies a short-lived SID.
2. The client calls GET /auth/fetch?sid=....
3. The server may complete the exchange and mint/activate the personal token.
4. The connection or response is lost before the client receives the token.
5. The client therefore does not know the token and cannot authenticate POST /auth/logout.
6. The CLI source states that /auth/fetch invalidates the SID during exchange.

Could you please confirm the officially supported contract for this case?

1. Is there a supported endpoint that cancels or revokes every credential associated with an OAuth SID after the outcome of /auth/fetch is unknown?
2. Is there a client-preknown exchange/session ID or nonce that can be used for revocation or authoritative status lookup without knowing the token?
3. Is /auth/fetch idempotent for a consumed SID? Specifically, will a retry return the same token, or can it only report that the SID is no longer valid?
4. The CLI's MCP flow receives {id, sid} from POST /auth/session/create. Is there a documented revoke/cancel endpoint using that id or sid? If so, is it supported for initial browser login without an existing authenticated parent session?
5. If no explicit revocation operation exists, is there a documented server-enforced lifetime or cleanup guarantee that proves a token whose response was never received cannot remain valid?
6. Which API version and supported CLI/SDK versions define this behavior?

We need a documented, server-confirmed fail-closed cleanup guarantee. Local retry or state persistence is insufficient because the token may have been issued while remaining unknown to the client.

No real OAuth or project-specific credentials are required to answer this contract question.

Thank you.