最近在使用 Codex 的时候又遇到了一个问题，想着干脆专门记录下来，也方便遇到相同情况的朋友通过这篇文章快速解决。
以下对桌面端的各种吐槽均为windows版。
问题现象
众所周知，在同一个会话里频繁进行多轮对话，容易导致 AI 的注意力逐渐分散。因此，我一般只会让 AI 在一个会话中完成一个任务，等一个功能的最小闭环完成后，再新建会话继续下一个任务。
对于 Codex 来说，新建会话本质上就是新建一个线程。
但这一次，在我完成一个功能的最小闭环后，新建会话时却出现了下面的问题：
新会话无法发送消息，甚至右下角的发送箭头都是灰色的。即使已经输入了内容，也依然无法点击发送。
最开始怀疑是桌面端故障
遇到这种情况，第一反应自然是怀疑 Codex Desktop 本身出了问题。
说实话，Codex 的桌面端目前确实还有不少问题，各种 Bug 层出不穷。单纯从稳定性来看，CLI 往往更加可靠；只不过桌面端操作起来更加直观，所以平时还是会继续使用。
既然怀疑是桌面端的问题，最简单的处理方式当然就是重启。
于是我关闭 Codex，又重新打开了一遍，但问题依旧存在，没有任何变化。
排除项目和 WSL 环境问题
进一步观察后，我发现：
- 旧会话仍然可以继续发送消息；
- 新建会话无法发送；
- 当前项目的终端也无法正常打开。
由于这个项目本身运行在 WSL 环境中，所以我开始怀疑，会不会是 WSL 项目路径或运行环境出了问题。
为了验证这个猜测，我打开了另一个比较老的项目。这个项目完全运行在 Windows 环境中，与 WSL 没有关系。
但在这个 Windows 项目中，新建会话后依然无法发送消息。
随后，我又尝试直接新建一个普通聊天，而不是在某个项目中创建会话，结果同样遇到了这个问题。
到这里基本可以确定：
问题与具体项目无关，也不是由 WSL 环境导致的，而是 Codex 本身出现了故障。
怀疑账号异常，但可能性不大
一开始我甚至怀疑，自己的账号是不是被限制了。
但仔细想想，这种可能性并不高：
- ChatGPT 网页端可以正常使用；
- Plus 订阅状态正常；
- 网络代理来源也比较稳定；
- 旧会话仍然可以继续对话。
于是我去交流群里向几位朋友求助。
有人建议，可以尝试使用 Windows 自带的应用修复功能。
可惜，修复之后问题依然没有解决。
重新登录后，终于出现了明确报错
后来我退出了 Codex 账号，并重新登录。
重新登录以后，右下角原本灰色的发送箭头居然亮了起来。
我本以为问题已经解决，结果真正点击发送时，仍然发送失败。不过这一次，报错信息发生了变化：
虽然本质上仍然是无法创建新会话，但至少现在终于出现了一个更加明确的错误信息。
其中最关键的内容是：
Invalid request: missing field `inputSchema`
看到这里，我开始怀疑这可能是一个已知 Bug，而不是我本地环境中的普通配置问题。
在 GitHub 中找到相同问题
随后，我去翻了 OpenAI 的 Codex GitHub 仓库，发现已经有不少人遇到了类似问题，也有人提交了相关 Issue 和解决方案。
结合这位老哥的反馈，再对比自己的环境后，我打算试一试这个方案：
我清楚地记得，在这次故障发生之前，Codex Desktop 曾提示我进行更新。
当时我点击了更新，但界面并没有给出明显反馈。现在回头看，很可能是更新后，Codex Desktop 仍然指向了旧版本的 CLI。
检查 CODEX_CLI_PATH
于是我在 PowerShell 中执行了下面的命令：
[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")
结果确实输出了一条 CLI 路径。
随后，我继续检查这个路径对应的 Codex CLI 版本：
& ([Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")) --version
输出结果为：
codex-cli 0.130.0-alpha.5
也就是说，Codex Desktop 当前被强制指向了一个旧版 CLI。
桌面端本身已经更新，但它调用的仍然是旧版本 CLI，因此两者之间出现了协议或工具定义不兼容，最终导致新会话创建失败，并出现：
Invalid request: missing field `inputSchema`
说实话，这里真的很想吐槽一下 Codex Desktop。
桌面端更新之后，居然还保留着旧 CLI 的路径，而且没有给出明确提示，最后表现出来的却是新会话无法发送消息，排查起来非常绕。
最终解决方法
按照 GitHub 评论区中其他用户提供的方法，我在 PowerShell 中执行了：
reg delete HKCU\Environment /v CODEX_CLI_PATH /f
这条命令的作用是删除当前用户环境变量中的：
CODEX_CLI_PATH
删除完成后，我重新启动了 Codex Desktop。
再次新建会话后，消息终于可以正常发送，问题彻底解决。
建议先检查再删除
为了避免误操作，也可以先执行下面的命令查看当前配置：
[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")
如果确实输出了某个 codex.exe 路径，再检查版本：
& ([Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")) --version
确认它指向旧版 CLI 后，再执行删除：
reg delete HKCU\Environment /v CODEX_CLI_PATH /f
删除后可以再次检查：
[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")
如果没有任何输出，就说明用户级环境变量已经清除。
最后彻底关闭 Codex Desktop，并重新启动即可。
还要检查 config.toml
环境变量删除后，还可以顺手检查一下 Codex 的配置文件：
notepad "$env:USERPROFILE\.codex\config.toml"
看看里面是否还有类似下面的配置：
CODEX_CLI_PATH = 'C:\Users\lenovo\AppData\Local\OpenAI\Codex\bin\xxx\codex.exe'
如果仍然存在写死的 CLI 路径，也建议先删除或注释掉，让 Codex Desktop 自动选择与当前版本配套的 CLI。
否则以后桌面端再次更新，而配置中的 CLI 路径没有同步变化，仍然可能出现类似的版本不兼容问题。
关于 Codex Desktop 使用 WSL CLI 的问题
最后再补充一个我目前仍然没有解决的问题。
我的项目本身运行在 WSL 中，所以我原本打算让 Codex Desktop 直接使用 WSL 环境中的 CLI。
理论上，这样可以避免 Windows Agent 通过：
PowerShell
→ wsl.exe
→ WSL 项目目录
这种绕路方式操作项目，也能减少 UNC 路径、权限和补丁写入方面的问题。
但实际尝试过程中，我遇到了很多麻烦。
我尝试过：
- 调整 Codex CLI 版本；
- 回退旧版本；
- 更新 WSL2；
- 修改 WSL 网络模式；
- 配置镜像网络；
- 检查代理设置；
- 参考官方文档重新配置。
CLI 本身可以正常运行，但 Codex Desktop 一旦切换到 WSL 环境，就会一直卡在“正在思考”。
尝试了很多次，结果都是一样。
同一台电脑上，Windows 原生模式可以正常对话，但切换到 WSL 后，桌面端始终无法正常工作。
后来我也专门设置过 WSL2 的网络，但依然没有解决。查阅官方文档和网络上的相关讨论后，也发现有其他人遇到了类似问题，不过目前没有找到稳定有效的解决方案。
所以现阶段我的判断是：
Codex CLI 在 WSL 中本身没有问题，真正不稳定的是 Codex Desktop 与 WSL Agent 之间的连接和初始化过程。
这个问题暂时只能等待后续版本修复。
