[分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录

第一稿，出去吃火锅了…

断断续续研究了将近一天，终于把 cc codex 和 opencode 都迁移到了 wsl 里 了；在这里开个记录帖子，记录下自己遇到的问题以及解决方案，欢迎各位佬友友好交流，分享自己的经验。

1. 迁移动机（废话略多）

• 最重要的一点，codex 在 windows 上的表现不佳且速度慢；
  在 windows 上使用 codex 的佬友一定经常见到过 codex 的 PowerShell 语法错误… 大量的时间和 token 被浪费于此，尽管在提示词里针对 codex 经常犯错的部分进行了提示，但仍无法有效地解决，根本原因还是 pwsh 的训练数据太少，而 unix 类天生就是大家默认的开发环境，数据多，支持地更好。且在 Linux 上 codex、cc 运行起来也更加丝滑

• opencode 的 windows 兼容过于垃圾；
  opencode 在爆火之前我就早早的接触过了，然而… 其对 windows 的支持可谓十分之差，经常出现上一个版本还是可以启动，下一个版本就不能启动了，打开 opencode 的 github 你会发现类似的 issue 层出不穷，最经典的就是渲染出错，启动 opencode，出现 opencode [object] [Object]；在经历数次 codex 手动修复让其能够启动后，我受够了。

• 常用的工具包或插件如 codeagent 和 claude mem 等对于 windows 的支持也很差；
  前者是我使用频率最高的 workflow+skill；而后者我更是从来没有在 windows 上成功启动过，考虑到众多插件都会优先支持 Linux 和 MacOS，我还是迁移的好。

2. windows 已有配置

• cc switch
  我是 cc switch 的忠实用户，ccs 的伟大无需多言；我用到的核心功能主要是

  1. 多配置切换，供应商 + 全局提示词；我有各家的 coding plan 以及自己手写的多套全局提示词，十分需要 ccs 统一管理；
  

  ccs 在当前版本可以指定 wsl 目录，这使得迁移起来没有什么难度，但是我并没有选择使用。

  2. ccs 的代理和统计功能，开启后可以直观地观测自己每天的 token 用量；ccs 的本地代理功能也是此次迁移较为顺利的根本原因
     
     

3. 迁移记录

3.1 基础部分

1. 安装 codex claude code opencode；过于简单，为了方便，我统一用 npm 了；

2. 添加供应商配置，这个时候，刚才说过的 ccs 的本地代理功能就派上用场了；只需要把 url 指向 ccs 的代理端口即可，这里以 codex 为例

   
   
   我出于一些考量，并没有选择用 ccs 直接配置，你也可以在这里更改配置目录后用 ccs 进行配置，更加自动
   
   

3.2 问题来了

mcp 迁移，对于一些 npx nvx 或者 remote 类型的 mcp 很简单，都不需要改；

都知道 wsl 好，为什么我迟迟没有迁移打算呢，问题就在于这里，因为个人手搓的小玩意对于 playwright 的依赖程度较高，而 wsl… 配置图形化… 比较麻烦吧，支持地也不好，当然 这些都不是问题。

在调研站里的方案，以及询问 gpt52pro 后，我有了方案 1:

方案 1: WSL2 里跑 Linux Playwright（WSLg）

在 WSL2 里跑 Linux 浏览器（WSLg 出窗口），这个… 需要做不少的前置准备，且最后的效果也不尽人意，我在跑通后遂放弃。

1 首先必须有显示环境（WSLg）

 echo "$DISPLAY" echo "$WAYLAND_DISPLAY" echo "$XDG_RUNTIME_DIR" 

2 得有浏览器二进制（Playwright 下载的 Chromium/Firefox/WebKit）

npx playwright install

3 必须有系统依赖（Ubuntu 的一堆 .so）

 # 安装系统依赖 sudo env "PATH=$PATH" npx playwright install-deps

这一套跑完，可以按照站里佬的方案持久化安装 playwright 或者 npx 启动；

它的问题是什么呢？WSLg 的浏览器实在太丑了！包括且不限于

1. 字体的缺失导致渲染出来的网页相当地丑，你根本无法判断是自己 UI 设计问题还是渲染问题
2. 启动时候默认一个半截窗口，全屏后不会响应式调整页面大小！这个过于逆天

尤其是 2 是我放弃方案 1 的最直接原因；

而方案 2 是我现在使用的方案，我似乎没有看到有佬提及这个方案来着？有一个佬友给出了类似的 chrome dev mcp 的安装方式，所以我就放上来供佬友参考；

方案 2： Windows 侧 Playwright MCP

基本的原理：

WSL2 (Ubuntu): claude / codex
  |
  v
/mnt/c/Windows/System32/cmd.exe /c npx @playwright/mcp@latest
  |
  v
Windows: Node+npx -> @playwright/mcp -> Playwright -> Browser (Windows GUI)

那么很简单了，以 cc 为例子：

"playwright": { "type": "stdio", "command": "/mnt/c/Windows/System32/cmd.exe", "args": ["/c", "npx", "@playwright/mcp@latest"], "env": {} } 

就这么简单

4. 番外部分

4.1 官方订阅问题

当前版本的 ccs 在 codex official oauth 时候不支持本地代理功能，那么如何也让它走统计呢？答案很简单，走 cliproxyapi 这类的反代工具套一层即可，这样子官方订阅也就可以被 ccs 后台统计用量了；

同理，对于 antigravity tool 这类工具，也可以接入到 ccs 里统一参与用量统计；

4.2 opencode 问题

如何让 opencode 也能用上 ccs 的代理功能，其实站里有佬友已经给出解决方案了，以 codex 为例，答案就是覆写 opencode 的 openai 供应商的 base_url 字段，更改其为 ccs 暴露的本地代理端口；

不过我由于日常只有 cc 在用 omo 工作流时候会用到 opencode 的 grok 模型，对 opencode 的研究并不多，当前我发现一个很奇怪的问题，就是 opencode 会请求 gpt-5-nano；这里我还没有找到很好的解决思路。

希望有佬友可以出手！