1. 问题背景与核心痛点拆解Codex 在 Windows 上频繁出现 Reconnecting 提示本质上是客户端与后端服务之间的长连接被反复中断。很多人第一反应是是不是网络问题然后开始折腾 WSL、换终端、重装 VS Code结果发现该断还是断。我自己前前后后在这上面耗了差不多两个周末最后定位到的根因其实跟网络质量关系不大而是 Windows 环境下几个默认配置在互相打架。先把结论摆出来Codex 在 Windows 原生环境PowerShell VS Code下跑Reconnecting 的高频触发点集中在三个地方——代理环境变量残留、PowerShell 执行策略与编码、VS Code 终端与扩展宿主之间的会话隔离。这三个问题单独看都不致命但叠在一起就会让连接状态机反复进入重连循环。为什么很多人会往 WSL 方向走因为 WSL 里的 Linux 网络栈确实更干净没有 Windows 那套系统级代理、WinHTTP、WinINET 的分层干扰。但 WSL 的代价也很明显文件系统跨层 IO 慢、GPU 直通配置麻烦、VS Code 远程连接偶尔抽风、内存占用高。对于只是想让 Codex 稳定跑起来的场景上 WSL 属于用大炮打蚊子而且蚊子还没打死。这篇文章面向的是这样一类人你在 Windows 上用 VS Code 配合 Codex 做日常开发不想引入 WSL 这层额外复杂度但被 Reconnecting 搞得心态爆炸。我会把每个环节的排查逻辑、参数含义、实操命令都写清楚你照着做基本能定位到自己那一版的问题。涉及到的工具就是 Windows 自带的 PowerShell、VS Code 本体、以及 Codex 的配置文件不需要装任何第三方网络工具。需要提前说明的是下面提到的具体配置项和命令一部分来自官方文档一部分是我在实际排查中通过日志对比和二分法验证出来的经验值。Windows 版本差异Win10 和 Win11、PowerShell 版本差异5.1 和 7.x会导致表现不完全一致我会在对应位置标注。2. 先搞清楚 Reconnecting 到底在重连什么2.1 Codex 客户端的连接模型Codex 在 VS Code 里运行时实际存在两条独立的通信链路。第一条是 VS Code 扩展宿主Extension Host与 Codex 后端服务之间的主链路走的是 HTTPS 长连接加流式响应第二条是终端里 Codex CLI 进程与后端之间的链路如果你同时开了 CLI 和扩展这两条会各自维护自己的会话。Reconnecting 提示通常来自第一条链路。它的触发逻辑是客户端在约定时间内没有收到服务端的心跳或数据分片就判定当前连接失效进入重连退避。退避策略一般是 1s、2s、4s、8s 这样指数增长所以你看到的现象往往是连上了用几秒断了等一会儿又连上。关键点在于触发重连的不一定是真的断网。只要客户端的事件循环被阻塞、DNS 解析变慢、TLS 握手被中间层干扰都会让心跳超时。Windows 上这三件事都特别容易发生。2.2 为什么 Windows 原生环境更容易触发Windows 的网络栈有个特点系统级代理设置Internet 选项里的那个会被 WinHTTP 和 WinINET 分别读取而不同运行时读到的结果可能不一致。Node.js 运行时VS Code 扩展宿主基于 Electron底层是 Node默认会读HTTP_PROXY/HTTPS_PROXY环境变量但不会自动读 Windows 系统代理。如果你之前装过某些工具在系统里留了代理配置而环境变量又是另一套就会出现一部分请求走代理、一部分直连的割裂状态。这种割裂对普通 HTTP 请求影响不大但对长连接是致命的。因为长连接在建立时走了一条路径后续心跳可能走了另一条服务端看到的会话 ID 对不上直接踢掉。客户端收到断开信号开始重连循环往复。另一个高频因素是 PowerShell 的默认编码。Windows PowerShell 5.1 默认输出编码是 GBK代码页 936而 Codex CLI 和部分扩展通信期望 UTF-8。编码不一致会导致某些包含非 ASCII 字符的响应体解析失败解析失败被上层当成连接异常处理也会触发重连。2.3 排查前必须确认的三件事在动手改配置之前先花五分钟确认基础状态能省掉后面大量无用功。第一确认你的 Codex 版本和 VS Code 版本。打开 VS CodeCtrlShiftP输入Codex: Show Version记下版本号。然后Help About看 VS Code 版本。这两个版本组合决定了你遇到的是已知 bug 还是配置问题。第二确认当前 shell 环境。在 VS Code 集成终端里执行$PSVersionTable看清楚是 5.1 还是 7.x。如果是 5.1后面编码相关的坑你大概率会踩。第三确认环境变量里有没有代理残留。执行Get-ChildItem Env: | Where-Object { $_.Name -match proxy }把结果记下来。有输出就说明存在代理环境变量这是重点怀疑对象。提示这一步不要跳过。我见过太多人直接开始改配置改了半天发现根因是半年前某个工具留下的HTTPS_PROXY环境变量。3. 环境变量与代理配置的清理实操3.1 定位残留的代理变量Windows 上代理配置有三个来源必须全部检查。第一个是用户级环境变量第二个是系统级环境变量第三个是 WinINET 的系统代理设置就是Internet 选项 连接 局域网设置里那个。用户级和系统级用 PowerShell 查# 查用户级 [Environment]::GetEnvironmentVariables(User) | Format-Table -AutoSize # 查系统级 [Environment]::GetEnvironmentVariables(Machine) | Format-Table -AutoSize重点看HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY这几个大小写都要看因为 Node 运行时对大小写敏感而 Windows 环境变量本身不区分大小写容易出现http_proxy和HTTP_PROXY同时存在且值不同的情况。WinINET 的系统代理用注册表查Get-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings | Select-Object ProxyEnable, ProxyServer, ProxyOverrideProxyEnable为 1 表示系统代理开着ProxyServer就是代理地址。3.2 清理策略与取舍逻辑清理不是无脑全删。如果你确实需要代理才能访问外网那不能删要做的是统一——让环境变量和系统代理指向同一个地址并且确保NO_PROXY里包含本地回环地址。如果你不需要代理那就彻底清掉。用户级环境变量删除[Environment]::SetEnvironmentVariable(HTTP_PROXY, $null, User) [Environment]::SetEnvironmentVariable(HTTPS_PROXY, $null, User) [Environment]::SetEnvironmentVariable(ALL_PROXY, $null, User)系统级需要管理员权限把User换成Machine。注意系统级改动影响面大改之前先确认没有其他软件依赖。WinINET 系统代理关闭Set-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings -Name ProxyEnable -Value 0改完之后必须重启 VS Code因为环境变量是在进程启动时读取的热改不生效。而且建议重启一次资源管理器或者直接注销重登确保系统级变量刷新。3.3 NO_PROXY 的正确写法如果你保留代理NO_PROXY一定要写对。常见错误是只写localhost但实际需要覆盖的是127.0.0.1、::1、localhost三个。正确写法NO_PROXYlocalhost,127.0.0.1,::1为什么这三个都要因为不同运行时解析localhost的结果不同有的优先 IPv4有的优先 IPv6。如果只写了localhost而实际连接走的是127.0.0.1代理判断就会漏掉本地回环流量被塞进代理直接导致连接异常。注意改完环境变量后用Get-ChildItem Env:在新开的终端里再确认一遍确保改动生效。我遇到过改了用户级变量但当前终端继承的是旧会话的情况白折腾半小时。4. PowerShell 执行策略与编码的坑4.1 执行策略对 Codex 启动的影响Codex 的 VS Code 扩展在启动 CLI 子进程时会调用 PowerShell 执行脚本。Windows 默认执行策略是Restricted不允许运行任何脚本。虽然扩展通常会带-ExecutionPolicy Bypass参数绕过但如果你的组策略强制覆盖了执行策略Bypass 也会失效。查当前执行策略Get-ExecutionPolicy -List输出会列出 MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachine 五个作用域。优先级从高到低是 MachinePolicy UserPolicy Process CurrentUser LocalMachine。如果 MachinePolicy 是 Restricted那你在用户层面怎么改都没用得找 IT 或者改组策略。对于个人机器把 CurrentUser 设为 RemoteSigned 就够了Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserRemoteSigned 的含义是本地写的脚本可以直接跑从网络下载的脚本需要签名。这个策略在安全性和可用性之间平衡得比较好也是微软推荐的开发机配置。4.2 编码问题的定位与修复编码问题的典型症状是Codex 能连上但输出里出现乱码或者某些操作执行到一半卡住然后 Reconnecting。根因是 PowerShell 5.1 的$OutputEncoding和[Console]::OutputEncoding默认不是 UTF-8。先看当前编码$OutputEncoding [Console]::OutputEncoding [Console]::InputEncoding如果输出里出现936或者GB2312那就是问题所在。修复方式是在 PowerShell 配置文件里设置$OutputEncoding [System.Text.Encoding]::UTF8 [Console]::OutputEncoding [System.Text.Encoding]::UTF8 [Console]::InputEncoding [System.Text.Encoding]::UTF8配置文件路径用$PROFILE查看如果文件不存在就创建if (-not (Test-Path $PROFILE)) { New-Item -Path $PROFILE -ItemType File -Force } notepad $PROFILE把上面三行贴进去保存然后. $PROFILE重新加载。4.3 PowerShell 5.1 与 7.x 的差异处理PowerShell 7.x 默认就是 UTF-8编码问题基本不存在。所以如果你的机器上装了 7.x最省事的方案是让 VS Code 默认用 7.x 作为集成终端。在 VS Code 的settings.json里加{ terminal.integrated.defaultProfile.windows: PowerShell, terminal.integrated.profiles.windows: { PowerShell: { source: PowerShell, path: C:\\Program Files\\PowerShell\\7\\pwsh.exe, args: [-NoLogo] } } }路径根据你实际安装位置调整。装 7.x 的方式很多微软商店、winget、msi 都行winget install Microsoft.PowerShell最省事。但要注意Codex 扩展调用的 shell 不一定跟随 VS Code 集成终端的设置。扩展可能读的是系统默认 shell 或者自己配置的 shell 路径。所以换 7.x 之后还要去 Codex 的设置里确认 shell 路径。在 VS Code 设置里搜codex.shell或者codex.terminal看有没有相关配置项。实操心得我建议即使换了 7.x也把 5.1 的编码配置一起改了。因为有些工具链会硬编码调用powershell.exe5.1你没法保证所有调用路径都走 7.x。两手准备最稳。5. VS Code 终端与扩展宿主的会话隔离问题5.1 扩展宿主和终端的进程关系VS Code 的架构里扩展跑在独立的 Extension Host 进程里终端跑在 ptyHost 进程里两者通过 IPC 通信。Codex 扩展如果需要在终端里执行命令走的是terminal.sendText这类 API命令实际在 ptyHost 管理的 shell 里执行输出再回传给扩展。这个架构本身没问题问题出在生命周期管理上。当你关闭终端面板但没杀进程、或者切换工作区、或者扩展宿主因为内存压力被重启时终端进程和扩展进程的状态可能不同步。扩展以为终端还在发命令过去没响应超时后触发重连逻辑。判断是不是这个问题看 VS Code 的进程列表。CtrlShiftP输入Developer: Show Running Extensions找到 Codex看它的激活状态和运行时长。如果运行时长很短、反复重启那就是扩展宿主不稳定。5.2 终端复用与会话保持配置减少这类问题的核心思路是让终端会话尽量稳定不要频繁创建销毁。VS Code 有个设置叫terminal.integrated.enablePersistentSessions默认是 true保持开启。另外建议关掉终端的自动重启{ terminal.integrated.enablePersistentSessions: true, terminal.integrated.persistentSessionReviveProcess: never }persistentSessionReviveProcess设为never的含义是VS Code 重启后不尝试恢复之前的终端会话。这看起来反直觉但实际能减少状态不一致。因为恢复出来的会话是假活状态扩展连上去发现 shell 上下文丢了反而更容易触发异常。还有一个关键设置是terminal.integrated.env.windows可以给终端注入干净的环境变量{ terminal.integrated.env.windows: { HTTP_PROXY: , HTTPS_PROXY: , ALL_PROXY: } }这样即使系统里有残留代理变量终端里也是干净的。注意这里设成空字符串而不是删除因为 VS Code 的环境变量合并逻辑是覆盖设空能确保覆盖掉继承来的值。5.3 扩展宿主内存与重启策略Codex 扩展如果处理大文件或者长会话内存占用会涨。VS Code 默认给扩展宿主的内存上限不算高超了会触发 GC 甚至重启。可以在启动参数里调高在 VS Code 快捷方式的目标后面加--max-memory8192单位 MB。或者如果你用命令行启动code --max-memory8192这个值根据你机器内存来16G 内存的机器给 4G 到 8G 比较合适。给太大反而会让系统整体 swap 变多得不偿失。另外Developer: Reload Window这个操作要慎用。它会把扩展宿主整个重启Codex 的连接状态全丢重连风暴往往就是这么来的。如果只是想刷新扩展用Developer: Restart Extension Host更温和。6. 完整排查流程与验证方法6.1 分步排查清单把前面的内容整理成一个可执行的排查顺序按这个顺序走基本能覆盖 90% 的场景。步骤操作预期结果异常处理1查环境变量代理残留无 proxy 相关变量按 3.2 清理2查 WinINET 系统代理ProxyEnable 为 0按 3.2 关闭3查 PowerShell 执行策略CurrentUser 为 RemoteSigned按 4.1 设置4查终端编码全部为 UTF-8按 4.2 修复5查 VS Code 终端配置持久会话开启、恢复关闭按 5.2 配置6查扩展宿主内存无频繁重启按 5.3 调高上限7重启 VS Code 验证Reconnecting 消失回到步骤 1 复查6.2 日志抓取与问题定位如果走完清单还有问题就得看日志了。Codex 扩展的日志在 VS Code 的输出面板里CtrlShiftU打开输出右上角下拉选 Codex。把日志级别调到 Debug在设置里搜codex.logLevel然后复现问题。重点看日志里的时间戳。Reconnecting 触发前的那几行是关键通常会看到类似heartbeat timeout、stream closed、ECONNRESET这样的信息。不同错误对应不同根因heartbeat timeout且前面有长时间无日志事件循环被阻塞查扩展宿主内存ECONNRESET连接被重置查代理和防火墙stream closed且伴随编码错误查 PowerShell 编码DNS lookup failed查 DNS 配置考虑换 DNS 服务器6.3 验证是否真正解决改完配置后怎么确认真的解决了而不是碰巧好了我的做法是做一个压力验证连续使用 Codex 执行 20 次以上的操作中间穿插大文件读取和长文本生成观察 30 分钟内是否出现 Reconnecting。如果 30 分钟稳定基本可以认为解决。如果还有偶发把日志留存对比触发时的系统状态内存占用、CPU、网络连接数。用Get-NetTCPConnection看 Codex 相关的连接状态Get-NetTCPConnection | Where-Object { $_.OwningProcess -in (Get-Process -Name Code -ErrorAction SilentlyContinue).Id } | Format-Table -AutoSize看有没有大量TimeWait或者CloseWait状态的连接堆积。如果有说明连接没有正常关闭可能是某个环节的 keep-alive 配置有问题。7. 常见问题速查与避坑经验7.1 高频问题速查表现象可能原因快速验证解决方向连上几秒就断代理变量不一致查环境变量和系统代理统一或清理代理输出乱码后断连PowerShell 编码非 UTF-8查 Console.OutputEncoding设 UTF-8切换工作区后断终端会话状态丢失查持久会话配置开启持久会话长时间运行后断扩展宿主内存超限查扩展运行时长调高内存上限特定操作必断该操作触发脚本执行查执行策略设 RemoteSigned重启 VS Code 后断会话恢复状态不一致查恢复配置关闭自动恢复7.2 几个容易踩的坑第一个坑是改了环境变量但没重启终端。环境变量在进程启动时读取已经开着的终端和 VS Code 不会感知变化。改完必须全部关掉重开包括 VS Code 本体。第二个坑是PowerShell 配置文件被多个来源覆盖。$PROFILE有多个变体CurrentUserCurrentHost、CurrentUserAllHosts 等你可能改了其中一个但实际生效的是另一个。用$PROFILE | Format-List *看清楚所有路径逐个检查。第三个坑是VS Code 设置的作用域搞混。用户设置、工作区设置、远程设置三层优先级不同。Codex 相关配置建议放在用户设置里避免工作区设置覆盖导致行为不一致。第四个坑是以为装了 WSL 就万事大吉。WSL 确实能绕开一部分 Windows 网络栈问题但引入了新的变量WSL 的网络模式NAT 还是 mirrored、WSL 内的 DNS 配置、跨文件系统访问的性能损耗。我见过有人从 Windows 原生迁到 WSLReconnecting 没了但变成了操作卡顿和文件监听失效问题只是换了个形式。7.3 关于是否上 WSL 的判断什么情况下值得上 WSL如果你的开发栈本身就是 Linux 优先比如要用到某些只有 Linux 才有的工具链那 WSL 是合理选择Codex 的稳定性只是顺带收益。但如果你的项目是纯 Windows 开发只是为了 Codex 稳定而上 WSL性价比很低。判断标准很简单列出你上 WSL 之后需要额外配置的东西。如果超过三项比如 GPU 直通、文件系统性能调优、网络模式配置、VS Code 远程连接调试那就别上。Windows 原生环境把前面几节的配置做对稳定性完全够用。我个人经验Windows 原生 PowerShell 7.x 干净的环境变量 正确的编码配置这套组合我连续跑了三个月Reconnecting 出现次数是个位数而且每次都是网络本身波动导致的不是配置问题。8. 配置固化与长期维护8.1 把配置写成可复现的脚本排查一次就够了别每次换机器都重来。把关键配置写成一个 PowerShell 脚本新机器上跑一遍就搞定。# codex-env-setup.ps1 # 清理代理变量 [Environment]::SetEnvironmentVariable(HTTP_PROXY, $null, User) [Environment]::SetEnvironmentVariable(HTTPS_PROXY, $null, User) [Environment]::SetEnvironmentVariable(ALL_PROXY, $null, User) # 设置执行策略 Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force # 设置编码 $profileContent $OutputEncoding [System.Text.Encoding]::UTF8 [Console]::OutputEncoding [System.Text.Encoding]::UTF8 [Console]::InputEncoding [System.Text.Encoding]::UTF8 if (-not (Test-Path $PROFILE)) { New-Item -Path $PROFILE -ItemType File -Force | Out-Null } Add-Content -Path $PROFILE -Value $profileContent Write-Host 配置完成请重启 VS Code这个脚本只做用户级改动不需要管理员权限安全可控。系统级的东西手动确认后再改。8.2 VS Code 设置的版本管理VS Code 的用户设置文件在%APPDATA%\Code\User\settings.json建议用 Git 管理起来。这样换机器或者配置被改乱时直接 checkout 回来。需要纳入管理的配置项{ terminal.integrated.defaultProfile.windows: PowerShell, terminal.integrated.enablePersistentSessions: true, terminal.integrated.persistentSessionReviveProcess: never, terminal.integrated.env.windows: { HTTP_PROXY: , HTTPS_PROXY: , ALL_PROXY: } }Codex 自己的配置项如果支持导出也一并纳入。这样整套环境是可复现的不会出现我机器上好好的换台机器就不行的情况。8.3 定期检查的项配置不是一劳永逸的。Windows 更新、VS Code 更新、Codex 扩展更新都可能改变默认行为。建议每个月花五分钟检查这几项环境变量里有没有新增的代理配置某些软件安装时会偷偷加PowerShell 执行策略有没有被组策略覆盖VS Code 的终端配置有没有被更新重置Codex 扩展的日志级别是不是还开着 Debug长期开 Debug 会影响性能把这些检查项也写进脚本做成一个check-codex-health.ps1跑一遍输出体检报告。这比出问题再排查效率高得多。最后分享一个我一直在用的小技巧在 VS Code 的settings.json里加一条codex.autoReconnect: false如果你的版本支持这个配置项把自动重连关掉改成手动重连。这样虽然偶尔需要手动点一下但能避免重连风暴导致的资源浪费而且问题暴露得更明显方便定位。这个配置项在不同版本里名字可能不一样搜reconnect关键词找对应的。