最近在使用 Codex 的时候又遇到了一个问题想着干脆专门记录下来也方便遇到相同情况的朋友通过这篇文章快速解决。问题现象众所周知在同一个会话里频繁进行多轮对话容易导致 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 之间的连接和初始化过程。这个问题暂时只能等待后续版本修复。