ChatGPT APP (Codex Desktop) node_repl 修复

ChatGPT APP (Codex Desktop) node_repl 修复
狂犬主子
最近在使用 Codex 接入第三方模型的过程中,我遇到了一个很奇怪的问题:配置了第三方模型之后,node_repl 以及依赖它的 Browser、Computer Use 等功能就无法正常使用。
一开始我也以为是“第三方模型不支持 node_repl”,于是各种查 Issue、翻教程、改配置、折腾 Skills,最后发现事情没有这么简单。
这次排查下来,我认为这里其实叠加了两个问题:
- Codex 的 custom
model_provider本身就存在 Browser / Computer Use 与动态工具发现(tool_search)方面的兼容问题。官方仓库目前就有一个非常接近这个现象的 Issue:同一台机器、同一套插件,在官方后端可以正常使用mcp__node_repl__js,切换到 custom provider 后却无法发现这个工具。 - 第三方配置工具又可能把 Codex 的
config.toml当成普通的“供应商配置”进行保存和覆盖。但 Codex 的config.toml实际上不只是模型和 API 配置,其中还包含大量由 Codex 根据当前版本、本机路径和运行时环境生成的状态。CC Switch 的公开 Issue 中已经有人报告了切换 provider 会整体覆盖config.toml,从而丢失 Codex 自己维护的动态状态。
因此,我这篇文章主要记录的是第二类问题:第三方配置工具保存的旧配置,与新版 Codex Desktop 自动生成的运行时配置发生冲突。
如果你遇到的是“官方模型正常,第三方模型无论怎么重建配置都无法使用 Browser / Computer Use”,那么还需要考虑 custom provider 本身的限制,不能简单归结为配置文件损坏,可尝试更新版本。另外,Codex 有AB灰度测试,因此这些功能都存在随机性。
背景
配置 Codex 的第三方模型,除了修改 ~/.codex/config.toml 之外,通常还需要配置 model_catalog_json。
可以通过下面的命令提取当前 Codex 自带的模型目录:
1 | codex debug models --bundled > ~/.codex/models_bundled.json |
比如直接在命令行运行 codex,然后在 TUI 中输入 /models,这里显示的模型信息就会涉及 Codex 的模型目录;使用 Desktop 时,模型选择器同样需要正确的模型元数据。


这个文件里面包含了模型的一些详细的参数,包括上下文窗口、输出限制、reasoning 等模型能力相关信息,甚至还包含了系统的提示词。

这也是为什么配置第三方模型的时候,通常不会让普通用户从头手写这些东西。除非你是神或者你使用 AI。
我们一般会使用第三方工具辅助配置,比如CC Switch、Codex++之类的,它会自动生成这种文件,非常的方便。还有一种情况就是模型提供商会给个脚本或者配置文件,比如说DeepSeek 的 Codex Agent 集成文档。
按照正常的情况,使用OpenAI账号登录的Codex应该是能正常使用的,不然官方早就炸锅了(其实已经炸锅了),真正开始出现问题,往往是在我们加入第三方模型、代理以及第三方配置工具之后。
你去翻这些配置工具的 GitHub Issues,可能真的会找到几个出现和你一样问题的兄弟,但这些 Issues 要么会神不知鬼不觉地关掉,要么没人解决,你根本都不知道人家是怎么修好的。即使你去 L 站找到教程,人家告诉你改这改那的,甚至让你弄一堆 skills 让它~~“玄武修复”~~。你根本不清楚是哪一项配置导致了你的ChatGPT APP(Codex Desktop)无法调用node_repl 。即使你这次修好,下次一更新又没法用了。
核心
Codex 的 config.toml 并不是一份普通的供应商配置,这可能是整个问题最容易被忽略的地方。
很多第三方模型切换工具最初都是围绕 Claude Code 之类的软件设计的。Claude老师,我还记得你~Claude Code 的配置相对简单,很多东西本质上就是环境变量或者几层 JSON 配置。开发模型切换工具的时候,自然会形成一种思维惯性:
保存一份公共配置 → 保存不同供应商的配置 → 切换时把两份配置合并 → 写回目标软件。
对于简单的配置文件,这种方式其实没有什么问题。但 Codex 的 config.toml 不太一样。它不仅包含模型的配置信息,还可能包含:
- 项目信任状态;
- Plugins;
- MCP Server;
- Marketplace;
- Desktop 设置;
- Codex Desktop 生成的 runtime 路径;
- Browser / Computer Use 使用的环境变量;
- runtime 版本;
- SHA256 trust 信息;
- 本机绝对路径。
也就是说,它更像是一份“用户配置 + 应用状态 + 本机运行时状态”混合在一起的配置文件。
而这就产生了一个问题。
第三方配置工具通常需要把供应商配置保存到自己的数据库中,例如 SQLite。但问题在于,它保存的其实是某个时间点的 Codex 配置快照。而 Codex Desktop 自己还会继续修改这份 config.toml。于是,Codex 更新了,运行时配置变了,第三方工具数据库里的旧快照却没有同步更新。下一次切换供应商时,第三方工具再把自己的配置写回 config.toml,新旧配置就可能发生冲突。

由于各种原因无法跟上最新的 TOML 版本,最终导致配置文件与最新版本的 ChatGPT APP(Codex Desktop)对不上,然后就出现了一些奇奇怪怪的问题,在我的实际环境里,出现过包括但不限于:
node_repl无法正常使用;- Browser / In-App Browser 无法使用;
- Computer Use 无法使用;
apply_patch等工具不可用;- 模型退回使用 PowerShell 写文件,在 Windows PowerShell 5.x 环境下进一步出现中文编码问题。
为什么会造成这一系列问题呢?主要还是在第1点 node_repl 上。这里要特别说明一下:并不是说“只要配置文件损坏,就一定会同时出现上述所有问题”,而更像是不同层面的连锁反应,其中最关键的还是 node_repl。
node_repl 到底是什么?
实际上,Codex 的这些工具,是使用“内置”的 NodeJS 作为运行环境的,通过 MCP 的方式给模型提供 node_repl 能力。这种 Work Agent 是不应该要求用户手动配置编程环境的,类似的产品如 WorkBuddy 也是一样的,都会自带环境。
Codex 的 Computer Use 则是通过 Skills 的方式实现的,但是他那个程序有访问限制只能使用内置的 node_repl 环境才能调用 CUA。




下面是我机器上一次正常运行时的配置片段,现在就清楚多了:
1 | model_provider = "custom" model = "deepseek-v4-flash-free" model_reasoning_effort = "high" disable_response_storage = true notify = [ "C:\Users\x\AppData\Local\OpenAI\Codex\runtimes\cua_node\9ec47c3bbf131bc8\bin\node_modules\@oai\sky\bin\windows\codex-computer-use.exe", "turn-ended" ] approval_policy = "on-request" sandbox_mode = "workspace-write" web_search = "live" model_catalog_json = "cc-switch-model-catalog.json" [model_providers.custom] name = "custom" wire_api = "responses" requires_openai_auth = true base_url = "http://127.0.0.1:15721/v1" experimental_bearer_token = "PROXY_MANAGED" [marketplaces.openai-bundled] last_updated = "2026-08-15T02:18:26Z" source_type = "local" source = '\?\C:\Users\x\.codex\.tmp\bundled-marketplaces\openai-bundled' [projects.'c:\users\x\test'] trust_level = "trusted" [projects.'c:\users\x\documents\codex\2026-08-15\ni-h'] trust_level = "trusted" [projects.'c:\users\x\documents\codex\2026-08-15\node-repl'] trust_level = "trusted" [projects.'c:\users\x\documents\codex\2026-08-15\node-repl-2'] trust_level = "trusted" [projects.'c:\users\x\documents\codex\2026-08-15\node-repl-3'] trust_level = "trusted" [projects.'c:\users\x\documents\codex\2026-08-15\browser-comments-user-comment-1-file'] trust_level = "trusted" [plugins."browser@openai-bundled"] enabled = true [plugins."visualize@openai-bundled"] enabled = true [features] js_repl = false [shell_environment_policy.set] BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab" NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S = "0b6d31ced7f1e01dcc1e3aba9416cb1ed01f17e76030ef4a4d1d3e19fd8e0bc6" NODE_REPL_TRUSTED_CODE_PATHS = 'C:\Users\x\.codex;C:\Users\x\AppData\Local\OpenAI\Codex\runtimes\cua_node\9ec47c3bbf131bc8\bin\node_modules' [desktop] conversationDetailMode = "STEPS_COMMANDS" sansFontSize = 14 codeFontSize = 13 ambient-suggestions-enabled = false show-context-window-usage = true followUpQueueMode = "queue" [windows] sandbox = "elevated" [sandbox_workspace_write] network_access = true [mcp_servers] [mcp_servers.node_repl] args = [] command = 'C:\Users\x\AppData\Local\OpenAI\Codex\runtimes\cua_node\9ec47c3bbf131bc8\bin\node_repl.exe' startup_timeout_sec = 120 [mcp_servers.node_repl.env] NODE_REPL_NATIVE_PIPE_CONNECT_TIMEOUT_MS = "1000" NODE_REPL_NODE_MODULE_DIRS = 'C:\Users\x\AppData\Local\OpenAI\Codex\runtimes\cua_node\9ec47c3bbf131bc8\bin\node_modules' NODE_REPL_NODE_PATH = 'C:\Users\x\AppData\Local\OpenAI\Codex\runtimes\cua_node\9ec47c3bbf131bc8\bin\node.exe' NODE_REPL_TRUSTED_CODE_PATHS = 'C:\Users\x\.codex;C:\Users\x\AppData\Local\OpenAI\Codex\runtimes\cua_node\9ec47c3bbf131bc8\bin\node_modules' CODEX_HOME = 'C:\Users\x\.codex' NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S = "0b6d31ced7f1e01dcc1e3aba9416cb1ed01f17e76030ef4a4d1d3e19fd8e0bc6" BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab" NODE_REPL_INSTRUCTIONS_USE_CASE_BROWSER = "Control the in-app browser in conjunction with the Browser Plugin." NODE_REPL_INSTRUCTIONS_USE_CASE_CHROME = "Control the Chrome browser in conjunction with the Chrome Plugin. Prefer this method of controlling Chrome over alternatives (such as Computer Use) unless the user explicitly mentions an alternative." BROWSER_USE_CODEX_APP_BUILD_FLAVOR = "prod" BROWSER_USE_CODEX_APP_VERSION = "26.810.50856" SKY_CUA_NATIVE_PIPE = "1" SKY_CUA_NATIVE_PIPE_DIRECTORY = '\.\pipe\codex-computer-use-bbbbbbbb-cccc-5555-aaaa-777777777777' CODEX_CLI_PATH = 'C:\Users\x\AppData\Local\OpenAI\Codex\bin\697a646d3cf0f240\codex.exe' |
里面有一堆的随机字符串、版本号,还有 SHA256 这种哈希校验,而且路径还是绝对路径。如果一个包含这么多运行时路径和 hash 的配置文件跨版本完全不变,我可以当场把这个电脑屏幕吃掉。所以你把我这份配置文件复制过去,也是没法使用的。
这也是为什么我认为第三方工具最容易踩坑的地方就在这里:它们需要管理供应商配置,但 Codex 的 config.toml 同时又承载了很多不应该被当成供应商配置保存的动态状态。
于是后面的事情就很典了:Codex Desktop 更新了,新的 runtime 也更新了,新的 node_repl、Browser、Computer Use 配置也生成了,然后第三方工具拿着自己数据库里上一版本的配置,再次覆盖 config.toml。
最后你就会看到:。node_repl 死了喵
解决
如果你已经确定自己遇到的是配置被第三方工具覆盖/污染这一类问题,要解决这个问题,核心就在于我们要让模型配置工具数据库里的配置文件与最新版本的 Codex 配置相统一。
这里给出一个解决这个问题的最彻底方案——让 Codex 重新生成一份当前版本的配置。
提醒一下,我这个方法比较兜底,会导致你的 Codex 里面的历史记录全部清空。出现数据丢失本人一概不负责。
如果你对 Codex 的文件结构比较熟悉,也可以不全删,而是只处理已经确认有问题的配置项。
1. 确保组件已经升级
在所有步骤之前,请务必确保你使用的 Codex、ChatGPT、CC Switch、Codex++ 为最新版本,必须检查是否是最新,尤其是 Codex Desktop,这个天天更新。这些属于已知严重影响体验的问题,正常是会进行修复适配的,只不过人家不一定能帮你重建配置罢。但如果你不升级到最新版本,那瞎折腾没有任何用处,本篇教程作废。
2. 彻底退出相关程序
把 Codex Desktop、ChatGPT、CC Switch、Codex++ 等相关程序全部退出。不仅要关窗口,还要注意任务栏托盘。然后打开任务管理器,检查是否还有:codex、ChatGPT、CC Switch、codex++ 之类的进程,有的话全部结束掉。
3. 重置Codex
首先建议把%USERPROFILE%\.codex 先完整备份一份,然后再考虑删除。在用户文件夹的 AppData 底下还有 Codex 文件夹,我们也最好将其删除:
%USERPROFILE%.codex或~/.codex%APPDATA%\Codex%LOCALAPPDATA%\OpenAI%LOCALAPPDATA%\Codex
这么删除,100% 会丢失历史记录。
为什么要全删呢?个人遇到仅删除里面的
config.toml文件,并不会导致配置完整重建,甚至还会出现无法UAC提权的问题。如果你对 Codex 比我熟悉的话,那你可以选择性地删除一部分。
下次重新执行ChatGPT APP(Codex Desktop)的时候,100% 会重新创建这个目录,配置也会随着重建而重建。
4. 先让 Codex 在干净环境下启动一次
这些东西清理干净以后,使用官号是不会出现问题的。我们要的就是这一个效果,就是要把这个状态给它持久化。
先别开蹬。直接启动 ChatGPT App(Codex Desktop)。如果没有官号,在首次运行的过程中:
- 选择“其他登录方式”;
- 在 API key 里面随便乱输点东西,回车;
- 完成那个个性化设置,直接进入主界面;
- 趁着这次机会设置你的偏好。后面就不要再配置了,这些配置是存在
config.toml里面的,一切换提供商他又没得了,因为你大概率记不起来点更新通用配置; - 将 ChatGPT APP(Codex Desktop) 彻底退出。
你可能需要使用魔法才能下载中文语言包。
5. 重新配置第三方模型
现在才轮到 CC Switch / Codex++。这里最重要的一点是:不要直接拿旧的第三方工具数据库覆盖刚刚生成的新配置。所以,我们需要同时清空这些第三方模型配置工具的数据,例如 CC Switch 的用户数据目录包括:
%USERPROFILE%.cc-switch或~\.cc-switch%LOCALAPPDATA%\com.ccswitch.desktop%APPDATA%\com.ccswitch.desktop
如果第三方工具已经长期使用,而且里面保存了大量旧的 Codex 配置,那么建议先备份它们的数据。
当然,你要是有办法使用
sqlite或者是一些工具更改它的数据库的话,那也是可以的。但我这边为了避免麻烦,直接全部清空。
CC Switch 的公开 Issue 已经有案例表明,其内部数据库中的 Codex 配置和 MCP 状态可能影响最终写入的
config.toml。所以,如果你只是通过客户端 UI 删除某个供应商,并不一定等价于“数据库里关于这个供应商的所有旧状态都消失了。”这也是我这次选择重新初始化的原因。
6. 让第三方工具重新读取当前配置
现在打开 CC Switch,重新配置你的第三方模型。你新建供应商了以后,会发现它底下的那些配置已经自动覆盖为通用配置了。因为这个时候CC Switch是干净的,它读取 Codex 的配置文件也是正确的,**正常情况下,CC Switch 的这个默认配置是能用的。**也不用管那个 node_repl 的 MCP,它默认就是启用的。
测试
最简单的测试方法,就是让模型真正做一次需要 node_repl 的操作。这里我是打开它侧边栏的浏览器,让 AI 自动执行操作,测试是没有问题的。

这也就解释清楚了,为什么维护者没有办法复现用户那些奇奇怪怪的情况,因为人家可能用的是干净环境或者是虚拟机,没有那些乱七八糟的通用配置。
我建议你在知道需要调用这个 node_repl 的情况下,执行一次这种测试——问问 AI 这个 node_repl 到底正不正常。不然的话,到时候只是浪费模型的 Token,只能看着 AI 在各种挣扎,但无能为力。
周期
修好以后能用多久呢?我不知道。但如果这些工具一直不适配,仍然采用“保存一份 Codex 配置快照 → 切换 provider 时重新写回”的方式,就存在再次发生配置覆盖的可能,那你每升级一次都得执行这一轮操作。我们只能尽量避免新旧配置的冲突。
为了避免配置文件被覆盖,我这里提供了个方法:
- Codex Desktop 更新以后,先不要启动 CC Switch。因为开启 CC Switch 后,如果你使用它的路由,把第三方模型的 chat 转为 responses,会覆盖你的配置文件,我估计问题就出在这里。
- 第一次启动把它当成“迁移启动”。升级完第一次启动 ChatGPT APP(Codex Desktop)就别想着直接开蹬——先让 Codex Desktop 自己完整启动一次,让它完成自己的初始化和迁移。
- 备份新的
config.toml。迁移完成以后,彻底退出 ChatGPT APP(Codex Desktop),赶紧去.codex目录底下备份好你的config.toml配置文件,避免到时候又要重置。 - 更新第三方工具以后,对比配置再切换。打开 CC Switch / Codex++,对比一下你的配置文件与供应商那里的配置文件有什么区别。如果有区别,就改为新的配置并手动保存一下,然后给它提取到全局配置。
这样操作的话,配置文件可能就不会被改乱了。不然的话,又只能重置了。
参考
- Codex 官方仓库:Browser / Computer Use 与 custom provider 的 tool_search 问题 #31750
- CC Switch:切换 Codex provider 整体覆盖 config.toml #5770
- CC Switch:保存 Codex 配置时重新注入 node_repl #4779
- Codex 官方 config schema
- CC Switch Codex 配置说明
- 知乎相关文章
- Linux.do 相关讨论 1
- Windows Codex Fast Patch Skill
- Linux.do 相关讨论 2
- Linux.do 相关讨论 3
- CC Switch
node_replIssues - Codex
node_replIssues

