Windows 版 Codex 使用 WSL："Failed to create unified exec process: No such file or directory" 怎么解决

在 Windows 版 Codex 应用里打开"WSL 代理"之后，任何命令都跑不起来。pwd 不行，git status 也不行。所有命令都在 shell 启动之前就失败，报错如下：

exec_command failed: CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

问题不在你的 Bash、项目或 WSL，而是 Codex 自己的两个进程在 Windows 磁盘上共用同一个临时目录而产生的冲突。截至 2026年10月7日，issue #49731 仍未关闭，也没有官方修复。不过有一个已被多位用户验证的办法：用 mount --bind 把这个目录挪出 Windows 磁盘。

"Failed to create unified exec process: No such file or directory" 是什么原因？

缺失的文件是 codex-linux-sandbox，Codex 在 Linux 沙箱里执行每条命令都要用到它。它之所以消失，是因为 Windows 侧的 Codex 进程删掉了 Linux 侧进程存放这个可执行文件的目录。

这个机制写在 Codex 源码 codex-rs/arg0/src/lib.rs 里，issue 中有人在不启动应用的情况下复现了它：

• 每个 Codex 进程都会在 $CODEX_HOME/tmp/arg0/codex-arg0XXXXXX 下创建自己的目录，并在运行期间锁住其中的 .lock 文件。
• 每个进程启动时都会对这个目录做一次清理（janitor_cleanup）：尝试锁住每个子目录的 .lock，一旦成功，就认为该目录已被废弃并整个删除。
• 在 WSL 模式下，Linux 代理和 Windows 的 codex.exe 共用同一个 CODEX_HOME，即 C:\Users\<你>\.codex，Linux 侧看到的是 /mnt/c/Users/<你>/.codex。
• 在 WSL 里对 /mnt/c 下文件加的锁，Windows 看不到。于是 codex.exe 拿到了锁，误以为 Linux 代理的目录已废弃，连同 codex-linux-sandbox 一起删掉。

应用启动几秒后就会拉起这个 codex.exe。所以重启没用：代理新建的目录很快又会被删掉。

怎么确认是这个问题？

在 Windows 命令提示符里查看 arg0 目录的内容：

dir /s %USERPROFILE%\.codex\tmp\arg0

如果只看到 .lock、apply_patch.bat 和 applypatch.bat，找不到任何 codex-linux-sandbox，就是这个问题。这些 .bat 文件属于 Windows 进程的目录，Linux 代理的目录已经被删了。

另一个迹象：打开 tty 后，同一条命令会给出更具体的错误，直接显示丢失的路径：

Unable to spawn /mnt/c/Users/<你>/.codex/tmp/arg0/codex-arg0<id>/codex-linux-sandbox because it doesn't exist on the filesystem (ENOENT: No such file or directory)

哪些 Codex 版本有这个问题？

issue #49731 中的报告覆盖了从 26.928.2636.0 到 2026年10月6日发布的 26.1002.6548.0，有用户在10月7日确认后者依然有问题。这些版本内置的 Linux 代理从 codex-cli 0.159 到 0.160.1。

应用版本（Windows）	#49731 中报告的状态
26.917.9434.0	正常（一位用户的报告，Windows 10 + Debian）
26.928.2636.0 到 26.928.3736.0	受影响
26.930.x（包括 26.930.41038）	受影响
26.1002.6548.0	2026年10月7日仍受影响

怎么用 mount --bind 解决？

思路是让 tmp/arg0 这个路径指向 Linux 磁盘上的目录。在那里，文件锁在 Linux 进程之间是有效的，Windows 的 codex.exe 也不会再删掉代理的 helper。CODEX_HOME 的其他内容（配置、会话、规则）保持原位。

1. 在 Linux 上创建目录，在 WSL 里用你自己的用户执行：

mkdir -p /home/<linux-user>/codex-arg0-local

2. 让挂载在重启后依然生效。编辑 /etc/wsl.conf（sudo nano /etc/wsl.conf），加入：

[boot]
command = mount --bind /home/<linux-user>/codex-arg0-local /mnt/c/Users/<windows-user>/.codex/tmp/arg0

请使用绝对路径，不要用 ~，因为启动命令以 root 身份运行。如果你的 wsl.conf 已经有带 systemd=true 的 [boot] 段，只需在其中加上 command 这一行。

3. 关闭 Codex 应用并重启 WSL，在 PowerShell 中执行：

wsl --shutdown

重新打开 Codex。在 WSL 中运行下面的命令，确认挂载已生效：

findmnt /mnt/c/Users/<windows-user>/.codex/tmp/arg0

用过这个办法的用户表示，命令恢复正常，沙箱也依旧生效（项目之外的写入仍被拦截）。要撤销的话，删掉 wsl.conf 里那一行，再执行 sudo umount /mnt/c/Users/<windows-user>/.codex/tmp/arg0。

挂载了还是失败，怎么办？

很可能你挂载时代理已经在运行，它还在找旧目录。有用户在应用开着的情况下挂载，遇到的正是这种情况。这就是第3步的意义：挂载写进启动配置并执行 wsl --shutdown 之后，挂载会在 Codex 拉起代理之前就存在，新目录直接建在 Linux 侧。

哪些做法没用？

以下做法都有报告者在 issue 中试过，均无效：

• 重启 Windows 或应用，或者新开一个对话。
• 重装 Codex，或者删除并重装 Ubuntu。
• 安装 bubblewrap，并在 config.toml 的 [features] 中关闭 unified_exec。
• 在 WSL 里重建被删的目录：只要 .lock 仍处于打开状态，Windows 就会让该目录处于"待删除"状态，Linux 上的 mkdir 会返回 File exists。

逐条批准命令在沙箱外运行确实可行，但这是错误的出路：你失去的正是沙箱本该提供的保护。

WSL 里没有 sudo，还有别的办法吗？

有：把代理切换到原生模式。在 Settings 的代理选择器中，从 WSL 改为 Windows native，然后重启应用。根据 Windows 应用的官方文档，这项更改要重启后才会生效。

在原生模式下，同一份文档建议把项目放在 Windows 磁盘上，再从 WSL 通过 /mnt/<drive>/ 访问。有用户报告，用原生代理打开 \\wsl.localhost 下的项目会报 helper_unknown_error，所以迁移项目也是切换的一部分。等 OpenAI 修复 #49731 之后，再切回 WSL 代理即可。

WSL 里的 Codex CLI 也会受影响吗？

有可能。官方文档建议在 WSL 中设置 export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex，让 CLI 和应用共享配置。这正是触发问题的条件：issue 里不依赖应用的复现，用的就是设置了这个 CODEX_HOME 的 Linux CLI，并且显示 Windows 上一条简单的 codex.exe --version 就会删掉正在运行的 Linux 进程的目录。如果你在 WSL 里的 CLI 也开始报同样的错，同样的 mount --bind 就能解决。