Codex 命令卡住或超时：日志、进程与网络排查

Codex 执行命令长时间没有结束，不一定是程序卡死。命令可能在等待密码或交互输入，也可能正在下载依赖、编译大型项目、等待网络响应，或者启动了本来就不会自动退出的开发服务器。先识别状态，再决定等待、输入还是终止。

## 先看最后一段输出

记录命令、开始时间和最后出现的日志。若提示 password、confirm、press enter 或选择菜单，说明它在等待输入；若持续有编译进度或下载数据，说明仍在工作；若输出停止但 CPU、网络或子进程仍活跃，可能只是暂时没有新日志。

不要因为页面没有变化就立即重复提交相同命令。重复的构建、迁移或启动命令可能争抢端口和文件锁，让问题更复杂。

## 区分常见类型

- 开发服务器：设计上会持续运行，需要单独会话或明确的停止方式。 - 测试挂起：可能有未关闭线程、数据库连接或浏览器进程。 - 网络超时：依赖源、代理、DNS 或外部 API 无响应。 - 权限等待：命令请求系统认证，但代理无法代替用户输入。 - 文件锁：另一个构建或包管理进程占用了缓存。

## 安全终止流程

1. 先确认命令是否允许正常中断。 2. 记录当前日志和进程标识。 3. 优先发送温和的终止信号，让程序释放资源。 4. 再检查端口、子进程和临时锁是否残留。 5. 只有确认普通终止无效时，才考虑强制结束。

不要使用模糊的批量 kill 命令，以免终止数据库、编辑器或其他用户任务。目标必须是已确认属于本次执行的进程。

## 用最小命令复现

把完整流水线拆开：先检查环境，再单独下载依赖，再编译目标模块，最后运行测试。网络相关命令设置合理超时并保存错误响应。若最小步骤可以完成，逐步恢复参数，直到找到造成等待的环节。

## 什么时候应该继续等待

命令仍有进度、资源使用合理、预计耗时有依据且未超过项目基线时，可以等待。大型首次构建往往比增量构建慢。相反，若完全无输出、无资源活动、超过正常时间并且无法解释，应停止并调查。

## 留给后续排查的信息

保留客户端版本、操作系统、工作目录、完整命令、开始与结束时间、退出码、最后日志和网络环境。若问题只在 Codex 中出现，还要用同一用户在普通终端执行最小命令作对比。这样可以区分工具执行层与项目本身的问题。