Add managed OAuth/login provider workflow across `auth` and `provider` CLI

[HaaapyDay]

Summary

I would like to request a complete CLI workflow for managed OAuth/login-based providers, not only a standalone login command.

The desired model is:

• cc-switch auth manages login accounts, tokens, and default account selection.
• cc-switch provider manages how those authenticated accounts are exposed and used as providers.

This is especially useful for subscription-backed providers such as:

• Codex / ChatGPT subscription via Codex OAuth
• GitHub Copilot subscription via GitHub Copilot login/OAuth

Upstream support and suggested implementation direction

My understanding is that the upstream cc-switch project already supports this kind of OAuth/login-based provider workflow, including managed accounts for providers such as Codex and GitHub Copilot.

Since this repository is downstream of cc-switch, I think the preferred direction should be to port/adapt/localize the upstream implementation instead of inventing a separate authentication model.

In particular, it would be ideal to preserve upstream semantics around:

• managed auth providers
• multi-account storage
• default account selection
• provider-to-account binding
• provider readiness/status display
• request-time token resolution
• OAuth/login provider UX
• localization/i18n strings where applicable

This would keep the downstream CLI behavior aligned with upstream and reduce long-term maintenance divergence.

Why auth login alone is not enough

A command like:

cc-switch auth login codex-oauth

would let the user authenticate, but it does not fully answer the provider workflow questions:

• How do I see which providers are backed by OAuth/login?
• How do I know whether a provider is authenticated?
• How do I bind a provider to a specific managed account?
• How do I tell whether the current provider uses API key auth or managed auth?
• What happens when I switch to an OAuth-backed provider but no account is logged in?
• Do speedtest, stream-check, and fetch-models use the managed token automatically?
• How does a user create a Codex OAuth or GitHub Copilot provider from CLI without manually editing config?

So this should not only add cc-switch auth login, but also adapt the existing provider CLI.

Current repository state

From looking through this repository, it seems that some backend support for managed authentication already exists, especially for Codex OAuth.

For example, the code appears to already include:

• AuthService support for codex_oauth
• Codex OAuth device-code login flow
• refresh-token persistence
• multi-account storage
• default account selection
• request-time token refresh
• provider-level authBinding
• providerType = "codex_oauth"
• proxy forwarding support for AuthStrategy::CodexOAuth
• ChatGPT-Account-Id header injection for Codex OAuth requests

However, I could not find a public CLI surface such as:

cc-switch auth login codex-oauth
cc-switch auth accounts codex-oauth
cc-switch auth use codex-oauth <account-id>
cc-switch auth logout codex-oauth

The design document docs/plans/2026-04-12-codex-oauth-backend-alignment.md also seems to describe the Codex OAuth work as backend-only and explicitly excludes CLI interactive login/account management UX for that pass.

So this issue is mainly asking to expose the existing managed-auth backend through a user-facing CLI, and to integrate it with the existing provider workflow.

Proposed model

1. cc-switch auth manages accounts

Suggested commands:

cc-switch auth providers

cc-switch auth login codex-oauth
cc-switch auth login github-copilot

cc-switch auth status
cc-switch auth status codex-oauth
cc-switch auth status github-copilot

cc-switch auth accounts codex-oauth
cc-switch auth accounts github-copilot

cc-switch auth use codex-oauth <account-id>
cc-switch auth use github-copilot <account-id>

cc-switch auth remove codex-oauth <account-id>
cc-switch auth logout codex-oauth
cc-switch auth logout codex-oauth --all

This layer should manage identity/account state.

It should not be the only place where provider usability is shown.

2. cc-switch provider list should show managed auth information

For OAuth/login-backed providers, provider list should show whether the provider uses managed auth and whether the account is available.

Example:

ID              Name              Type             Auth       Account           Status
openai-api      OpenAI API         codex            api_key    -                 ready
codex-official  Codex Official     codex_oauth      managed    user@example.com  ready
copilot         GitHub Copilot     github_copilot   managed    octocat           not logged in

Possible columns:

• provider id
• provider name
• provider type
• auth type: api_key, managed, none
• auth provider: codex_oauth, github_copilot
• bound account or default
• auth status: ready, not logged in, account missing, expired
• whether it is current

This would make provider list much more useful for subscription-backed providers.

3. cc-switch provider current should show auth binding/status

For the active provider, provider current should show something like:

Current provider: codex-official
Application: claude
Provider type: codex_oauth
Auth: managed account
Auth provider: codex_oauth
Account: user@example.com
Status: ready

If the provider is not usable:

Current provider: copilot
Provider type: github_copilot
Auth: managed account
Status: not logged in

Run:
  cc-switch auth login github-copilot

4. cc-switch provider add should support managed auth providers

When adding a provider, users should be able to choose managed auth instead of API key.

For example:

cc-switch --app claude provider add

Could offer choices like:

Provider kind:
  API key / custom endpoint
  Codex OAuth / ChatGPT subscription
  GitHub Copilot subscription

Or non-interactive forms:

cc-switch --app claude provider add \
  --type codex-oauth \
  --name "Codex Official" \
  --auth-provider codex-oauth \
  --account default

cc-switch --app claude provider add \
  --type github-copilot \
  --name "GitHub Copilot" \
  --auth-provider github-copilot \
  --account default

For Codex OAuth, this could create provider metadata similar to:

{
  "meta": {
    "providerType": "codex_oauth",
    "authBinding": {
      "source": "managed_account",
      "authProvider": "codex_oauth"
    }
  }
}

If a specific account is selected:

{
  "meta": {
    "providerType": "codex_oauth",
    "authBinding": {
      "source": "managed_account",
      "authProvider": "codex_oauth",
      "accountId": "<account-id>"
    }
  }
}

5. cc-switch provider edit should support binding/unbinding managed accounts

Users should not need to manually edit config JSON to bind an account.

Suggested commands:

cc-switch provider bind-auth <provider-id> codex-oauth --account <account-id>
cc-switch provider bind-auth <provider-id> codex-oauth --default

cc-switch provider bind-auth <provider-id> github-copilot --account <account-id>
cc-switch provider bind-auth <provider-id> github-copilot --default

cc-switch provider unbind-auth <provider-id>

Alternatively, this could be part of provider edit <id>.

Expected behavior:

• --account <account-id> binds the provider to that exact account.
• --default makes the provider follow the default account for that auth provider.
• unbind-auth returns the provider to provider-config/API-key auth if applicable.

6. cc-switch provider switch should warn when auth is missing

When switching to a managed-auth provider, the CLI should verify whether the provider is usable.

Example:

cc-switch provider switch codex-official

If no Codex OAuth account exists:

Switched to provider: codex-official

Warning: this provider uses Codex OAuth, but no account is logged in.

Run:
  cc-switch auth login codex-oauth

If a bound account no longer exists:

Warning: this provider is bound to account acct_xxx, but that account was not found.

Run one of:
  cc-switch auth accounts codex-oauth
  cc-switch provider bind-auth codex-official codex-oauth --default

7. Diagnostics should resolve managed auth automatically

The following commands should work with managed-auth providers:

cc-switch provider speedtest <id>
cc-switch provider stream-check <id>
cc-switch provider fetch-models <id>

Expected behavior:

• If the provider uses API key auth, use the configured API key.
• If the provider uses managed auth, resolve the access token at request time.
• If the token is expired, refresh it.
• If no account is available, show a clear error suggesting cc-switch auth login ....
• Never print access tokens, refresh tokens, or raw secrets.

8. cc-switch config validate should validate managed auth bindings

It would also be helpful if config validation could detect broken provider auth bindings.

Example checks:

• provider uses meta.providerType = "codex_oauth" but no authBinding
• authBinding.authProvider is unsupported
• authBinding.accountId points to a missing account
• provider follows default account, but no default account exists
• provider type is github_copilot, but no GitHub Copilot managed auth backend exists yet

Codex OAuth

The repository already appears to have backend pieces for Codex OAuth managed auth, including account storage, token refresh, and request-time token resolution.

The requested work is to expose this through the CLI and integrate it with provider management.

Minimum expected workflow:

cc-switch auth login codex-oauth
cc-switch --app claude provider add --type codex-oauth --name "Codex Official" --account default
cc-switch --app claude provider list
cc-switch --app claude provider switch codex-official
cc-switch --app claude provider stream-check codex-official

GitHub Copilot

The upstream project appears to already support GitHub Copilot as a login/OAuth-backed provider.

In this downstream repository, the codebase appears to recognize GitHub Copilot provider/auth strategy in some places, but I could not find a complete managed login/token manager comparable to Codex OAuth.

It would be useful to port/adapt the upstream GitHub Copilot managed-auth workflow as well:

cc-switch auth login github-copilot
cc-switch provider add --type github-copilot --name "GitHub Copilot" --account default
cc-switch provider list
cc-switch provider switch github-copilot

The goal is to allow users with a GitHub Copilot subscription to use it as a provider through cc-switch, without manually managing tokens.

Localization / i18n

Since this repository already has CLI i18n support, the new commands and provider status messages should ideally be localized as well.

If the upstream project already has relevant strings or UX wording for managed auth providers, it would be preferable to adapt/localize those upstream strings here rather than creating a different vocabulary.

Suggested terms to localize include:

• managed auth
• login provider
• account
• default account
• bound account
• not logged in
• account missing
• token expired
• provider uses managed account
• run cc-switch auth login ...

Acceptance criteria

• cc-switch auth --help is available.
• cc-switch auth login codex-oauth works through device-code login.
• cc-switch provider list displays managed auth provider type/status/account information.
• cc-switch provider current displays auth binding and readiness.
• cc-switch provider add can create a managed-auth provider without manual JSON editing.
• cc-switch provider edit or a new provider subcommand can bind/unbind managed accounts.
• cc-switch provider switch warns clearly if the selected provider is not authenticated.
• speedtest, stream-check, and fetch-models use managed auth automatically where applicable.
• config validate detects broken managed auth bindings.
• Existing API-key providers continue to work unchanged.
• Secrets are never printed in normal output, logs, or errors.
• Shell completions include the new auth/provider commands.
• New CLI output is localized consistently with the rest of the project.
• Where possible, behavior and terminology are ported/adapted from upstream.

Suggested tests

Please consider adding tests for:

• Codex OAuth login flow with mocked responses
• account list/default/remove behavior
• provider authBinding resolution
• request forwarding token resolution
• ChatGPT-Account-Id header injection
• provider list/current display for managed-auth providers
• provider switch warnings for missing auth
• provider add/edit/bind-auth CLI parsing
• config validation for broken auth bindings
• shell completion generation for auth and new provider commands
• localization/i18n coverage for new CLI strings

Compatibility

This should be additive only.

Existing behavior should not be broken:

• provider add
• provider edit
• provider switch
• API-key based providers
• Codex official provider snapshots
• existing proxy forwarding behavior
• existing CLI i18n behavior

Why this should involve both auth and provider

auth and provider represent different layers:

• auth: manages identities, tokens, default accounts
• provider: manages how those identities are used by Claude/Codex/Gemini/OpenCode/etc.

A complete user workflow needs both. Otherwise users can log in successfully but still have no clear way to create, inspect, bind, switch, or diagnose subscription-backed providers.

Since upstream already appears to support this workflow, the ideal path is probably to port/adapt/localize the upstream managed-auth provider workflow into this downstream CLI repository.

Contribution note

If possible, I plan to submit a PR in the near future to help implement the functionality described above.

I plan to implement this with the help of AI coding tools, but I will make sure to perform thorough testing and review before submitting the PR.

If this work is already planned or in progress, I would appreciate it if some of the remaining tasks could be assigned to me.

[SaladDay]

Thanks for the detailed proposal. This direction makes sense and is acceptable.

A few requirements for implementation:

• Please keep the behavior and terminology as close to upstream cc-switch as possible.
• Prefer porting/adapting upstream logic instead of creating a separate auth/provider model.
• Please keep the current database schema unchanged for now.
• The change should be additive and must not break existing API-key provider workflows.
• Codex OAuth can be implemented first; GitHub Copilot support can be follow-up if needed.

A PR for this would be welcome☺️

[HaaapyDay]

Hi @SaladDay

Thanks for the context.

I agree the original proposal is too broad for one issue/PR. I would like to narrow the scope for my initial contribution.

For the first pass, I would like to focus only on Codex OAuth and the minimum useful Claude Code workflow:

1. Expose Codex OAuth managed-auth through CLI.
2. Allow Claude Code to use a codex_oauth provider through cc-switch proxy forwarding.

The intended user workflow would be:

cc-switch auth login codex-oauth
cc-switch auth accounts codex-oauth
cc-switch auth use codex-oauth <account-id>
cc-switch --app claude provider add \
  --type codex-oauth \
  --name "Codex" \
  --account default
cc-switch --app claude provider switch <provider-id>

After that, Claude Code requests should be forwarded by cc-switch to the Codex/ChatGPT subscription backend using the managed Codex OAuth account.

Backend parity / implementation source:

Area	Backend logic status
Codex OAuth device-code login	Should be ported/adapted from upstream, not newly invented. Upstream source: src-tauri/src/proxy/providers/codex_oauth_auth.rs; exposed through upstream Tauri command layer in src-tauri/src/commands/auth.rs.
Multi-account storage	Should preserve upstream backend semantics. Upstream source: src-tauri/src/proxy/providers/codex_oauth_auth.rs.
Default account selection	Should preserve upstream backend semantics. Upstream source: src-tauri/src/proxy/providers/codex_oauth_auth.rs and command wrapper in src-tauri/src/commands/auth.rs.
Account removal / logout	Should preserve upstream backend semantics. Upstream source: src-tauri/src/proxy/providers/codex_oauth_auth.rs and src-tauri/src/commands/auth.rs.
Provider metadata shape	Should preserve upstream metadata semantics: meta.providerType = "codex_oauth" and meta.authBinding = { source: "managed_account", authProvider: "codex_oauth", accountId? }. Upstream source: src-tauri/src/provider.rs, plus frontend/provider construction references in src/config/claudeProviderPresets.ts and src/components/providers/forms/ProviderForm.tsx.
Claude provider type detection	Should be ported/adapted from upstream, not newly invented. Upstream source: src-tauri/src/proxy/providers/mod.rs and src-tauri/src/proxy/providers/claude.rs.
Codex OAuth base URL routing	Should preserve upstream behavior: force codex_oauth providers to https://chatgpt.com/backend-api/codex. Upstream source: src-tauri/src/proxy/providers/claude.rs.
Claude Messages → OpenAI Responses transform	Should reuse/port upstream behavior for codex_oauth, including Codex-specific constraints such as store: false and reasoning.encrypted_content. Upstream source: src-tauri/src/proxy/providers/claude.rs and src-tauri/src/proxy/providers/transform_responses.rs.
Request-time access-token resolution	Should preserve upstream backend semantics: resolve token from the managed Codex OAuth account at request time, using explicit accountId when present and default account otherwise. Upstream source: src-tauri/src/proxy/forwarder.rs.
Access-token refresh	Should preserve upstream manager behavior. Upstream source: src-tauri/src/proxy/providers/codex_oauth_auth.rs.
ChatGPT-Account-Id injection	Should preserve upstream forwarding behavior. Upstream source: src-tauri/src/proxy/forwarder.rs.
Missing login/account error behavior	Should be adapted from upstream manager/forwarder behavior, with CLI-friendly error messages. Upstream source: src-tauri/src/proxy/providers/codex_oauth_auth.rs and src-tauri/src/proxy/forwarder.rs.

(The above information was compiled by AI for me)

So the backend logic I want to implement is mostly ported/adapted from upstream, not newly designed.

The main downstream-specific work is wiring that upstream backend behavior into this CLI-first repository:

• expose the existing/ported auth backend through CLI commands;
• ensure codex_oauth provider metadata can be created or represented from CLI;
• connect the existing Claude proxy path to the upstream Codex OAuth forwarding semantics.
  For provider metadata, I plan to preserve the upstream shape:

{
  "meta": {
    "providerType": "codex_oauth",
    "authBinding": {
      "source": "managed_account",
      "authProvider": "codex_oauth"
    }
  }
}

If a specific account is selected:

{
  "meta": {
    "providerType": "codex_oauth",
    "authBinding": {
      "source": "managed_account",
      "authProvider": "codex_oauth",
      "accountId": "<account-id>"
    }
  }
}

I will explicitly leave the broader provider-management UX for follow-up work, including:

• GitHub Copilot OAuth
• provider list/current auth status display
• provider bind-auth / unbind-auth
• full managed-auth UX for all provider types
• managed-auth support for all diagnostics commands
• broader config validation

So the goal of the first PR would be:

Port/adapt upstream Codex OAuth managed-auth backend semantics and minimal Claude Code proxy forwarding for codex_oauth providers.

This keeps the backend behavior aligned with upstream while avoiding turning the first PR into a full managed-auth provider epic.