一、问题背景我的开发环境是Windows 11VS Code Remote WSLCodex 插件Windows 上的本地 HTTP 转发服务监听在 7890 端口WSL 通过 Windows 主机在 WSL 虚拟网络中的地址访问该本地服务例如172.19.0.1:7890问题现象在 WSL 终端中使用 Codex CLI 可以正常使用 Codex但在 VS Code 中选择“适用于 Linux 环境的 Windows 子系统”运行 Codex 插件时对话会不断重新连接。最终发现WSL 终端和 Codex 插件虽然都运行在 WSL 中但它们使用的网络环境并不一定相同。二、确认 WSL 网络环境变量检查环境变量env | grep -i proxy输出类似https_proxyhttp://172.19.0.1:7890 http_proxyhttp://172.19.0.1:7890说明在 WSL 终端中相关网络转发环境变量已经生效如未生效请提前设置环境变量。三、确认 WSL 终端确实使用了该网络配置使用curl -v检查访问任意网站时的实际连接curl -v https://example.com 21 | head -30关键输出这说明 WSL 终端可以正常完成网络访问Windows 本地转发端口和 WSL 网络本身都是正常的。问题只出现在 VS Code 的 Codex 插件中。四、检查 Codex 进程是否继承了网络变量先找到 Codex 的 PIDpid$(pgrep -n -f codex app-server) echo Codex PID: $pid然后检查该进程的环境变量tr \0 \n /proc/$pid/environ | grep -Ei ^(HTTP_PROXY|HTTPS_PROXY|NO_PROXY|http_proxy|https_proxy|no_proxy)结果为这是整个排查过程中的关键发现。虽然当前 WSL 终端中存在HTTP_PROXYhttp://172.19.0.1:7890 HTTPS_PROXYhttp://172.19.0.1:7890但 Codex 进程内部却是HTTP_PROXY HTTPS_PROXY也就是说Codex 插件没有继承当前 WSL Shell 中的网络配置。因此仅仅在.bashrc中设置相关变量并不能保证 VS Code 扩展启动的 Codex 进程也会使用这些变量。五、通过网络连接确认 Codex 未使用本地转发端口为了进一步确认 Codex 是否使用了本地转发端口可以监控它的实际 TCP 连接。执行watch -n 0.2 ss -tpn | grep -E codex|172\.19\.0\.1:7890然后在 VS Code 的 Codex 面板中发送一条消息。观察到的结果类似SYN-SENT 0 1 172.19.8.77:49988 target.example.com:443 \ users:((codex,pid5743,fd25))这说明 Codex 的连接路径是Codex ↓ target.example.com:443而不是Codex ↓ 172.19.0.1:7890 ↓ local http service因此可以确定Codex 当时没有使用 WSL 中配置的本地转发端口。六、尝试过但没有生效的方法1. 只在.bashrc中添加大写网络变量尝试添加export HTTP_PROXYhttp://172.19.0.1:7890 export HTTPS_PROXYhttp://172.19.0.1:7890重新执行source ~/.bashrc终端中的环境变量正常但 Codex 进程中仍然是HTTP_PROXY HTTPS_PROXY原因是 VS Code 的扩展宿主并不一定通过交互式 Bash 启动因此不一定读取.bashrc。2. 使用~/.vscode-server/server-env-setup尝试创建mkdir -p ~/.vscode-server nano ~/.vscode-server/server-env-setup写入#!/bin/sh WSL_HOST$(ip route show default | awk /default/ {print $3; exit}) export HTTP_PROXYhttp://${WSL_HOST}:7890 export HTTPS_PROXYhttp://${WSL_HOST}:7890 export http_proxy$HTTP_PROXY export https_proxy$HTTPS_PROXY export NO_PROXYlocalhost,127.0.0.1,::1 export no_proxy$NO_PROXY unset ALL_PROXY unset all_proxy然后添加执行权限chmod 700 ~/.vscode-server/server-env-setup关闭 VS Code并在 Windows PowerShell 中执行wsl --shutdown重新进入 WSL 后通过code .启动 VS Code。但是再次检查 Codex 进程pid$(pgrep -n -f codex app-server) tr \0 \n /proc/$pid/environ | grep -Ei ^(HTTP_PROXY|HTTPS_PROXY|NO_PROXY|http_proxy|https_proxy|no_proxy)仍然得到NO_PROXY HTTPS_PROXY HTTP_PROXY说明在我的环境和当前版本中这种方式依然没有让 Codex 使用本地转发配置。七、最终解决方法配置 VS Code 的 HTTP 网络项最终有效的方法不是继续修改 WSL 的 Shell 环境而是直接配置 VS Code 自己的 HTTP 网络设置。在 VS Code 中按下Ctrl Shift P搜索Preferences: Open User Settings (JSON)在settings.json结尾加入http.proxy: http://172.19.0.1:7890, http.proxySupport: override我的完整配置结构类似注意上一项后面要添加逗号否则 JSON 格式会报错。八、验证结果1. 重新加载 VS Code保存配置后按Ctrl Shift P执行Developer: Reload Window等待 VS Code 和 Codex 插件重新加载。如果重新加载窗口后仍然没有生效可以完全关闭 VS Code再从 WSL 中重新启动2. 验证 Codex 是否使用该网络配置重新获取 PIDpid$(pgrep -n -f codex app-server) echo Codex PID: $pid查看相关环境变量tr \0 \n /proc/$pid/environ | grep -Ei ^(HTTP_PROXY|HTTPS_PROXY|NO_PROXY|http_proxy|https_proxy|no_proxy)成功后应该能看到类似3. 检查实际 TCP 连接执行watch -n 0.2 ss -tpn | grep -E codex|172\.19\.0\.1:7890然后在 Codex 中发送消息。配置成功后应该看到 Codex 连接到 Windows 本地转发端口在插件中可正常对话至此问题解决。九、最终结论本次问题的核心并不是 Windows 本地转发服务不可用也不是 WSL 无法访问该端口。真正的问题是WSL 终端中的网络环境变量只能证明当前 Shell 和从该 Shell 启动的程序能够使用该配置不能证明 VS Code 扩展启动的 Codex 进程也会继承这些变量。即使下面的命令可以正常访问curl https://example.comCodex 仍然可能没有使用本地转发端口。在我的环境中最终有效的解决方案是在 VS Code 的settings.json中显式配置http.proxy: http://172.19.0.1:7890, http.proxySupport: override配置完成并重新加载窗口后Codex 才真正通过 WSL 中可访问的 Windows 本地转发端口。说明本文仅记录 VS Code Remote WSL 下扩展进程网络配置的排查过程适用于企业内网、本地开发、前后端调试、内网服务转发等合规场景。