Codex app-server 是什么，报错说明什么
App-server 指的是 codex.exe 以 app-server 模式运行的后台进程。按照 OpenAI 官方文档的说法，它是 “the interface Codex uses to power rich clients”，也就是桌面端、VS Code 插件等富客户端所依赖的服务端。它通过 JSON-RPC 通信，默认使用 stdio，远程功能则走 WebSocket。在 Windows 上，ChatGPT 或 Codex 桌面应用负责把它拉起，Browser Use 与浏览器插件同样依赖它。
当窗口弹出「Codex app-server is not available」，说明客户端尝试通信时找不到仍然存活的 app-server：进程已经崩溃、没有被拉起，或者网络链路不可达。有用户在云环境场景中遇到：配置好云端环境后新建会话，提交首条消息就弹出 “Error submitting message / Codex app-server is not available”，会话无法启动。另一种常见情形是：dot 电脑列表里本机持续显示 Offline，恢复聊天时报 “Failed to resume chat: Codex app-server is not available”，桌面日志给出 failureReason=remote_unavailable。
五类典型成因与识别信号
根据公开讨论与用户反馈，该报错主要集中在以下五类成因：
- 二进制路径失效或缺失：识别信号为 os error 3、Unable to locate the Codex CLI binary，多条用户反馈。
- Microsoft Store 沙箱拦截：识别信号为 Access is denied，商店版重装无效，多条用户反馈。
- 僵尸进程与数据库锁：识别信号为 database locked，重启电脑才好，来自用户实测记录。
- 插件 manifest 缓存崩溃：识别信号为启动数秒后 code=1 退出，defaultPrompt 超 128 字符，来自用户反馈。
- 代理环境下 WebSocket 超时：识别信号为 ETIMEDOUT、握手约 15 秒超时、1006 断开，多条对照记录。
报错时间线也值得注意：有用户反馈 dot 启动的线程无法恢复聊天，也有用户在 Windows 更新后遇到该报错、重启未解决。「更新后出现」的时间关联，和第一类（路径/权限被更新打乱）与第五类（代理链路被更新重置）都能对上，具体归属仍需按日志判断。
验证有效的排查顺序
排障资料中命中率最高的顺序如下，按序推进、每步验证：
- 结束全部残留进程：任务管理器结束所有 codex.exe，或用 tasklist | findstr codex 配 taskkill /PID /F 清理。
- 备份后清理配置目录：整体重命名 ~/.codex（Windows 为 C:\Users\用户名\.codex），让客户端冷启动重建；注意历史会话会清空，操作前务必备份。
- 给安全软件加白名单：把 codex.exe 与 .codex 目录加入杀毒/安全软件白名单。
- 验证 CLI 本身：终端执行 codex --version；终端能起 app-server 而桌面端或插件报错，属于客户端与后端路径不匹配。
- 换安装渠道：卸载 Microsoft Store 版，改用官网独立安装包或 npm CLI（npm i -g @openai/codex），必要时设 CODEX_CLI_PATH 指向新二进制。
- 看日志关键词定位：崩溃前的日志行比弹窗一句话信息量大得多。
日志关键词与处理方向对照：
- unknown feature key：版本兼容问题，降级 CLI 或插件版本。
- database locked：进程没杀干净，结束全部 Codex 进程。
- permission denied：权限或沙箱拦截，换安装渠道、检查目录权限。
- os error 3：路径失效，修复路径或重装 CLI。
三个容易忽略的环境因素：Windows 用户名或路径含非 ASCII 字符、配置目录被 OneDrive 同步重定向、本地 9234 端口被其他程序占用。另外，单纯重装通常无效——配置与历史都在 .codex 目录里，卸载不触碰它。
代理环境为何更易触发该报错
有用户提供了一组可复现的对照数据。同一台 Windows PC：走系统代理时，Responses WebSocket 握手约 15 秒后超时；仅对诊断进程显式设置 HTTP 代理后，握手约 2.84 秒即以 HTTP 101 Switching Protocols 成功，更新检查也随之恢复；改用显式 SOCKS 代理时 WebSocket 成功，但 HTTP provider 检查失败。桌面日志里能看到完整的失败链：connect ETIMEDOUT :443 → code=1006 关闭 → state_changed next=error → 弹窗报错。
机制不复杂：Codex 桌面端的 durable 连接与 local-executor rendezvous 都走 WebSocket，而系统代理对 WebSocket 的支持常不完整——超时阈值偏短、对 Upgrade 头处理不一致，握手被掐断后客户端报 remote_unavailable。另有同类反馈：代理环境下桌面端打不开任务、网页版正常，相关排查记录包含 WebSocket 代理排查与切换路由的对照；更早的反馈也记录了 system proxy 与显式代理的 WebSocket 差异。也就是说，同一条报错，在代理环境下有独立成因，本地排查全做完也可能复现。
2026 年为 Codex 选网络出口的四个标准
- 协议完整度：低质量出口仅支持 HTTP，SOCKS 场景缺位；稳定出口需 HTTP 与 SOCKS5 双协议可用。
- 长连接稳定性：低质量出口高峰频繁断连，WS 握手超时；稳定出口 WebSocket 长连接稳定，超时可控。
- 出口一致性：低质量出口地区跳变，触发反复验证；稳定出口固定归属地，会话连续。
- 并发与带宽：低质量出口晚高峰拥塞，任务中断；稳定出口带宽保障，多人共用不互相拖累。
综合上述对照结果，能被客户端显式指定的代理（进程级 HTTPS_PROXY）优于全局系统代理；而能被桌面端稳定使用的前提是出口本身支持长连接。IPxSS海外AI网络方案提供 HTTP 与 SOCKS5 双协议、固定归属的出口，并配套代理 IP 资源灵活扩展，开发团队可小批量验收后放量，把网络侧变量一次性排掉。更多信息可参考 https://www.ipxss.com/ 。
常见问题 FAQ
Codex app-server is not available 是封号吗？
不是。它表示本地后台的 codex.exe 进程崩溃或无法连接，属于本地环境或网络链路问题，与账号状态无关。同一账号换一台设备登录通常即可验证。
重装 Codex 能解决这个问题吗？
多数情况下无效。配置、缓存与历史会话都存在 .codex 目录，卸载不会清除它们；商店版重装后沙箱权限问题依旧。更有效的是清理 .codex 重建、换非商店安装渠道。
开着系统代理时 Codex 连不上，是什么原因？
典型是 WebSocket 握手被系统代理掐断。有用户的对照实测显示：系统代理下握手约 15 秒超时，显式 HTTP 代理下约 2.84 秒成功。可改用进程级显式代理，或换支持长连接的稳定出口对照验证。
怎么定位具体是哪种成因？
先看弹窗与日志：os error 3 指向路径失效，Access denied 指向商店沙箱，database locked 指向残留进程，code=1 且伴随插件 WARN 指向 manifest 超长；出现 ETIMEDOUT、1006 则优先怀疑代理链路。
dot 里电脑显示 Offline 和这个报错有关吗？
有关联但可能是两条链路。实测记录显示 durable 连接与 local-executor rendezvous 会分别失败：dot 显示 Offline 是远程可达性问题，恢复聊天时报 app-server 错是另一条连接失败，需要分开诊断。
总结
Codex app-server is not available 的意思是后台 codex.exe 进程崩溃或不可达：多数案例来自路径失效、商店沙箱、残留进程、插件缓存四类本地问题，单纯重装通常无效；代理环境下的 WebSocket 握手超时是独立成因，换显式 HTTP 代理或稳定出口即可对照验证。按「杀进程→清缓存→验 CLI→换渠道→看日志」的顺序推进，大多数情况能在不换机的前提下恢复。IPxSS海外AI网络方案提供双协议稳定出口，配套代理 IP 资源，适合长期依赖 Codex 的团队。