Codex VS Code 插件为何报错“app-server process exited with code 1”？

Codex VS Code 插件报错“app-server process exited with code 1”，其中 code 1 只表示后台进程启动失败，真正原因要看它前面的最后一段 stderr。公开案例的关键不是 config.toml，而是 WSL 无法完成基础进程启动：Windows PATH 转换失败、Linux 用户查询失败、项目挂载目录无法进入，最后连 /bin/sh 都无法执行。

先读完整错误链

案例中的错误依次包含：

• UtilTranslatePathList 无法转换多条 Windows PATH。
• getpwuid(0) failed 2，WSL 无法解析 root 用户信息。
• chdir(/mnt/e/crypto-qr) failed 2，项目目录不存在或未挂载。
• execvpe /bin/sh failed 2，基础 shell 不存在或系统根文件系统不可用。

最后两条足以让任何需要在 WSL 中启动的 app-server 失败。插件只是把子进程退出结果显示为 code 1。

确认插件是否在使用 WSL

先打开 Codex 的输出日志，查找 Spawning codex process inside WSL、wsl.exe 或 Linux 二进制路径。如果日志显示 WSL 启动命令，就应先验证 WSL，而不是反复修改模型设置。

在 PowerShell 中运行：

wsl --status
wsl --list --verbose

记录默认发行版、运行状态和 WSL 版本。机器上存在 Ubuntu 不代表 Codex 选择了正确发行版，默认项可能已删除、损坏或停止注册。

直接测试发行版能否执行 shell

wsl -d Ubuntu -- /bin/sh -lc 'id; pwd; uname -a'

如果这条最小命令都出现 getpwuid、/bin/sh 或进程创建错误，故障在 Codex 启动之前。应先修复 WSL 发行版，再测试插件。

若发行版名称不是 Ubuntu，使用 wsl --list --verbose 输出中的准确名称。不要凭界面显示猜测。

检查 Linux 用户数据库

getpwuid(0) failed 表示系统无法从用户数据库解析 UID 0。进入发行版后检查：

getent passwd 0
getent passwd "$(id -u)"
ls -l /etc/passwd
head -5 /etc/passwd

正常系统应能返回 root 和当前用户记录。不要直接覆盖 /etc/passwd；它属于系统身份基础数据。若文件缺失或损坏，应先导出重要数据，再使用发行版包管理或备份恢复。

确认 /bin/sh 可用

ls -l /bin/sh
readlink -f /bin/sh
/bin/sh -lc 'echo shell-ok'

Ubuntu 的 /bin/sh 通常是有效 shell 的符号链接。若路径不存在，可能是发行版根文件系统损坏、错误挂载或基础包被删除。此时安装或恢复 shell 比调整 Codex 配置更优先。

验证 Windows 项目盘是否已挂载

原案例的项目位于 Windows E 盘，对应 WSL 路径 /mnt/e/crypto-qr。在 WSL 中检查：

findmnt /mnt/e
ls -ld /mnt/e
ls -ld /mnt/e/crypto-qr
cd /mnt/e/crypto-qr && pwd

若 /mnt/e 不存在，先检查 automount 配置和驱动器可用性；若挂载存在但项目目录不存在，VS Code 保存的工作区路径可能已经移动或拼写变化。

用本地 WSL 项目做对照

在 Linux 主目录创建一个最小仓库：

mkdir -p ~/codex-wsl-check
cd ~/codex-wsl-check
git init
printf '# Testn' > README.md

从 WSL 中打开该目录，并启动 Codex。如果 Linux 主目录项目正常、/mnt/e 项目失败，重点检查驱动器挂载与路径转换；两者都失败时，继续检查发行版 shell、用户和 Codex 二进制。

PATH 转换错误如何理解

WSL 默认会把 Windows PATH 中的目录转换并追加到 Linux PATH。日志里的 Graphviz、Node.js、Anaconda、VS Code 和其他目录转换失败，说明 WSL 的互操作或驱动器映射异常。

单个已删除 Windows 目录通常不一定致命，但同时出现大量转换失败、项目盘无法进入和 /bin/sh 无法执行时，不能把它当作无关警告。

用干净 PATH 隔离启动

可以从 PowerShell 运行最小环境测试：

wsl -d Ubuntu -- /usr/bin/env -i HOME=/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/sh -lc 'id; pwd'

这条命令绕过大部分 Windows PATH 导入。如果仍无法执行 /bin/sh，就不是某个 Graphviz 或 Anaconda PATH 条目导致的。

检查 wsl.conf 的互操作设置

if test -f /etc/wsl.conf; then cat /etc/wsl.conf; fi

appendWindowsPath 控制是否把 Windows PATH 附加到 WSL。临时关闭它可以用于诊断大量路径转换警告，但会改变 WSL 中调用 Windows 程序的行为。

修改系统配置前备份文件，并在 PowerShell 中运行 wsl --shutdown 后重新启动发行版。只有干净 PATH 明确解决问题时，才考虑把设置作为长期方案。

为什么 config.toml 不是首要方向

公开案例的配置只设置模型和推理强度，没有显示解析错误。更重要的是，stderr 已经明确来自 WSL 进程创建阶段。即使 config.toml 完全正确，WSL 无法执行 shell 时 app-server 仍不可能启动。

只有日志明确报告 TOML 语法、未知字段或不支持的值时，才应针对配置修复。不要看到界面上的通用“检查 config.toml”提示就删除整个配置。

尝试关闭 WSL 模式前要理解影响

如果 Codex 设置允许使用 Windows 原生运行时，可以关闭 WSL 模式做对照。关闭后检查新日志是否确实启动了 Windows 二进制，而不是仍调用 wsl.exe。

Windows 原生模式与 WSL 模式的路径、shell 和工具链不同。项目依赖只安装在 WSL 中时，原生模式即使能启动，也可能无法运行构建命令，因此它更适合作为诊断或临时入口。

谨慎处理 WSL 重置

注销发行版会删除其文件系统，是破坏性操作，不能作为第一步。先导出发行版：

wsl --export Ubuntu D:Backupsubuntu-before-repair.tar

确认备份文件存在并记录大小后，才评估修复或重新安装。项目若只保存在发行版内部，还应另外备份仓库和未提交文件。

分层判断表

测试结果	故障范围
wsl --status 失败	WSL 平台或服务
/bin/sh 无法运行	发行版根文件系统
getent passwd 0 无结果	Linux 用户数据库
只有 /mnt/e 项目失败	驱动器挂载或项目路径
干净 PATH 成功	Windows PATH 导入或互操作
所有 WSL 检查成功但 Codex 失败	扩展启动命令、二进制或 Codex 配置

修复后的验收

1. 最小 WSL shell 命令稳定成功。
2. root 与默认用户都能被 getent 解析。
3. 目标 Windows 盘和项目目录可进入。
4. 从相同目录运行基础 Git 命令正常。
5. Codex 日志显示 app-server 已启动且不再退出。
6. 重启 VS Code 与 WSL 后再次验证。

当前结论

在该公开案例中，app-server process exited with code 1 不是足以单独诊断的原因，真正证据是 WSL 无法完成用户解析、目录切换和 shell 执行。排查应从 WSL 发行版健康状态开始，再验证 Windows 驱动器挂载、项目路径和 PATH 转换，最后才回到 Codex 配置。

只删除扩展、重写模型设置或反复登录无法修复缺失的 /bin/sh 与不可用的 /mnt/e。先让相同 WSL 启动命令在终端独立成功，才能证明 Codex app-server 具备运行基础。