用过 CCSwitch 后，如何恢复 Codex Desktop 官方登录与模型配置

事件日期：2026 年 9 月 7 日；整理日期：2026 年 9 月 14 日。环境为 Windows + PowerShell，修复时 CLI 版本为 codex-cli 0.153.4。文中的 CCSwitch 字段和数据库结构来自当时的本机记录，不保证适用于所有版本。

我之前使用 CCSwitch 调整过 Codex 的配置，随后发现账号、模型选择和服务商设置变得混乱。这次恢复分成了两个阶段：我先参考教程恢复官方账号登录，成功进入 Codex 后，再请 Codex 帮我排查和修复剩余配置。

这篇文章记录实际发生的过程，也整理出一套可以借鉴的排查方法。它不是“一键重置教程”：登录信息、模型选择和切换工具的状态需要分别确认。

一、第一步：恢复官方登录

我先按照倍司企业文档的《Codex Desktop 切换回官方登录模式教程》恢复登录，成功进入 Codex 后，才请它处理后面的配置问题。下面按原教程的五步顺序整理，命令保持一致，来源链接附在文末。

1. 删除本地认证文件

按 Windows 键，搜索并打开 PowerShell，粘贴下面的命令后按 Enter：

Remove-Item "$env:USERPROFILE\.codex\auth.json" -Force -ErrorAction SilentlyContinue

这会删除本地保存的认证信息，以便后续重新登录。命令没有输出时，继续下一步。

2. 用记事本修改 Provider

在 PowerShell 中执行：

notepad "$env:USERPROFILE\.codex\config.toml"

在记事本中找到：

model_provider = "custom"

将这一行替换为：

model_provider = "openai"

3. 删除自定义 API Provider 配置段

继续在同一文件中找到 [model_providers.custom] 小节。原教程示例包含下面这些字段，地址和密钥在这里用占位值表示：

[model_providers.custom]
name = "custom"
wire_api = "responses"
base_url = "https://example.invalid/v1"
experimental_bearer_token = "YOUR_API_KEY"

删除对应的整个小节，包括标题和其中的字段。上面的片段用于定位要删除的内容，不要粘贴进去；其他 MCP、Skills、插件和项目配置保留。

4. 保存并关闭记事本

按 Ctrl + S 保存，然后关闭记事本。

5. 退出并重新打开 Codex Desktop

保存正在进行的工作后，在 PowerShell 中执行原教程的退出命令：

Stop-Process -Name Codex -Force -ErrorAction SilentlyContinue

随后重新打开 Codex Desktop，看到官方账号登录入口后，按提示完成登录。我完成这一步后，才开始下文的配置排查。

以上操作只涉及认证文件和相关 Provider 配置，不要删除整个 .codex 目录。

二、登录成功后，为什么还需要继续修复？

进入 Codex 并不意味着所有模型设置已经恢复一致

这里至少有三层状态：

本次修复的关键就是：第一层已经恢复，但第二层还有显式覆盖，第三层仍然记着另一个服务商。

当时实际发现了什么?

1. ChatGPT 登录已经正常

执行：

codex --version
codex login status

当时返回：

codex-cli 0.153.4
Logged in using ChatGPT

认证文件的结构检查也显示 auth_mode 为 chatgpt。后续修复因此没有再修改 auth.json。

这个结果证明当时本地认证方式是 ChatGPT，但并不单独证明每一个模型都能调用成功，也不代表已经核对过桌面端显示的账号和工作区身份。

官方说明，登录缓存可能保存在 auth.json 或操作系统凭据存储中；其中包含敏感凭据。排查时应优先使用状态命令，不要把认证文件全文贴到博客或聊天里。官方认证说明

2. 没有发现已检查环境变量的覆盖

当时检查了进程、用户和系统三个作用域中的以下变量，均未设置：

OPENAI_API_KEY
OPENAI_BASE_URL
CODEX_HOME
CODEX_API_KEY
ANTHROPIC_API_KEY
ANTHROPIC_BASE_URL

这缩小了本次排查范围。它不等于穷尽了所有可能影响行为的配置来源。

3. Codex 用户配置还固定着模型等参数

config.toml 开头当时是：

model_provider = "openai"
model = "gpt-4o-mini"
disable_response_storage = true
model_reasoning_effort = "high"
service_tier = "priority"
personality = "pragmatic"

这段配置说明 provider 已经指向官方，但模型仍被显式固定，推理等级和服务层级也有单独设置。

需要准确地描述这个发现：这些字段不是“出现就一定报错”。本次删除它们，是为了恢复默认选择行为、减少不再需要的覆盖。现有记录也不足以断言每一行都由 CCSwitch 写入，或者其中某一行就是全部异常的唯一原因。disable_response_storage 更不属于模型名称或服务商选择字段，只是本次一并撤销的旧设置。

4. CCSwitch 仍然选中 DeepSeek

当时 CCSwitch 的本地记录是：

这与 Codex 当前文件中的 model_provider = "openai" 不一致。后续如果再次切换服务商，就存在重新写入其他配置的风险。

但这不意味着当时请求已经经过 DeepSeek。数据库中的 Codex 代理状态显示 proxy_enabled = 0、live_takeover_active = 0，排查时也没有发现运行中的 CCSwitch 进程。因此，实际证据支持的是“切换工具记录与当前配置不一致”，而不是“代理仍在接管全部请求”。

四、实际修复：撤销覆盖，并同步 CCSwitch 状态

1. 先备份即将修改的三个文件

本次备份包括：

.codex/config.toml
.cc-switch/settings.json
.cc-switch/cc-switch.db

备份保存在本机 .cc-switch/backups/codex-repair-20260907_114833/ 下。数据库可能包含服务商凭据，因此备份只用于本地回退，不应随文章上传。

读者可以参考下面的备份命令。先正常退出 CCSwitch，并确认其后台进程已经结束；运行中的 SQLite 数据库可能有尚未合并的日志，不能把简单复制主文件视为完整备份。

$repairStamp = Get-Date -Format 'yyyyMMdd_HHmmss'
$repairBackup = Join-Path $env:USERPROFILE ".cc-switch\backups\codex-repair-$repairStamp"
New-Item -ItemType Directory -Path $repairBackup | Out-Null

Copy-Item -LiteralPath (Join-Path $env:USERPROFILE '.codex\config.toml') -Destination (Join-Path $repairBackup 'config.toml.before')
Copy-Item -LiteralPath (Join-Path $env:USERPROFILE '.cc-switch\settings.json') -Destination (Join-Path $repairBackup 'settings.json.before')
Copy-Item -LiteralPath (Join-Path $env:USERPROFILE '.cc-switch\cc-switch.db') -Destination (Join-Path $repairBackup 'cc-switch.db.before')

此示例适用于这些文件实际存在且使用默认目录的情况；自定义配置目录应按实际路径调整。

2. 从 Codex 配置中撤销五个显式设置

在已经备份、退出桌面端和 CCSwitch 的前提下，执行下面的命令，用记事本打开配置：

$repairCodexDir = if ($env:CODEX_HOME) { $env:CODEX_HOME } else { Join-Path $env:USERPROFILE '.codex' }
notepad (Join-Path $repairCodexDir 'config.toml')

本次删除的是：

model_provider = "openai"
model = "gpt-4o-mini"
disable_response_storage = true
model_reasoning_effort = "high"
service_tier = "priority"

操作时按 Ctrl + F 分别搜索这几个字段，只删除文件开头对应的顶层设置。值可能与你的不一样；先确认它们确实是准备撤销的覆盖。不要使用“全文件替换”误删其他 profile 或子配置里的同名字段。

以本次文件为例，修改后开头只保留：

personality = "pragmatic"

这只展示文件开头的结果，不能用这一行覆盖整个文件。下面原有的插件、MCP 等内容仍应保留。按 Ctrl + S 保存并关闭记事本。

model_provider 的默认值就是 openai，所以在本次没有其他相关覆盖的情况下，可以省略它。模型不再由这份用户配置固定，后续应在桌面端按账号实际可用列表选择。

第一部分显式写 openai 是为了让登录恢复步骤清楚可见；这里撤销这行，是回到默认值。也可以保留 model_provider = "openai" 来明确表达选择，它与本次省略该字段的目的相同。

这不是把默认模型指定成某个“最新型号”，也不会增加账号权限。原有的 personality、插件、MCP、项目可信设置、语言和其他桌面端配置都保留了。

3. 让 CCSwitch 也回到官方服务商

本次在确认 CCSwitch 未运行、备份完成后，同步修改了它的设置文件和数据库：

数据库修改使用事务，并在写入前确认本机确实存在唯一的官方 Codex 条目。DeepSeek 的配置记录仍保留，只是不再选中。

这里记录的是本次具体处理，不建议直接照抄数据库写入语句。普通使用者应优先通过自己版本的 CCSwitch 界面选择官方条目，再核对落盘结果；确需手工修数据库时，必须先检查表结构和条目 ID。

读者操作：先在 CCSwitch 选择官方，再检查配置文件

打开 CCSwitch，切到 Codex 对应的服务商列表，找到官方 OpenAI 条目并设为当前使用。如果界面提供“切换时保留 Codex 官方认证”选项，将它开启。各版本入口名称可能不同；没有官方条目时，不要只在文件里填写一个猜测的 ID。

切换可能重新写入 config.toml。因此应在完成切换并退出 CCSwitch 后，重新检查上一小节的模型覆盖项。若切换后认证发生变化，也要重新确认登录状态。

对于和本次相同、配置保存在用户目录下的版本，可以这样打开 CCSwitch 设置文件：

notepad (Join-Path $env:USERPROFILE '.cc-switch\settings.json')

按 Ctrl + F 找到：

"preserveCodexOfficialAuthOnSwitch": false

将 false 替换为 true，其他字符保持原样。如果这行末尾原本有逗号，保留逗号。不要用这个片段覆盖整个 JSON 文件，也不要粘贴一个重复键。找不到该字段时，先确认版本是否支持，不盲目添加。

再搜索 currentProviderCodex。本次正确值是 codex-official，但这个字段必须与数据库里的实际条目一致，不能只改设置文件就宣称切换完成。数据库不要用记事本编辑。

保存后可执行下面的只读检查，验证 JSON 能解析，并只显示这两个非敏感字段：

$repairSwitchSettings = Get-Content -Raw -LiteralPath (Join-Path $env:USERPROFILE '.cc-switch\settings.json') | ConvertFrom-Json
$repairSwitchSettings | Select-Object currentProviderCodex, preserveCodexOfficialAuthOnSwitch

本次预期分别为 codex-official 和 True。这个检查只验证设置文件；重新打开 CCSwitch 后，还应确认界面选中的确实是官方条目。

参考资料

• 倍司企业文档：Codex Desktop 切换回官方登录模式教程：我首先参考的登录恢复教程。本文第一部分按其五步顺序整理，沿用删除认证文件、打开记事本和退出应用的命令；示例地址和密钥替换为占位值。后续配置修复来自本次实际操作。
• OpenAI 官方配置参考：provider 默认值及自定义配置字段定义。
• OpenAI 官方认证说明：登录状态检查与凭据缓存说明。

本文中的修复前后配置、命令结果与验证边界，来自 2026 年 9 月 7 日的实际操作记录；个人绝对路径、第三方条目随机 ID 和凭据已省略。