Codex App Enhancements can preserve OAuth but still consume Auth quota instead of API billing

[Tomodad]

Self Checks / 自检

• I have read the FAQ section in README.
• I have searched existing issues, including codex 需要保持混合登录状态！ #3018, 能否增加让codex在使用第三方api登录的状态下，能正常使用插件的功能？ #3400, and Codex 供应商切换时 auth.OPENAI_API_KEY 被 experimental_bearer_token 覆盖 #3556.

CC Switch Version / 版本号

3.16.1

Operating System / 操作系统

Windows

Related App / 涉及应用

Codex

Problem or Motivation / 问题或动机

Settings -> Codex App Enhancements -> Keep official login when switching third-party providers appears to preserve Codex App official features by keeping ChatGPT/Codex OAuth material in ~/.codex/auth.json, while writing the third-party API key into config.toml as experimental_bearer_token.

This does preserve the official login state, but in my local testing it also means Codex still treats the active session as ChatGPT/Auth login rather than API-key login. As a result, provider routing may point at the third-party API endpoint, but usage appears to be charged against the Auth/ChatGPT account instead of the OpenAI API project.

This makes the current enhancement ambiguous:

• The UI says the third-party/API provider is active.
• config.toml points to the third-party/custom base_url.
• But auth.json remains auth_mode = chatgpt with OPENAI_API_KEY = null.
• codex doctor reports ChatGPT auth / ChatGPT reachability, not API key auth.
• The OpenAI API dashboard shows no corresponding usage, while the Auth account quota decreases.

Steps to Reproduce / 重现步骤

1. Start from a valid Codex ChatGPT/OAuth login.
2. Enable Codex App Enhancements -> Keep official login when switching third-party providers.
3. Switch Codex to a third-party/API provider with a valid API key.
4. Check the live files:

~/.codex/auth.json:
auth_mode = "chatgpt"
OPENAI_API_KEY = null
tokens = <present>

~/.codex/config.toml:
model_provider = "custom"
[model_providers.custom]
base_url = "<third-party-or-relay-url>"
requires_openai_auth = true
experimental_bearer_token = "<provider-api-key>"

5. Run:

codex login status
codex doctor

Actual Behavior / 实际行为

With auth.json preserved as ChatGPT/OAuth, Codex reports ChatGPT/Auth login even though the active provider is a third-party/custom provider.

Observed diagnostics:

codex login status:
Logged in using ChatGPT

codex doctor:
model provider           custom
provider name            ccswitch
auth mode                chatgpt
stored API key           false
stored ChatGPT tokens    true
reachability mode        ChatGPT auth

In this state, the OpenAI API dashboard did not show usage for the test requests, while the Auth/ChatGPT account quota decreased.

After changing auth.json to API-key login:

{
  "auth_mode": "apikey",
  "OPENAI_API_KEY": "<api-key>"
}

Codex reports the expected API auth state:

codex login status:
Logged in using an API key

codex doctor:
stored auth mode         api_key
stored API key           true
stored ChatGPT tokens    false
auth mode                api_key
reachability mode        API key auth

Expected Behavior / 期望行为

There should be a way to preserve Codex App official features such as mobile remote control / official plugins while ensuring model traffic is authenticated and billed through the selected API provider/key.

At minimum, CC Switch should make the effective auth/billing mode explicit. If the live state is:

auth.json auth_mode = chatgpt
OPENAI_API_KEY = null
config.toml experimental_bearer_token = <api-key>

then the UI should not imply that this is equivalent to API-key login or API billing. It should warn that Codex still reports ChatGPT/Auth login.

Proposed Solution / 建议方案

Possible approaches:

1. Add an explicit Codex provider auth mode with clear semantics:

   • Official app mode: preserve auth.json OAuth; third-party key lives in experimental_bearer_token; warn that billing may still follow ChatGPT/Auth unless Codex confirms provider-scoped billing.
   • API billing mode: write auth.json as auth_mode = apikey and OPENAI_API_KEY = <provider key>; official app features may be unavailable.
   • Proxy split mode: keep auth.json OAuth for app/session features, but route model calls through CC Switch local proxy using the provider key server-side, so Codex App auth and upstream model billing are separated outside Codex's global auth state.

2. In the Codex provider card or enhancement settings, show a diagnostic badge derived from live state:

   • codex login status
   • codex doctor auth mode / reachability mode
   • whether stored ChatGPT tokens or stored API key is active

3. For the current preservation feature, consider warning when all of these are true:

   • preserveCodexOfficialAuthOnSwitch = true
   • auth.json.auth_mode = chatgpt
   • auth.json.OPENAI_API_KEY is null/empty
   • selected provider has experimental_bearer_token

   Suggested warning:

   Official login is preserved. Codex may still authenticate model requests as ChatGPT/Auth. Verify with codex doctor; API billing is not guaranteed in this mode.

4. Longer-term: investigate whether current Codex supports a true split-auth configuration: official OAuth for app features, provider-scoped API key for model requests. If Codex does not expose this separation, CC Switch may need to implement it through local routing/proxy ownership rather than only file switching.

Related Issues / 相关 Issue

• codex 需要保持混合登录状态！ #3018: request to keep official account while model conversations go through third-party provider
• 能否增加让codex在使用第三方api登录的状态下，能正常使用插件的功能？ #3400: plugins unavailable when using third-party API login
• Codex 供应商切换时 auth.OPENAI_API_KEY 被 experimental_bearer_token 覆盖 #3556: auth.OPENAI_API_KEY and experimental_bearer_token getting mixed during provider switching/sync

Additional Context / 补充信息

This issue is not about exposing any API key. All diagnostics above are redacted. The main concern is that experimental_bearer_token may make the third-party key present in config.toml, but the effective Codex auth mode remains chatgpt, causing the user's quota/billing expectation to be wrong.

[hungryM0]

I tested this as well and observed a split behavior

• Local Codex sessions work as expected

requests are routed through the configured custom base_url, and usage is recorded by the selected API provider.

• Remote Control sessions do not

requests started through Remote Control appear to bypass the custom provider configuration and continue consuming the ChatGPT/Codex account quota.

---

So preserving the OAuth login does not seem to be the only problem. The local CLI can use the third-party provider while keeping auth.json, but Remote Control appears to use a separate execution or authentication path that does not inherit the local model_provider, base_url, or provider API key.

If Remote Control runs through an OpenAI-managed remote environment, this may not be solvable through config.toml and auth.json changes alone.