Skip to content
CC Switch WikiUnofficial Community Wiki

auth.json does not change with the channel; editing overwrites the third-party channel key (cc-switch)

Quick fix

cc-switch 3.20.0 writes the official key from auth.json back into a Codex relay channel when editing it. Upgrade to the version with the #6534 fix and re-save…

Symptom

Section titled “Symptom”
Error output
`auth.json` 不会随渠道改变而改变，在编辑时覆写第三方渠道的密钥
English translation

`auth.json` does not change with the channel, and editing overwrites the third-party channel's key

Cause

Section titled “Cause”

The root cause was confirmed by the maintainer: `~/.codex/auth.json` is a single-slot shared file with no provider identity. With "keep official login" enabled, auth.json stores the official login key, while the relay provider's own key actually lives in `experimental_bearer_token` in `config.toml`. However, the edit dialog in cc-switch 3.20.0 reads auth.json first when loading the live config, so the input box shows the official key; on save it writes that official key back into the provider's database record (`settings_config.auth.OPENAI_API_KEY`), resulting in "edit a channel once, and its key gets replaced by the official key". After the fix (#6534), loading a Codex config promotes `experimental_bearer_token` as that provider's key, so both display and save use its own key.

Note that #1868 in the same cluster is a different code path: a user wanted to use GPT models in Claude Code via a relay, hit errors like `There's an issue with the selected model (gpt-5.4). It may not exist or you may not have access to it`, and was unsure whether to fill in `ANTHROPIC_AUTH_TOKEN` or `OPENAI_API_KEY`, or whether a relay was needed. The maintainer replied explicitly: Codex oauth is not implemented yet, so you must go through a relay; configure it per the example and enable proxy takeover, and the Response API request URL usually has an extra `v1`; the thinking level in Claude Code maps to the GPT model's thinking level. This is not the same bug; it only also involves key configuration under a relay.

Fix

Section titled “Fix”

  1. Upgrade cc-switch: the maintainer confirmed this bug is fixed by #6534, to be released in the version after 3.20.0. After upgrading to a version containing the fix, the edit dialog will correctly display and save the provider's own key.

  2. Temporary workaround before upgrading: after editing a third-party channel and before saving, check the API Key input box. If it now shows the official key (the one in `~/.codex/auth.json`), manually change it back to the relay key before saving; or simply avoid editing already-configured channels.

  3. If the provider's database record is already polluted (the official key was saved), after upgrading edit that provider again, enter the correct relay key, and save once more to correct `settings_config.auth.OPENAI_API_KEY` in the database.

  4. Use the maintainer's three-point comparison to verify the fix: `settings_config.auth.OPENAI_API_KEY` in the provider's database record should be the relay key; `OPENAI_API_KEY` in `auth.json` should remain the official login unchanged; the actually effective `experimental_bearer_token` in `config.toml` should be the relay key.

    ~/.codex/config.toml
    # 中转站供应商自己的密钥应保存在这里，而不是 auth.json
    experimental_bearer_token = "中转站密钥_KEY_A"

Affected Versions

Section titled “Affected Versions”
ToolCodex
Version3.20.0（受影响版本；修复 #6534 将随其后的下个版本发布）
PlatformsWindows

Source Issues

Section titled “Source Issues”

This page is distilled from 2 real issues

FAQ

Section titled “FAQ”
After editing a third-party channel, the key in the input box became the official key. What should I do?
This is exactly the symptom of this bug: the edit dialog reads the official login key from `~/.codex/auth.json` first. Upgrade to a version containing the #6534 fix; before upgrading, manually change the key in the input box back to the relay key before saving.
With official login enabled, after switching API and restarting Codex, auth.json is still the official login, and changing it manually does not work. Is this the same problem?
Yes, same root cause: `auth.json` is a single-slot shared file with no provider identity. With "keep official login" enabled it always stores the official key; each channel's key actually lives in `experimental_bearer_token` in `config.toml`. Do not manually edit auth.json.
When logging into Codex with a third-party key it says the token is invalid. Is that this bug too?
No. The maintainer explained that is a different code path: since Codex CLI 0.149 it no longer automatically attaches the Authorization header from auth.json. That issue is tracked in #6744 and is out of scope here.
Does cc-switch not integrate local codex oauth? Is a relay mandatory?
The maintainer replied that oauth is not implemented yet. Currently, to use GPT models in Claude Code you must go through a relay: set up the provider per the maintainer's config example and enable proxy takeover. Note the Response API request URL usually needs an extra `v1`.
Section titled “Related problems”
Provider API Key Overwritten: After Codex Restart or SwitchUpgrade to cc-switch v4.0.0 or later to prevent provider keys from overwriting each other and restore the official login state.6 issues mergedCannot use Google-email Codex account after opening cc switch - CodexA third-party key in ~/.codex/auth.json overrode ChatGPT login: add the official provider in CC Switch and switch back to restore login, and upgrade to…7 issues mergeddeepseek接入 模型勾选了1m: no 1M context option in Claude Code model pickerUpgrade cc-switch to v3.17.0+, leave the DeepSeek provider's ANTHROPIC_MODEL empty or check 1M there too, fill only Haiku/Sonnet/Opus mappings… (Claude Code)7 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.