Skip to content
CC Switch WikiUnofficial Community Wiki

auth.json OPENAI_API_KEY not synced - Codex

Quick fix

Upgrade cc-switch to v3.20.1. Switching Codex providers no longer overwrites auth.json, fully resolving the key retention issue.

Symptom

Section titled “Symptom”
Error output
auth.json OPENAI_API_KEY → 匹配 SuperAPI（上一个 provider）✗
config.toml base_url / experimental_bearer_token → 匹配 Vibe Coding ✓
English translation

auth.json OPENAI_API_KEY → matches SuperAPI (previous provider) ✗ config.toml base_url / experimental_bearer_token → matches Vibe Coding ✓

Cause

Section titled “Cause”

Before cc-switch v3.20.1, a configuration write logic flaw existed when switching Codex providers. The core cause was that cc-switch failed to keep the active provider's `settings_config.auth` content (specifically `OPENAI_API_KEY` and `auth_mode`) synchronized with `~/.codex/config.toml` when writing the live configuration. Specifically, after switching providers, `config.toml` correctly updated `base_url` and `experimental_bearer_token`, but `~/.codex/auth.json` still retained the previous provider's key. This caused Codex to read an inconsistent configuration combination on startup, using incorrect authentication for actual requests.

Additionally, in proxy takeover mode, cc-switch only explicitly extracted the `OPENAI_API_KEY` field when writing `auth.json`, discarding other necessary fields like `auth_mode`, causing third-party API to malfunction. In the config-only refactor of v3.20.1, these issues were fixed by rewriting the storage location management: switching third-party providers no longer writes `auth.json` at all, keys follow the provider's own provider table, and `auth.json` returns to being a pure official login file.

Fix

Section titled “Fix”

  1. Upgrade cc-switch to v3.20.1 or higher. This version performs a config-only refactor of Codex configuration storage, no longer overwriting auth.json when switching third-party providers.

    ~/.codex/auth.json
    // 修复前（被错误覆写）
    {
      "OPENAI_API_KEY": "sk-旧供应商的key"
    }
    // 修复后（不再被覆写，保持官方登录状态）
    {
      "OPENAI_API_KEY": "",
      "auth_mode": "chatgpt",
      "token": "..."
    }

  2. If the issue persists after upgrading, check if OPENAI_API_KEY is set in system environment variables. cc-switch detects system environment variable conflicts and may affect configuration application; remove this setting from system environment variables.

    系统环境变量
    // 删除或注释掉环境变量
    // OPENAI_API_KEY=sk-xxxx

  3. For users using proxy takeover, if you manually edited auth.json, ensure it contains the auth_mode field. After upgrading to v3.20.1, this field is automatically populated with the provider configuration, requiring no manual maintenance.

Affected Versions

Section titled “Affected Versions”
ToolCodex
Version3.14.1 - 3.19.0（受影响版本），v3.20.1 修复
PlatformsWindowsmacOS

Source Issues

Section titled “Source Issues”

This page is distilled from 10 real issues

FAQ

Section titled “FAQ”
Why does Codex report INVALID_API_KEY after switching providers?
Because the old version of cc-switch only rewrote config.toml when switching providers, without updating OPENAI_API_KEY in ~/.codex/auth.json, causing Codex to read the previous provider's expired key. This issue is fixed after upgrading to v3.20.1.
Why is auth.json overwritten to contain only a single OPENAI_API_KEY field?
In proxy takeover mode, the old version of cc-switch only explicitly extracted the OPENAI_API_KEY field when serializing auth.json, discarding other fields like auth_mode. Starting from v3.20.1, switching third-party providers no longer writes auth.json at all, so this issue no longer occurs.
Will previous configurations still work after upgrading to the latest version?
Yes. The config-only refactor in v3.20.1 rewrote the storage location management. The database side backfill uniformly strips the bearer token from the config text and stores it in a single key slot. Existing managed accounts may need to click "Re-login" once on the account row; see the release notes for details.
What to do when adding a custom provider shows an error and cannot be added?
When adding, auth.json (JSON) must be set to {"OPENAI_API_KEY": "any"}. After adding, setting it to empty {} during modification is fine. This is because the old version performed a non-empty check on OPENAI_API_KEY.
Why does cc-switch prompt a detected system environment variable conflict?
This is triggered by having OPENAI_API_KEY set in system environment variables. It is recommended to remove this setting from system environment variables to avoid conflicts with cc-switch managed configurations.
Section titled “Related problems”
ANTHROPIC_BASE_URL rewritten to 127.0.0.1With local routing on, ANTHROPIC_BASE_URL pointing at http://127.0.0.1:15721 is expected. Move shared fields into 通用配置 and restart Claude Code.10 issues mergedAuth conflictDelete primaryApiKey from claude.json, or change the environment variable to ANTHROPIC_API_KEY, to resolve the auth conflict.5 issues mergedauth.json under .claude is forcibly replaced after a restart - CodexUpgrade cc-switch to the latest version, or turn proxy takeover off before signing in officially, so a stale snapshot cannot overwrite official credentials.5 issues merged

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.