VS Code Remote/Container 中 Codex 插件无法启动：排查流程与经验总结

场景：Windows 本地 VS Code + Remote/Dev Container（Linux 容器）+ Codex VS Code 插件。
现象：Windows 本地可以使用，远程容器中的 Codex 面板长期空白、一直转圈，CLI 有时正常，但插件不正常。
最终结论：Codex VS Code 扩展版本回归（regression）是最终根因；回退扩展版本后恢复正常。

1. 问题现象

最初表现为：

  • VS Code 顶部 CODEX 标签一直显示旋转图标；
  • Codex 面板完全空白；
  • 右上角持续显示加载条；
  • Codex CLI 与 VS Code 插件行为不一致；
  • 远程容器中比 Windows 本地更容易出现问题；
  • 日志中出现：
    • Request timed out
    • Reconnecting...
    • failed to refresh available models
    • MCP startup incomplete
    • Webview did not finish starting
    • Connection failed: error sending request

其中最重要的现象是：

Windows 本地 Codex       正常
远程容器 Codex 插件      异常
远程容器 Codex CLI       后来可正常使用

这说明问题不能简单归因于账号、模型或 OpenAI 服务本身。

2. 第一阶段：判断是不是公网网络问题

2.1 检查代理环境变量

env | grep -iE '^(http|https|all|no)_proxy='

当时 shell 中已经存在：

HTTP_PROXY=http://127.0.0.1:10240
HTTPS_PROXY=http://127.0.0.1:10240
http_proxy=http://127.0.0.1:10240
https_proxy=http://127.0.0.1:10240

2.2 测试 Codex/ChatGPT 相关网络

curl -v --http1.1 --connect-timeout 10   https://chatgpt.com/backend-api/codex/responses   -o /dev/null

返回：

HTTP/1.1 405 Method Not Allowed

这实际上是好现象，说明：

  • 网络连接已建立；
  • TLS 正常；
  • 请求已到达 ChatGPT 后端；
  • 只是因为 GET 方法不对。

再测试 WebSocket Upgrade：

curl --http1.1 -i --max-time 15   -H "Connection: Upgrade"   -H "Upgrade: websocket"   -H "Sec-WebSocket-Version: 13"   -H "Sec-WebSocket-Key: SGVsbG9Xb3JsZDEyMzQ1Ng=="   https://chatgpt.com/backend-api/codex/responses

返回：

HTTP/1.1 401 Unauthorized

这也说明基础链路是通的；401 只是因为手工 curl 没有 Codex 登录凭证。

阶段结论

可以排除：

服务器完全无法访问 OpenAI

更准确的判断是：

基础 HTTPS 网络可用
但 VS Code Codex 插件内部的启动/网络/渲染路径仍可能异常

3. 第二阶段：确认 Codex CLI 与插件是否走同一套代理

3.1 检查登录状态

codex login status

结果：

Logged in using ChatGPT

说明认证正常。

3.2 查看 Codex 进程

ps -ef | grep -i codex

可看到：

  • codex
  • codex app-server
  • Node wrapper
  • native Codex binary

3.3 检查真实进程是否继承代理

不能直接写：

tr '\0' '\n' < /proc/<PID>/environ | grep -i proxy

<PID> 只是占位符。

应该替换为真实 PID：

tr '\0' '\n' < /proc/2712097/environ | grep -i proxy

也可以批量：

for pid in 2712073 2712097 3618180 3618192; do
  echo "===== PID $pid ====="
  tr '\0' '\n' < /proc/$pid/environ 2>/dev/null | grep -i proxy
done

当时发现旧 Codex 相关进程没有任何 proxy 环境变量。

这说明：

当前 shell 有代理
≠
VS Code Extension Host 有代理
≠
Codex app-server 有代理

4. 第三阶段：给 VS Code Remote 环境注入代理

4.1 VS Code http.proxy

"http.proxy": "http://127.0.0.1:10240",
"http.proxyStrictSSL": false

这对 VS Code 自己的 HTTP 请求有效，但不能保证 native 子进程继承。

4.2 关键配置：remoteEnv

Attached Container 配置中加入：

{
  "remoteEnv": {
    "HTTP_PROXY": "http://127.0.0.1:10240",
    "HTTPS_PROXY": "http://127.0.0.1:10240",
    "http_proxy": "http://127.0.0.1:10240",
    "https_proxy": "http://127.0.0.1:10240",
    "NO_PROXY": "localhost,127.0.0.1,::1,.local,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16",
    "no_proxy": "localhost,127.0.0.1,::1,.local,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
  }
}

并保留：

"settings": {
  "http.proxy": "http://127.0.0.1:10240",
  "http.proxyStrictSSL": false
}

4.3 必须重新 Attach

仅新开 Terminal 不够。

保存配置
→ 关闭 Remote 窗口
→ 重新 Attach Container
→ 再启动 Codex

因为环境变量只在进程启动时继承。

5. 第四阶段：确认 Remote Extension Host 是否真的拿到代理

ps -ef | grep -E 'extensionHost|extension-host' | grep -v grep

然后：

tr '\0' '\n' < /proc/<真实PID>/environ | grep -i proxy

最终新的 Extension Host 已经获得：

HTTP_PROXY=http://127.0.0.1:10240
HTTPS_PROXY=http://127.0.0.1:10240
http_proxy=http://127.0.0.1:10240
https_proxy=http://127.0.0.1:10240

这说明：

VS Code remoteEnv 配置已经生效

但此时 Codex 插件仍打不开，因此：

代理不是最终根因

6. 第五阶段：确认 Codex app-server 是否正常启动

ps -ef | grep 'codex app-server'

有一段时间结果里只有：

grep --color=auto codex app-server

没有真正的：

codex app-server --listen unix://

说明问题发生在更前面的：

Codex VS Code Extension 激活 / Webview / Extension Host

而不是单纯 app-server 联网失败。

7. 第六阶段：检查 Codex 扩展与日志

7.1 当前扩展版本

code --list-extensions --show-versions | grep openai.chatgpt

当时得到：

openai.chatgpt@26.901.22334

7.2 检查日志

grep -RniE 'openai\.chatgpt|Codex|app-server|renderer_ready|PendingMigration|error' ~/.vscode-server/data/logs 2>/dev/null | tail -100

日志中曾出现：

failed to refresh available models:
Connection failed: error sending request

以及：

TypeError: fetch failed
https://ab.chatgpt.com/v1/initialize

更早还出现过：

Activating Codex extension
Spawning codex app-server
Initialize received id=1

以及：

Webview did not finish starting

这些信息说明，故障已经进入：

Codex VS Code Webview / renderer / app-server initialization

这一层。

8. 干扰项：其他扩展错误

日志中同时出现过：

Error: chatParticipant must be declared in package.json: claude-code

以及：

SyntaxError: Unexpected identifier 'p'

还有 Todo Tree / TabNine 在 Extension Host 退出时的错误。

这些说明 Remote Extension Host 确实存在其他扩展异常，但最终并没有证明它们是 Codex 无法启动的根因。

非常重要的经验：

日志里出现错误
≠
这个错误就是当前问题的根因

需要继续通过时间线、进程状态和 A/B 测试定位。

9. 最终解决方案

最终采用：

回退 Codex VS Code 扩展版本

问题立即恢复正常。

因此最终根因可以定性为：

Codex VS Code 扩展新版本在当前 Remote/Dev Container 环境中出现版本回归（regression）或兼容性问题。

最终状态：

网络       基本正常
账号       正常
Codex CLI  正常
remoteEnv  正常
代理       已进入 Extension Host

但新版 Codex VS Code 扩展异常

回退旧版后：
恢复正常

10. 推荐的标准排查流程

以后 Codex/Claude Code/OpenCode 等 IDE Agent 出现类似问题，建议按下面顺序排查。

Step 1：先区分 CLI 问题还是插件问题

codex

如果 CLI 正常、插件异常：

优先查 VS Code 扩展 / Webview / Extension Host
不要先怀疑模型本身

Step 2：确认认证

codex login status

正常：

Logged in using ChatGPT

Step 3：确认基础网络

curl -I https://chatgpt.com

以及：

curl -v --http1.1 --connect-timeout 10   https://chatgpt.com/backend-api/codex/responses   -o /dev/null

需要重点关注：

timeout
connection reset
TLS error

而不是把 401 / 405 误认为“完全无法联网”。

Step 4：确认 proxy 是否进入真实进程

只看：

env | grep -i proxy

不够。

还要看：

tr '\0' '\n' < /proc/<PID>/environ | grep -i proxy

因为 Terminal、Extension Host、app-server 可能拥有不同环境。

Step 5：确认 app-server 是否启动

ps -ef | grep 'codex app-server'

如果没有：

问题发生在扩展激活阶段

如果有但请求失败：

继续查 app-server 网络 / auth / WebSocket

Step 6：确认 Remote Extension Host

ps -ef | grep -E 'extensionHost|extension-host' | grep -v grep

检查：

  • CPU 是否异常；
  • 是否继承 proxy；
  • 是否存在多个旧 Extension Host；
  • 是否存在明显 extension activation error。

Step 7：只看当前日志，不要混入历史日志

重点目录：

~/.vscode-server/data/logs/

建议找最近的日志：

find ~/.vscode-server/data/logs   -type f   \( -name 'remoteexthost.log' -o -name 'Codex.log' \)   -mmin -30   -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n'   | sort

Step 8：优先做版本 A/B 测试

如果：

以前正常
突然坏掉
CLI 正常
网络正常
配置基本没变化

应优先怀疑：

扩展自动更新导致 regression

此时：

Extensions
→ Codex
→ Install Another Version...

回退旧版。

如果旧版立即恢复，基本可以确认是版本回归。

11. 这次排查中最重要的经验

经验 1：ping 成功不等于 Codex 网络正常

Codex 还涉及：

HTTPS
TLS
WebSocket
ChatGPT backend API
认证
长连接

所以：

ping 成功
≠
Codex 一定正常

经验 2：curl 有响应比 ping 更有诊断价值

例如：

405 Method Not Allowed
401 Unauthorized

虽然不是 200，但往往说明：

DNS ✓
TCP ✓
Proxy ✓
TLS ✓
服务端可达 ✓

经验 3：CLI 正常、插件不正常时，优先查 IDE 集成层

CLI 路径：

Codex CLI
→ binary
→ network

插件路径：

VS Code
→ Remote Extension Host
→ Codex Extension
→ Webview
→ app-server
→ model manager
→ network

因此 CLI 正常不能证明插件正常。

经验 4：检查真实进程环境，而不是只看 shell

非常关键：

shell 有 HTTP_PROXY
不代表 Extension Host 有
也不代表 app-server 有

真正可靠的是：

/proc/<PID>/environ

经验 5：修改 remoteEnv 后必须重新启动 Remote 环境

仅新开 Terminal 不够。

应该：

重新 Attach Container

让新的 Extension Host 从新环境启动。

经验 6：不要看到一条红色日志就立刻锁定根因

这次同时出现过：

  • Claude Code 错误；
  • TabNine 错误；
  • Todo Tree 错误；
  • Codex 网络错误；
  • Webview 错误；
  • SyntaxError。

真正根因需要靠：

时间线
当前会话
进程状态
CLI 对照
A/B 测试
版本回退

判断。

经验 7：以前正常、突然坏掉，要优先怀疑自动更新

尤其是快速迭代的 IDE Agent：

Codex
Claude Code
Copilot

如果昨天正常、今天突然坏，而且系统配置没明显变化，第一反应应该是：

检查扩展版本
检查是否刚自动更新

而不是立即大改服务器网络。

经验 8：版本回退既是修复，也是强力诊断手段

新版异常
↓
旧版恢复
↓
基本确认 regression

这是比继续猜网络、MCP、代理更直接的因果验证。

12. 推荐以后使用的排查顺序

1. CLI 是否正常
2. 登录是否正常
3. curl HTTPS 是否正常
4. 插件版本是否刚更新
5. Extension Host 是否正常
6. app-server 是否启动
7. app-server 是否继承代理
8. 查看最新日志
9. 回退插件版本做 A/B
10. 最后才考虑大规模修改系统配置

13. 本次最终结论

本次问题最终不是：

OpenAI 服务不可达
账号异常
Codex CLI 异常
服务器完全没有网络
代理完全失效

而是：

Codex VS Code 扩展新版本在 Remote/Dev Container 环境下出现兼容性回归。

最终通过：

回退 Codex VS Code 扩展版本

成功恢复。

后续建议：

  • 暂时关闭 Codex 扩展自动更新；
  • 保留当前可工作的版本；
  • 等后续版本明确修复 Remote/Dev Container 兼容问题后再升级；
  • 更新后若再次出现空白/转圈，第一时间做“旧版 A/B”，不要重复整套网络排查。

一句话经验

CLI 正常 + 网络正常 + Remote 环境正常 + 插件突然坏掉时，优先怀疑扩展版本回归；先做版本回退 A/B，再决定是否继续查网络。

# vscode
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

码道 · 寻艺——从零构建“非遗交互式对话平台“的完整实践

avatar AI编程社区

码道：从零构建学生信息管理系统 API：FastAPI 内存版 CRUD 项目全解析

FastAPI 的强大，很大程度上来自 Pydantic 的校验能力。我们写下类型声明，FastAPI 在运行时自动把它变成边界检查器。name：字符串，长度限制 1 到 50；age：整数，限制在 6 到 120 之间（ge大于等于、le小于等于）；gender：字符串，用正则限定只能是"男"“女”“其他”；email：邮箱格式字符串；grade与major：可选字段，代表班级和专业方向。

avatar AI编程社区

码道：用 Python + FastAPI 快速构建一个学生信息管理接口：从零到 Swagger 在线文档

在日常开发和教学中，我们经常需要一套简单、可控、能快速上手的后端接口来演示"前后端分离"、练习 Restful API 设计，或者作为前端联调的 Mock 服务。传统做法往往是搭一套完整的 Web 工程：配置数据库、编写 DAO、引入 ORM、做请求分发……一套流程下来，光环境搭建就要花去不少时间，对于想快速验证想法、或者刚入门 API 开发的同学来说，显得过于沉重。

avatar AI编程社区