feat(auth): support application-provided OAuth token storage

• I have looked for existing issues (including closed) about this

Feature Request

Allow applications to supply the token storage used by the built-in ChatGPT and Copilot OAuth clients, while keeping Rig responsible for login, token refresh, and authenticated requests.

In Rig 0.42, these clients expose token-file paths through their builders. The shared cache helpers on main also read and write JSON files directly. I could not find a public interface for replacing that persistence with application-owned storage.

Motivation

I maintain Toad, a Rust/Tauri application using Rig for its native agents. We want provider credentials and MCP credentials to use the same OS-backed vault: macOS Keychain, Windows Credential Manager, and Linux Secret Service.

Ordinary API keys can already be loaded by the application and passed to Rig in memory. Built-in OAuth is different: Rig also persists tokens during login and refresh, so choosing a different file path does not let the application enforce its storage policy.

Other desktop applications, services with managed secret storage, and tests using an in-memory store could use the same extension point.

Proposal

Add a caller-supplied OAuth token-store interface for ChatGPT and Copilot. The exact API shape is open for discussion; the intended behavior is:

• Route token reads, writes, and invalidation through the selected store, including Copilot's bootstrap credentials and derived token cache.
• Keep the existing file-backed behavior as the default.
• Keep login and refresh logic in Rig. An application selects persistence without implementing OAuth or replacing the inference client.
• Distinguish a missing record from an unavailable or failed store. A configured custom store must not silently fall back to writing token files.
• Define how the store participates in refresh coordination so concurrent clients do not overwrite rotated credentials.

The interface should follow Rig's error and WASM conventions. OS-specific implementations and dependencies can stay in the consuming application; this proposal does not require Rig to depend on a keychain library.

Tests could extend the existing ChatGPT/Copilot OAuth coverage with an in-memory/failing store, proving that login and refresh use it, failures propagate, and no default token files are created.

Related work: #2050 provides OAuth regression coverage, #2396 routes auth through the generic HTTP client, and #2088 includes useful discussion of refresh locking and preserving credentials after failed writes. #1905 also touches shared auth code, but its token persistence remains file-based.

I'm happy to contribute a focused PR once we agree on the storage boundary.

Alternatives

• Restrict permissions on the existing token files. That limits file access but does not integrate with the application's OS credential store.
• Copy tokens between the vault and temporary files around Rig calls. This still creates plaintext copies and complicates refresh, cancellation, and crash recovery.
• Own OAuth outside Rig and inject access tokens. That duplicates login/refresh behavior we would prefer to keep in Rig.
• Add a specific keychain backend directly to Rig. A storage interface would let callers choose their backend without imposing native dependencies on everyone.