Codex app-server 启动失败：按报错原文对症修，先别删 .codex

Windows 上的 Codex 桌面应用（2026 年 7 月 9 日起并入 ChatGPT 桌面应用，所以弹窗里写的是 "ChatGPT failed to start"）和 ChatGPT 浏览器扩展，都要靠一个后台进程 codex.exe ... app-server 干活。报错里出现 app-server，说明这个进程没找到文件、没在期限内完成初始化，或者一启动就崩了。四条常见报错分别坏在不同环节，修法不能混用：先在下表找到你的原文，再跳到对应小节。

两条规则先说在前面。关窗口不等于退出：应用会常驻系统托盘，后台进程继续占着数据库，所以动任何文件之前都要从托盘退出。%USERPROFILE%\.codex 里存着本地对话记录、登录状态和配置，重装应用不会碰它，删掉它也修不好上面任何一条。

截至 2026 年 10 月 9 日，这四条报错都没有 OpenAI 公布的根因或修复版本，更新日志里也没有提到这几句原文。下面的修法除特别注明外，都是用户在 GitHub issue 里报告的变通办法，每条都标出有几人验证过。

动手前：确认装的是哪个应用，彻底退出，再备份 .codex

先确认版本和包名。官方文档现在把它叫做 ChatGPT desktop app for Windows，但 Windows 里的包名仍然是 OpenAI.Codex，商店 ID 是 9PLM9XGG6VKS。另有一个叫 ChatGPT Classic 的旧应用（包名 OpenAI.ChatGPT-Desktop），里面没有 Codex 的 app-server；有用户通过普通的 ChatGPT 下载链接重装，结果装成了它。

Get-AppxPackage -Name "OpenAI.*" | Select-Object Name, Version

输出里应该有 OpenAI.Codex。版本号记下来，后面判断分支和提交问题都要用。

然后彻底退出：在任务栏右下角的托盘图标上选择退出，VS Code 等编辑器里的 Codex 扩展也一并关掉。确认后台进程已经没了：

Get-Process ChatGPT, codex, node_repl -ErrorAction SilentlyContinue

没有输出才算退干净。还有残留时，用 Stop-Process -Name ChatGPT, codex, node_repl -Force 结束。

最后备份 .codex。先看看对话记录有多大，有用户的 sessions 文件夹累积到 22.24 GB，这时最好备份到另一个磁盘：

Get-ChildItem "$env:USERPROFILE\.codex\sessions" -Recurse -File -ErrorAction SilentlyContinue |
  Measure-Object Length -Sum | Select-Object Count, @{N='GB'; E={[math]::Round($_.Sum/1GB, 2)}}

$stamp = Get-Date -Format yyyyMMdd-HHmm
Copy-Item "$env:USERPROFILE\.codex" "$env:USERPROFILE\Desktop\codex-backup-$stamp" -Recurse

.codex 里几个关键文件：state_5.sqlite 是对话列表的索引，sessions\ 是本地对话记录，config.toml 是配置，auth.json 是登录凭据，另外还有记忆和插件状态。下文要你"移走"的文件，都是挪到旁边的文件夹，随时可以搬回来。

failed to start codex app-server（os error 3）：改掉更新后失效的路径

这条报错通常在 Browser Use、内置浏览器或 Chrome 插件干活时出现：标签页能列出来，但 tab.goto()、DOM 快照和截图全部失败，有时显示的是 os error 2。os error 3 是 Windows 的"找不到路径"。报错来自 node_repl.exe，它要启动 codex app-server --listen stdio://，却找不到该启动的那个 codex.exe。

原因已经被多名用户还原出来：应用会把辅助程序从 C:\Program Files\WindowsApps\ 复制到 %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\ 和 %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\，每个版本的 hash 都不一样。自动更新删掉旧文件夹后，下面几处还记着旧路径：

• %USERPROFILE%\.codex\config.toml 里的 [mcp_servers.node_repl] 一节（command、CODEX_CLI_PATH、NODE_REPL_NODE_PATH 等）
• 用户环境变量 CODEX_CLI_PATH
• chrome-native-hosts-v2.json（浏览器扩展用的那份记录，下一节细说）

最早的报告 #19187 从 2026 年 4 月 23 日开到现在，OpenAI 员工把后来的同类报告标成它的重复；#20206 等同类 issue 里，"还在发生"的留言一直持续到 2026 年 9 月 22 日。

第一步：找出哪些路径已经失效

彻底退出应用后，在 PowerShell 里列出 config.toml 里记录的所有 .exe 路径，False 就是已经不存在的：

$cfg = "$env:USERPROFILE\.codex\config.toml"
Select-String -Path $cfg -Pattern "[A-Za-z]:\\[^'`"\r\n]+?\.exe" -AllMatches |
  ForEach-Object { $_.Matches.Value } | Sort-Object -Unique |
  ForEach-Object { "{0}  {1}" -f (Test-Path $_), $_ }

[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")

再看现在实际存在的文件在哪个 hash 文件夹里：

Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex" -Recurse -Include codex.exe, node_repl.exe, node.exe -ErrorAction SilentlyContinue |
  Select-Object FullName, LastWriteTime

第二步：把旧路径改成现存路径

先复制一份 config.toml，再把失效的路径换成上一步找到的现存路径。#26011 里的报告者改成了这样（<user> 和 <hash> 换成你的实际值）：

[mcp_servers.node_repl]
command = 'C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\<hash>\node_repl.exe'

[mcp_servers.node_repl.env]
CODEX_CLI_PATH = 'C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\<hash>\codex.exe'

Windows 路径要用单引号，或者把反斜杠换成正斜杠。写在双引号里时 \ 会被当成转义符，有用户因此卡在启动界面，日志里是 missing escaped value。config.toml 其他字段怎么写，可以看 Codex 沙箱与 config.toml：权限、批准和网络怎么配。

用户环境变量 CODEX_CLI_PATH 如果指向不存在的文件，直接删掉比改成另一个 hash 更稳：

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")

有用户把它指向旧版本的 codex.exe 后，应用能启动了，跑的却是旧版 CLI，之后对话又出错。改完后彻底退出、重新打开，在新对话里让它打开一个网页并截图，能截图就说明修好了。这个办法有多名用户验证。其中一位遇到的路径失效还被误报成"企业网络策略拦截"，所以看到这类提示也可以先查路径。

2026 年 4–5 月的版本：bin 文件夹整个不存在

在 26.422、26.429 这批版本上，%LOCALAPPDATA%\OpenAI\Codex\bin 有时根本没有被创建，辅助程序只留在 %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin。先把应用更新到最新版：有用户报告 26.506 已经能正常创建这个文件夹。更新后仍然没有时，多名用户的做法是建一个目录联接：

New-Item -ItemType Junction -Path "$env:LOCALAPPDATA\OpenAI\Codex\bin" `
  -Target "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin"

有一位用户在干净的虚拟机上这样做之后，报错变成了沙箱错误 CreateProcessAsUserW failed: 5，只有在完全访问模式下 Browser Use 才能用。

据多名报告者反馈，对这条报错没用的做法有：应用设置里的修复和重置、单纯重装、重启电脑、以管理员身份运行、另装一份 npm 版 Codex CLI。

missing required path nodePath / resourcesPath：让浏览器扩展找到新路径

这条报错出现在 Chrome、Edge、Brave 的 ChatGPT 扩展侧栏里，标题是 "Unable to start ChatGPT"，下面写着 Codex app-server manifest entry is missing required path nodePath，也可能是 resourcesPath 或 codexCliPath。

扩展本身不运行 Codex，它的调用链是这样的：浏览器通过原生消息主机 com.openai.codexextension 启动 .codex\plugins\cache\openai-bundled\chrome\latest\ 下面的 extension-host.exe，后者读取 chrome-native-hosts-v2.json，再按里面记录的 nodePath、resourcesPath 等路径启动 app-server。所谓 "missing"，多名用户确认是这个路径已经不存在，而不是字段缺失：桌面应用更新时删掉了旧的 cua_node\<hash> 运行时和旧安装目录，这份记录却没有跟着更新。2026 年 10 月 3 日和 10 月 8 日的更新之后，又有用户在 #32706 和 #40357 里报告复发。

从最轻的做法开始：

1. 先打开桌面应用，等 30–60 秒再用扩展。 扩展只在桌面应用运行时才能工作，有一两位用户这样就恢复了。
2. 走一遍官方的连接检查（浏览器扩展文档里的排查步骤，没有点名这条报错）：更新桌面应用；装了不止一个 ChatGPT 或 Codex 桌面应用时，每个都更新，不用的删掉；重启浏览器；在桌面应用的 Settings → Computer Use 里确认浏览器显示 Manage 而不是 Install；使用装了扩展的那个浏览器配置文件；新开一个对话再试；重启桌面应用；仍不行就从 Settings → Computer Use 重新安装扩展。
3. 在桌面应用里让 Codex "connect to Chrome"，有一位用户这样让状态重新生成了。

OpenAI 支持人员在论坛回复里建议，不要反复重试安装插件、卸载插件或清缓存。上面几步都不行时，再手动修那份记录：

# 当前最新的 Node 运行时文件夹
Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node" -Directory |
  Sort-Object LastWriteTime -Descending | Select-Object -First 1 FullName

# 当前安装目录下的 resources
(Get-AppxPackage -Name OpenAI.Codex).InstallLocation + "\app\resources"

关掉桌面应用和浏览器，先复制一份 %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json，再把里面的 nodePath 改成 <运行时文件夹>\bin\node.exe，nodeModuleDirs 改成同一位置的 node_modules，resourcesPath 改成上面输出的 resources 路径。JSON 里的反斜杠要写成 \\。保存后先启动桌面应用，再打开浏览器。这个做法有多名用户验证。#35705 里还有用户贴出了自动完成这几步的 PowerShell 脚本 Repair-CodexChromeManifest.ps1，它会先备份，并支持用 -WhatIf 预览改动，另有一人确认有效。脚本不是 OpenAI 提供的，运行前先读一遍。

如果连 chrome\latest 联接也指向了被删掉的版本，就需要从安装目录恢复插件缓存、重建联接和两份 v2 记录。这一步比较复杂，#42520 里有多名用户在 26.930.2377.0 上做成功的完整步骤。

修好的标志是侧栏正常加载，可以在桌面应用里用 @Chrome 之类的提及调用浏览器。

initialize handshake timed out：app-server 没在 30 秒内完成握手

按官方说明，客户端连上 app-server 后要先发一个 initialize 请求，这一步就是"握手"（handshake）。桌面应用只给它 30 秒，#39015 的日志里能看到 durationMs=30012、cause=initialize_handshake_timeout。30 秒这个期限是从日志里看到的，文档里没有写。

它和 15 秒的云端配置包超时不是一回事。如果你的报错是 timed out waiting for cloud config bundle after 15s，请看 Codex 启动超时：先查云端配置包，再处理连接、MCP 和进程。

按代价从小到大试：

1. 移走日志数据库 logs_2.sqlite。 这是证据最多的原因：日志库太大或已经损坏，app-server 启动时打开它就超时。有用户的日志库有 6.7 GB；另一位的 2.27 GB 日志库损坏，移走后握手时间降到 1.7 秒。按 #39015 的说明，这个库里没有对话和设置。从托盘彻底退出后，三个文件一起移走：

$codex = "$env:USERPROFILE\.codex"
Get-ChildItem "$codex\logs_2.sqlite*" | Select-Object Name, @{N='MB'; E={[math]::Round($_.Length/1MB)}}

$hold = "$codex\hold-logs-$(Get-Date -Format yyyyMMdd-HHmm)"
New-Item -ItemType Directory $hold | Out-Null
Move-Item "$codex\logs_2.sqlite*" $hold

重新打开应用，它会建一个新的日志库。OpenAI 员工在 #23917 里说，新版本会检测并报告数据库损坏，自动修复还在开发中，没有给出版本号。

2. 清掉占着数据库的残留进程。 有一位用户遇到过十几次：上次没退干净的进程锁住了状态数据库。结束 Get-Process *codex*, *chatgpt*, *node_repl* 列出的进程后重新打开（#32160，单人报告）。

3. 用 WSL 跑 Codex 的，先关掉 WSL 模式。 在 WSL 模式下，启动时要通过 /mnt/c 回填状态，有人超过了 30 秒。在 config.toml 里加上下面的设置，或者等回填跑完（约 40 秒）再重新打开（#38345，单人报告）：

[desktop]
runCodexInWindowsSubsystemForLinux = false

代价是关掉之后，在 WSL 下建的对话暂时打不开（#39169）。

4. 对话记录特别大时，临时移走 sessions。 一位 Reddit 用户在 sessions 有 22.24 GB 时，只移日志库没用；完整备份后，把 sessions、archived_sessions 和 state_5.sqlite* 移到另一个盘，应用才打开（原帖）。这样做之后对话列表会暂时变空，文件搬回来之前看不到旧对话，所以放在最后，而且一定是移走，不是删除。同一帖里另有两人说，他们真正的原因是 WSL 模式。

还有一位用户切换了 Clash 代理节点就好了（#29040），只有这一例。

0xC000001D（code=3221225501）：先查是谁注入了 codex.exe

完整报错一般是：

ChatGPT failed to start. (code=3221225501, signal=null). Most recent error: Codex app-server websocket closed (code=3221225501)

3221225501 换成十六进制就是 0xC000001D，含义是 STATUS_ILLEGAL_INSTRUCTION：codex.exe 执行到一条 CPU 无法执行的指令，进程直接崩溃。有时界面上只显示 Codex app-server process is not available。

先看是哪个模块崩的：打开事件查看器，进入 Windows 日志 → 应用程序，找来源为 Application Error、应用名是 codex.exe 的错误，看"错误模块名称"（Faulting module name）。

错误模块是 ASProxy64.dll：卸掉 Astrill 的 LSP

ASProxy64.dll 是 Astrill VPN 装进 Winsock 的 LSP 组件，它会被注入到 codex.exe 里。这是桌面版 0xC000001D 证据最多的原因，#30884 和 #24408 里的报告者用的都是 Zen 5、Core Ultra、i7-14700KF 这类新 CPU，所以问题不在 CPU 太老。多名用户验证过的做法，任选一种：

• 在 Astrill 里按住 Ctrl 打开菜单，Help → LSP Uninstall，然后重启电脑。
• 用管理员终端检查并重置 Winsock 目录，然后重启。注意 netsh winsock reset 会重置所有 LSP，不只 Astrill 的：

netsh winsock show catalog | findstr ASProxy
netsh winsock reset

• 直接卸载 Astrill。

重启后运行 tasklist /m ASProxy64.dll，显示没有任务在运行，就说明 DLL 已经不再注入，这时再打开应用。想继续用 Astrill 的用户报告，OpenWeb 和 WireGuard 协议不会装这个 LSP，去掉 LSP 后 StealthVPN 也照常可用。如果错误模块是别的第三方 DLL，情况可能类似，但目前只有 Astrill 有成批的验证报告。

错误模块是 codex.exe 本身：本地多半修不了

这时更可能是某些版本的 codex.exe 用到了你的 CPU 不支持的指令。目前有两个相关案例，都不是桌面版：npm 版 CLI 0.135.0 在 Haswell 至强上崩溃，OpenAI 员工回复"下个版本修复"，临时办法是退回 0.134.0（#25367）；VS Code 扩展里的 codex.exe 在 Zen 3 和 Raptor Lake 上报 HW capability requested: 0x200000，报告者说 WSL2 里的 Linux 版能用（#17410，仍未关闭）。桌面版的 0xC000001D 没有任何 OpenAI 员工回复，当前版本具体要求哪些 CPU 指令也没有公开说明。

对这一分支，多名用户报告重装、重新注册应用包、装 VC++ 运行库、删 SQLite 数据库、清空 .codex 都没有效果。能做的是按文末的清单收集信息、提交报告；需要临时继续工作的话，可以参照 #17410 的报告者，改在 WSL2 里用 CLI。

其他 app-server 报错和启动卡住：对照表

不是上面四条时，按原文在这里找：

卡在 logo 时只结束 app-server 进程，可以用这条命令（来自 Qiita 上的记录）。结束 exec-server 没用，结束全部 codex.exe 会打断其他会话：

Get-CimInstance Win32_Process |
  Where-Object { $_.Name -eq "codex.exe" -and $_.CommandLine -like "* app-server *" } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

应用已经正常打开、只是用着用着断线重连，那是另一类问题，见 Codex 一直 Reconnecting：先保住任务，再定位是哪一层断了。

删 .codex、重置、以管理员运行：这些做法修不好还有代价

• 删除 .codex 文件夹。 有用户排查时这样做，丢了全部对话记录；在 #30884 和 #30339 里，删掉它也没有修好 0xC000001D。OpenAI 支持人员在论坛回复里也说，没备份就不要删 %USERPROFILE%\.codex。启动卡住时，他们建议的是把 %APPDATA%\Codex 改名为 Codex.backup，这是另一个文件夹。
• Windows 设置里的"重置"。 有用户重置后本地任务被删掉了，还要重新登录；"修复"相对安全一些。日志和崩溃转储存在应用包的 LocalCache 里，卸载时很可能一起被删，要卸载的话先把下文提到的日志复制出来。
• 以管理员身份运行。 它解决不了 os error 3，而且按官方文档，这样启动后 Codex 执行的每条命令都会带着管理员权限。最多临时用来排查一次。
• 关闭 Windows 安全防护。 OpenAI 支持人员明确不建议把它当成变通办法。
• 来路不明的补丁和"修复工具"。 相关 issue 里有新注册账号贴出的补丁压缩包，被其他用户指认为勒索病毒；有一段修改 browser-client.mjs 的补丁，会绕过网站许可检查；还有一款在多个帖子里推广的修复工具，同样不是 OpenAI 的。都不要下载运行。

本地修不好时：在 /feedback 或 GitHub issue 里附上这些

整理好以下信息再报告，对方才能判断是哪条分支：

• 应用版本（Get-AppxPackage -Name OpenAI.Codex 输出里的 Version）和 Windows 版本号（运行 winver 查看）
• 完整的报错原文和退出代码，比如 code=3221225501
• 事件查看器里 Application Error 的错误模块名称
• 桌面端日志：%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\<年>\<月>\<日>\codex-desktop-*.log，崩溃转储在同一 LocalCache 下的 Roaming\Codex\web\Codex\Crashpad\reports（较早版本的日志在 %LOCALAPPDATA%\Codex\Logs）
• 你已经试过的步骤和各自的结果

在应用里可以运行 /feedback，联系支持时附上对话 ID，这是浏览器扩展文档给出的最后一步。也可以把信息补充到已有的 issue 里，而不是另开新帖：os error 3 对应 #19187，nodePath 对应 #35705，握手超时对应 #39015，0xC000001D 对应 #24408。贴日志之前，把里面的用户名和项目路径换掉。

Codex 打不开的几个相关问题

Codex 更新后打不开，是上面这几条报错吗？

有弹窗、有原文的，按开头的表对照即可。nodePath 这条在 2026 年 10 月 3 日和 8 日的更新后都有人复发，os error 3 也多发生在自动更新之后。没有任何报错、一直卡在 logo 的，多数是 26.924–26.928 那一批版本，见对照表里的"卡在 logo"一行；10 月 7 日以后在 26.1002.7124.0 上登录完自动关闭的，是运行时包安装崩溃那一行。

重装 Codex 能修好 app-server 启动失败吗？

多数情况不能。.codex 在应用包之外，重装不会动它，所以凡是由 config.toml、日志库、对话记录引起的问题，重装后还在；os error 3、握手超时和 0xC000001D 都有用户报告重装无效。例外是 Unable to locate the Codex CLI binary：有用户换到更新的版本后恢复了，但不是每个人都有效。要重装的话，用商店 ID 9PLM9XGG6VKS 安装（winget install --id 9PLM9XGG6VKS -s msstore），不要装成 ChatGPT Classic。

Codex CLI 能用、桌面应用打不开，说明什么？

说明账号和网络大概率没问题，坏的是桌面应用自己复制出来的那套程序、它记录的路径，或者注入进它进程的 DLL。#20048 和 #30884 都是 CLI 正常、桌面端报错。另装一份 npm 版 CLI 修不好 os error 3，但等官方修复期间，可以先用 CLI 继续工作。

ChatGPT 桌面应用和 Codex App 是同一个应用吗？

是同一个。更新日志写明，2026 年 7 月 9 日起 Codex 成为 ChatGPT 桌面应用的一部分，原有项目和设置会保留。Windows 里的包名仍是 OpenAI.Codex，所以弹窗写的是 ChatGPT，报错里写的是 Codex app-server。ChatGPT Classic 是另一个应用，里面没有 Codex。有的电脑上还同时装着 ChatGPT (Beta)，包名是 OpenAI.CodexBeta；浏览器扩展连不上时，官方建议每个都更新，或者删掉不用的那个。