Codex终于上Linux：别急着退MacBook，App、CLI、WSL到底怎么选？

Codex 负责人 Tibo 昨晚发了一句很会带节奏的话：Linux 版终于来了，等不及买了 MacBook 的人可以取消订单了。

截至发稿前，这条公开帖子已经超过 49 万浏览。热度是真的，但“可以退 MacBook”显然不是购买建议。

所以，先别急着下载。你真正要选的不是 Linux 和 Mac，而是 App、CLI、WSL 谁来当主工作台。

Codex CLI 原本就支持 Linux。很多开发者一直在终端、SSH、VS Code 或远程服务器里用它。

8 月 12 日补上的，是官方桌面 App。首批明确支持：

如果你只在终端里改代码，模型没有因此变强；如果你经常并行跑多个项目、看 diff、预览文件、切浏览器流程，桌面 App 才会明显改变体验。

还有一个边界要先说：官方当前把 Computer Use 桌面操作能力列在 macOS 和 Windows，Linux 预览版不能直接按功能完全对齐来理解。Linux 公告写的是 browser workflows，不等于能接管所有 Linux 桌面应用。

A. Linux桌面开发机：优先App

你的代码就在 Ubuntu、Debian 或 Fedora 桌面上，又经常同时开几个项目，可以优先试官方 App。

它的价值不是省掉一条命令，而是把项目列表、并行对话、文件预览、Git 变更和浏览器检查放在一起。你可以让 Codex 改代码，同时在审查面板里看它到底动了什么。

发布后的早期公开讨论也集中在这个差异上：有人已经装好并追问“只是 GUI，还是也有 Computer Use、远程控制”；也有人明确表示服务器工作仍会留在 CLI。争论的核心不是 App 能不能启动，而是哪一层工作流真的被补齐。

B. Windows电脑+WSL2：先定主环境

这是最容易把配置弄乱的一组。

Windows App 默认让 Codex 在 PowerShell 里运行。它可以打开 WSL2 里的项目，也可以切换成让 Agent 本身运行在 WSL2；切换后需要重启 App 才生效。

更关键的是，Windows App 默认使用 Windows 用户目录里的 .codex，WSL 内单独运行的 CLI 默认使用 Linux home 下的 .codex。两边不会自动共享配置、登录缓存和会话历史。

因此不要一上来就复制整个目录。先选一条主线：

1. Windows原生为主：项目放 Windows 文件系统，WSL 通过 /mnt/... 访问。

2. WSL为主：在 App 设置里把 Agent 切到 WSL2，项目和工具链都留在 Linux 文件系统。

3. 两边隔离：Windows App 和 WSL CLI 各用各的 .codex，接受历史不互通，换来边界更清楚。

C. 远程Linux服务器：继续CLI

如果工作发生在云主机、开发容器、SSH 或 tmux 里，桌面 App 不是必需品。

CLI 更贴近服务器的真实工具链，也更容易放进脚本、CI 和自动化。你可以在本地 App 里做需求拆分和代码审查，再把确定的任务交给远程环境；也可以从头到尾留在 CLI。

这里的判断标准不是“GUI更先进”，而是 任务最终在哪台机器执行、文件和依赖在哪里、出错后你要在哪里验收。

三条路线的代价也不一样：

这里没有统一的“最强方案”。你省下的界面切换，可能会变成配置维护；你保留 CLI 的稳定，也会放弃一部分可视化工作区。

第一步：看系统。确认发行版、版本和架构在首批支持范围内；不在名单里，只能算兼容性尝试，不算官方承诺。

第二步：看项目。项目主要在 Linux 本地、Windows 盘、WSL 文件系统，还是远程服务器？先定主位置，再选入口。

第三步：看旧配置。备份现有 .codex，记录自定义规则、Skills、MCP、工具路径和环境变量。不要覆盖后才想起旧会话在哪里。

第四步：看权限。先用受限模式打开一个测试项目，确认它能读取、编辑、跑测试和生成 diff；不要为了少点一次确认就直接给全盘权限。

第五步：做回退。保留原来的 CLI 和安装方式。App 还在 preview，遇到兼容问题时，应该能立即回到已经验证过的终端流程。

Linux 桌面开发机，想要统一项目、对话、文件和审查：可以试 App，但先按测试仓库验收。

Windows 加 WSL2：先确定 PowerShell 还是 WSL 是主环境，避免两套配置一起漂移。

远程服务器和纯终端工作流：继续用 CLI，不必为了新界面迁移。