Codex Remote SSH / Dev Container 无限转圈与 GPT-6 可用问题排查总结

1. 问题背景

环境大致为：

• Windows 本地运行 VS Code
• 通过 Remote SSH 连接远程 Linux 服务器
• 再通过 Dev Containers / Attach to Running Container 进入容器
• 容器内使用 OpenAI Codex VS Code 扩展
• 目标：使用较新的 Codex 扩展，并能够使用 GPT-6

最开始的问题表现为：

1. Codex 扩展安装后右侧面板一直显示加载圆圈；
2. 降级到旧版本虽然可能能启动，但担心无法使用 GPT-6；
3. 升级 VS Code 后，Remote SSH / Attach to Container 又出现连接失败；
4. 最终解决后，新版 Codex 可以正常启动，并能够使用 GPT-6。

---

2. 第一阶段：Codex 扩展一直转圈

2.1 最开始怀疑网络和 Marketplace

一开始 VS Code 扩展页出现过：

• Failed to fetch
• 扩展安装或更新异常
• Marketplace / CDN 请求失败

检查过代理环境，例如：

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

也测试过：

curl -I https://marketplace.visualstudio.com

以及 VS Code Marketplace 的 publisher CDN。

后来确认：

• Marketplace 本身基本可以访问；
• 404 出现在 CDN 根路径时并不代表网络失败；
• 扩展其实已经安装完成；
• 右侧一直转圈不是"安装进度"，而是 Codex 扩展初始化失败。

---

3. Codex 版本回归问题

当时使用的 Codex 版本为：

26.901.22334

社区已有与该现象非常接近的 Remote SSH 报告：

• 新版 Codex 在 Remote SSH 环境下侧边栏无限加载；
• 回退到：

26.825.51511

后可以恢复正常。

因此一度考虑过：

26.901.22334  -> 新版，GPT-6 支持更有希望，但 Remote SSH 会卡
26.825.51511  -> Remote SSH 更稳定，但版本较旧

不过由于目标是继续使用 GPT-6，因此没有把"长期降级"作为最终方案。

---

4. 尝试过的一个无效方向：supportNodeGlobalNavigator

曾经尝试在远程 VS Code Server 设置中加入：

{
  "extensions.supportNodeGlobalNavigator": true
}

对应文件：

~/.vscode-server/data/Machine/settings.json

完整结构例如：

{
  "http.proxyStrictSSL": false,
  "files.participants.timeout": 0,
  "chat.mcp.discovery.enabled": {
    "claude-desktop": true,
    "windsurf": true,
    "cursor-global": true,
    "cursor-workspace": true
  },
  "http.proxy": "http://127.0.0.1:10240",
  "extensions.supportNodeGlobalNavigator": true
}

这个选项主要用于解决另一类：

PendingMigrationError
navigator is now a global in nodejs

但本次问题配置后仍然无效。

因此继续查看 Remote Extension Host 日志。

---

5. 真正的关键错误：Node 22 无法解析新版 Codex 的 JS

日志中最终发现：

SyntaxError: Unexpected identifier 'p'

同时错误指向：

~/.vscode-server/extensions/openai.chatgpt-26.901.22334/out/extension.js

这说明：

• Codex 不是"启动后卡住"；
• 而是在 Extension Host 加载 extension.js 的解析阶段就失败了；
• 所以甚至无法正常完成 extension activation。

进一步检查 Remote Extension Host 使用的 Node：

pid=$(pgrep -n -f 'extensionHost')
echo "PID=$pid"
readlink -f /proc/$pid/exe
/proc/$pid/exe --version

输出为：

/root/.vscode-server/bin/994fd12f8d3a5aa16f17d42c041e5809167e845a/node
v22.21.1

这一步非常关键。

说明当时远程 VS Code Server 使用的是：

Node.js 22.21.1

而新版 Codex bundle 中使用了较新的 JavaScript 语法，例如 Explicit Resource Management：

using x = ...

Node 22 无法正确解析，因此报：

SyntaxError: Unexpected identifier

最终表现到 UI 上就是：

Codex 一直打圈

---

6. 正确解决思路：升级 VS Code，而不是修改系统 Node

这里需要特别注意：

即使执行：

node --version

看到系统 Node 是 18、20、24，都不重要。

Codex 扩展运行的 Node 是：

VS Code Remote Extension Host 自带的 Node

路径类似：

~/.vscode-server/bin/<commit>/node

因此以下方法都不是正确解法：

nvm use 24

或者手工替换：

~/.vscode-server/bin/.../node

真正正确的方法是：

升级本地 VS Code，使对应的新版本 VS Code Server 也升级，从而让 Remote Extension Host 使用较新的 Node。

---

7. 升级 VS Code 后出现第二个问题：Remote SSH / Attach to Container 失败

升级 VS Code 后，Codex 的 Node 22 问题有望解决，但又出现：

附加到容器出错

日志中的关键内容为：

https://update.code.visualstudio.com/commit:a44adf7f53e00964ab890f9f8758a334f1fc15bc/server-linux-x64/stable

请求失败：

GET Failed to fetch

同时还有：

https://main.vscode-cdn.net/core/stable.json
GET Failed to fetch

随后：

resolveAuthority(attached-container)
returned an error {"code":"NotAvailable"}

这说明：

升级后的本地 VS Code 需要下载与新 commit 对应的 VS Code Server，但是 VS Code 自己的网络请求失败。

于是链路变成：

Windows VS Code 升级
        ↓
需要新的 VS Code Server
        ↓
尝试下载 server-linux-x64
        ↓
VS Code 内部网络请求失败
        ↓
Remote Extension Host 起不来
        ↓
Attach to Container 失败

---

8. 为什么 PowerShell 能 curl，但 VS Code 仍然 Failed to fetch

在 Windows PowerShell 中测试：

curl.exe -I "https://update.code.visualstudio.com/commit:a44adf7f53e00964ab890f9f8758a334f1fc15bc/server-linux-x64/stable"

能够得到：

HTTP/1.1 302 Found

并跳转到：

https://vscode.download.prss.microsoft.com/...

同时：

curl.exe -I "https://main.vscode-cdn.net/core/stable.json"

也返回：

HTTP/1.1 200 OK

说明：

Windows 网络本身      正常
curl                  正常
VS Code / Electron    请求失败

因此问题进一步缩小到：

• VS Code 本地代理配置；
• VS Code 继承的环境变量；
• Electron / Chromium 网络状态；
• VS Code 本地缓存；
• 本地 VS Code 与远端代理配置混用。

---

9. 远端 127.0.0.1:10240 与 Windows 本地 10240 的区别

这一点很重要。

远端曾设置：

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

但这里的：

127.0.0.1:10240

是 远程服务器 / 容器侧的 loopback 地址。

如果 SSH 使用的是 RemoteForward，例如：

RemoteForward 10240 127.0.0.1:<Windows真实代理端口>

那么逻辑是：

远端 127.0.0.1:10240
        ↓
SSH 反向隧道
        ↓
Windows 本机真实代理

因此 Windows 本机执行：

Test-NetConnection 127.0.0.1 -Port 10240

得到：

TcpTestSucceeded : False

不一定有问题。

因为 Windows 本机本来就未必监听 10240。

需要避免的情况是：

把只适用于远端的 http://127.0.0.1:10240 错误写进 Windows 本地 VS Code 的 User Settings。

---

10. 本地与远端代理配置必须分开

Windows 本地 VS Code

检查：

Get-Content "$env:APPDATA\Code\User\settings.json" |
  Select-String -Pattern 'proxy'

以及：

Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

本地 VS Code 不应该错误地使用：

"http.proxy": "http://127.0.0.1:10240"

除非 Windows 本机真的有代理监听 10240。

Remote VS Code Server / 容器

远端如果依赖 SSH 反向隧道，则可以保留：

"http.proxy": "http://127.0.0.1:10240"

因为对于远端来说，10240 就是 SSH 映射后的代理入口。

---

11. 升级后可用的完整逻辑

最终正确的技术链路应当是：

Windows 新版 VS Code
        ↓
连接 Remote SSH
        ↓
部署新版 VS Code Server
        ↓
Remote Extension Host 使用新版 Node
        ↓
Node 可以解析 Codex 26.901 的新 JS 语法
        ↓
Codex extension activation 成功
        ↓
Codex app-server 正常启动
        ↓
WebView 正常加载
        ↓
GPT-6 可用

而最初失败时的链路是：

旧 VS Code Server
        ↓
Node 22.21.1
        ↓
加载 Codex 26.901
        ↓
extension.js 新语法无法解析
        ↓
SyntaxError: Unexpected identifier
        ↓
Codex activation 失败
        ↓
UI 一直打圈

---

12. 本次排障中最有价值的命令

查看 Remote Extension Host 使用的 Node

pid=$(pgrep -n -f 'extensionHost')
echo "PID=$pid"
readlink -f /proc/$pid/exe
/proc/$pid/exe --version

不要只运行：

node --version

因为那只是 shell 的 Node。

查看 Codex 扩展版本

ls -d ~/.vscode-server/extensions/openai.chatgpt-* 2>/dev/null

查看 Codex / Remote Extension Host 进程

pgrep -af 'codex|extensionHost'

查看最新 Remote Extension Host 日志

rlog=$(
  find ~/.vscode-server/data/logs \
    -type f \
    -name remoteexthost.log \
    -printf '%T@ %p\n' |
  sort -nr |
  head -1 |
  cut -d' ' -f2-
)

grep -nEi \
'openai\.chatgpt|activation|activate|SyntaxError|Unexpected|PendingMigration|navigator|chatgpt\.openSidebar|error' \
"$rlog" |
tail -150

Windows 测试 VS Code Server 下载

curl.exe -L -I "https://update.code.visualstudio.com/commit:a44adf7f53e00964ab890f9f8758a334f1fc15bc/server-linux-x64/stable"

Windows 检查本地代理

Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

netsh winhttp show proxy

Get-Content "$env:APPDATA\Code\User\settings.json" |
  Select-String -Pattern 'proxy'

---

13. 排障经验总结

这次问题实际上是 两个连续的问题叠加。

问题一：Codex 无限转圈

根因：

Codex 新版 JS 语法
+
Remote VS Code Server 的 Node 22
=
extension activation 语法解析失败

解决方向：

升级 VS Code / VS Code Server

而不是：

修改系统 Node
修改 nvm
反复重装 Codex
只调代理

问题二：升级后无法 Attach to Container

根因表现为：

VS Code 本身无法 fetch 新版 VS Code Server

即：

update.code.visualstudio.com
main.vscode-cdn.net

在 PowerShell 中可访问，但 VS Code 内部 fetch 失败。

因此需要检查：

Windows 本地 VS Code 代理
环境变量
Electron 网络状态
本地/远端代理是否混用

而不是继续怀疑：

Docker 容器损坏
/root/workspace 消失
SSH 本身坏了

---

14. 最终结论

这次最核心的认识是：

Codex 在 Remote SSH / Dev Container 中运行时，真正决定扩展 JavaScript 兼容性的不是系统 Node，而是 VS Code Remote Extension Host 自带的 Node。

因此以后如果出现：

Codex 安装成功
但一直转圈

应优先检查：

Remote Extension Host 日志
+
VS Code Server 自带 Node 版本

尤其遇到：

SyntaxError: Unexpected identifier

时，应优先考虑：

VS Code / VS Code Server 版本过旧

而不是把问题归结为 Codex 登录、模型权限或代理。

最终结果：

新版 VS Code / VS Code Server
+
新版 Codex
+
Remote SSH / Container 正常
+
GPT-6 可用

注：本总结记录的是本次排查中已经确认的故障链路与关键修复方向。最后一步本地网络/代理恢复的具体操作在对话中没有单独记录，因此没有臆测写成某一个确定动作。