Win11+WSL2运行Codex卡顿？性能优化排查指南【解答】-人工智能-PHP中文网

win11上wsl2运行codex卡顿需四步排查：①安装vc++运行库并重启；②重置wsl2为nat+dns隧道模式；③项目迁移至wsl原生路径（非/mnt/c/）；④清理.codex目录下膨胀的sqlite日志与状态库。

win11+wsl2运行codex卡顿？性能优化排查指南【解答】

Win11系统上通过WSL2运行Codex时出现启动慢、响应迟滞、终端界面卡顿、VS Code中长期显示“Thinking…”等现象，不是模型退化或网络服务端问题，而是本地环境配置与资源分配失衡导致的底层运行阻塞，需从运行库、WSL网络模式、文件系统路径、状态库膨胀四个维度逐层排查。

确认并修复VC++运行库缺失

打开任务管理器（Ctrl+Shift+Esc），观察Codex启动瞬间是否高频调用powershell.exe和cmd.exe——若持续超60秒且无Codex主进程创建，大概率是VC++运行库未安装，导致Rust/Node原生组件根本无法加载。

访问微软官方页面下载vc_redist.x64.exe，双击运行→点“安装”→等待完成。

【安装后必须重启电脑】，否则系统DLL缓存仍指向空缺路径，Codex点击图标后依旧静默退出，不报错也不弹窗。

当前卡顿若伴随curl https://github.com报“Could not resolve host”，或wsl终端中cat /etc/resolv.conf返回空或错误IP，说明WSL DNS配置已被破坏，而Codex CLI依赖稳定域名解析发起token exchange请求。

方法一：强制恢复默认安全网络栈

在Windows中打开记事本，输入以下内容并保存为C:\Users\%USERNAME%\.wslconfig：

[wsl2]
networkingMode=NAT
dnsTunneling=true
autoProxy=false

保存后以管理员身份运行PowerShell，执行：wsl --shutdown → 关闭所有WSL终端 → 重新打开Ubuntu终端，输入cat /etc/resolv.conf，确认输出含nameserver 172.x.x.1（即Windows主机网关）。

方法二：若你曾手动修改过/etc/resolv.conf或启用mirrored模式，请先删除该文件，再执行上述.wslconfig写入步骤——【WSL不允许同时存在手动resolv.conf和dnsTunneling=true】，否则DNS彻底失效。

VS Code中Codex卡在“Thinking…”但wsl终端能ping通Google，说明网络通路已建立，问题出在文件系统层：Codex插件尝试扫描项目目录时，若路径位于/mnt/c/Users/xxx/project，会触发9P协议频繁跨VM读取，I/O堆积导致UI线程挂起。

第一步：确认当前路径是否踩坑

Codex Imagen

通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存

下载

在WSL终端中执行：df -T .，若输出中Type列为9p，立即停止操作，当前路径不可用于Codex开发。

第二步：创建原生工作区

执行：mkdir -p ~/projects/codex-demo && cd ~/projects/codex-demo，然后在此路径下克隆或初始化项目。

第三步：VS Code中重新连接WSL，用Remote-WSL打开~/projects/codex-demo，而非任何/mnt/开头路径。

这一步做完，Codex插件的文件监听开销下降80%以上，不再因扫描Windows NTFS元数据而卡死。

关闭Codex桌面端与所有WSL终端，按Win+R输入%USERPROFILE%\.codex回车，进入该目录。

重点检查：logs_2.sqlite（正常应＜20MB）、state_5.sqlite（必须能被DB Browser for SQLite正常打开）、codex-tui.log（单文件＞1GB即触发启动扫描风暴）。

方法一：改名隔离法（零风险）

将上述三个文件分别重命名为：logs_2.sqlite.old、state_5.sqlite.old、codex-tui.log.old。

方法二：归档旧会话减压

进入sessions/目录，将30天内未访问且未置顶的子目录，全部剪切到桌面新建的codex-sessions-archive文件夹中。

完成后启动Codex，它将自动重建轻量级状态库，首次启动时间从分钟级回落至3秒内。