按完整后缀与首条致命错误定位分支
弹窗通常只显示一行前缀，真正的判断依据藏在完整后缀中：退出码、signal以及退出前的第一条fatal记录共同决定处理方向。常见的报错形态有三种，主体均为Codex app-server进程：
- Codex process errored: Codex process is not available
- Codex process errored: Codex app-server process exited unexpectedly (code=3221225781, signal=null)
- Codex process errored: Codex app-server process exited unexpectedly (code=unknown, signal=SIGKILL)
排查时在VS Code「查看→输出」面板选择Codex，向前翻到第一条fatal，逐项记录以下信息：第一条fatal或初始化失败的完整内容、退出码与signal的组合、完整的Last CLI error、系统环境及是否运行在WSL、本次崩溃所在窗口与扩展版本。需要留意的是，process is not available与stdin is destroyed多属进程退出后的连带报错，不能只处理这两行。可再用单窗口新会话与受影响旧会话对照，原会话保持不动，这属于诊断手段而非修复完成。分流前不要急于改配置或重装。
分支对应关系如下：
- 退出码3221225781，或启动提示缺少VCRUNTIME140.dll / MSVCP140.dll——指向DLL依赖与运行库分支；
- 开启Run in WSL或从Chat切Agent后立即报错，且版本与日志匹配历史记录——指向WSL历史缺陷分支；
- 多窗口、多客户端同时运行，报failed to initialize SQLite state runtime——指向SQLite争用分支；
- 仅打开某个旧会话崩溃、新会话正常——指向单会话绕行分支；
- signal=SIGKILL且系统内核有OOM记录——指向内存分支。
退出码3221225781：Windows运行库修复
退出码3221225781（0xC0000135）指向DLL加载失败，但单凭退出码无法确定具体缺失哪个DLL。只有当Codex在Windows本机运行，且明确提示缺少VCRUNTIME140.dll、MSVCP140.dll，或与已验证案例一致时，才应安装或修复微软Visual C++ Redistributable；并非所有同前缀报错都适用此方案。
- 保留日志与报错原文，不要急于清空面板；
- 前往微软官方Visual C++ Redistributable页面，选择与应用架构匹配的受支持包，架构以应用二进制为准；
- 安装或修复运行库，按安装器要求完成重启；
- 重开IDE，发送实际请求验证。
不要下载第三方单独DLL文件。微软官方运行库页面为Latest Supported Visual C++ Redistributable Downloads。多位用户确认安装运行库后恢复，但身份独立性待核；微软官方仅确认运行库作用与架构要求，未对全部同词报错定性。装完重启IDE后能发送请求、同版本不再以相同缺DLL错误退出，即算该分支走通。若无效，应检查实际缺失依赖，避免让用户反复安装运行库；此时重读第一条fatal，若指向SQLite初始化则转入SQLite分支，若指向SIGKILL则转入内存分支。
开启WSL后报错：历史缺陷与版本核对
仅当开启Run in WSL、或从Chat切Agent后立即报错，且版本与日志能对上2025年11月的历史记录时，才进入这条分支。维护者当时确认修复了数个WSL设置问题，预发布版0.5.39曾是修复候选；多人报告关闭WSL选项后恢复，但也存在预发布后复发的反例。
当前核对步骤：
- 记录扩展版本与运行环境；
- 核对当前支持版本与更新说明；
- 环境允许时切Windows本机运行，重载扩展做对照；
- 确认原触发场景可用且模式能力满足需求。
历史旧版本号不应视为当前推荐，也不要一刀切要求WSL使用者改配置。单人回退旧版恢复的案例不建议照搬，更不要为绕开报错去开启更高的模式权限，旧版本号也不能当作长期方案。IDE扩展与独立CLI是不同安装，更新CLI不代表扩展内置二进制已更新，两端版本需分开核对。核对后仍失败，应回到原环境保留日志，按新版本问题提交反馈，不把绕行当作永久修复。
SQLite初始化失败：先排查多客户端同时启动
failed to initialize SQLite state runtime只说明本地状态初始化失败，不能单凭这一行断定数据库损坏或锁争用。若该报错恰好发生在多个VS Code窗口或桌面端、IDE同时启动时，应先按多客户端争用排查。完整性检查正常的数据库也可能初始化失败——争用判断来自报告者的时序与持有者比对，官方尚未定性。
- 保存工作，正常退出其他客户端与多余窗口；
- 单窗口重载扩展，发送请求验证；
- 必要时重开第二个窗口，观察是否复发。
不建议删除数据库文件，更不能因状态库报错清空所有SQLite与WAL文件。重置本地状态会同时改动认证、配置、历史与数据库多个变量，只在完整备份且理解影响时考虑，不作为首选。单窗口下同一配置与任务稳定运行只说明当前恢复，多窗口恢复时是否复发仍需观察；若复发，应收集完整的数据库错误、版本与多客户端时序记录，再提交反馈。
单会话崩溃与SIGKILL：绕行与内存分支
仅打开某个特定旧会话即崩溃、新会话与其他旧会话正常时，新会话可用只能帮助定位范围，不能证明旧文件已损坏，也可能涉及会话体积、图片或恢复逻辑。绕行步骤为：保留旧记录、不改动会话文件；在新会话补充目标、文件位置与简短上下文；发送实际请求完成任务验证。这属于临时绕行，原会话并未修复，上下文也不会自动迁移；改动会话文件有丢失上下文的风险，不作为常规步骤。
关于SIGKILL与内存：必须同时存在内核OOM记录才进入内存分支，不能仅凭SIGKILL断定内存不足。已有含图长会话恢复时内存飙升、被OOM killer终止的本机记录案例。排查时对照新会话与内存占用变化；保留原会话、用小会话继续工作，减少无关大图只能降低负担，并不等于修复缺陷。
恢复验收以实际请求和任务完成为准，面板重现、登录正常都不算；完整重启IDE后仍能发送请求并完成任务，才算恢复。若只剩网络侧证据（超时、连接重置），再单独评估网络环境，可参考站内AI API调用错误与网络稳定性指南。
常见问题解答
- 这个报错是网络不稳定造成的吗？不能一概归因网络。后缀与第一条fatal决定分支，仅有证据的网络错误才进网络分支。
- process is not available是什么意思？多为进程退出后的连带报错，应处理的是第一条fatal。
- 需要删除本地数据库吗？不建议删除。检查正常也可能初始化失败，优先退出多余客户端并单窗口重载。
- 只有一个旧会话打不开怎么办？在新会话补充目标与上下文继续任务，属临时绕行，未修复原会话。
- 怎么判断Codex真正恢复了？以实际请求和任务完成为准；面板重现或登录正常都不算依据。
总结
Codex process errored没有单一根因：应读完整后缀与第一条fatal，按分支处理，完整重启后实测验收。运行库、WSL、SQLite、单会话与OOM各自独立，不要跨分支套用方案，目前也未查到可靠的代理修复案例；验收只认实际请求与任务完成。若日志另外出现连接超时、代理连接失败或TLS错误，再单独排查网络路径，调整网络替代不了本地故障处理。网络侧证据成立时，IPxSS海外AI网络提供按设备固定出口与Socks5等多种接入；需要长期固定出口的团队可前往 https://www.ipxss.com/ 考察。