GSC 后台看到一个搜索词，叫”codex mac intel 版本”。84 次曝光，0 次点击。点不进来，是因为搜的人想要一个确定答案：我这台 Intel Mac，到底能不能跑 Codex？
答案要拆成两半。Codex CLI 能。Codex Desktop App 不能。
下面这篇把这条线讲清楚，包含三条安装路径、Node 版本陷阱、7 个常见报错、以及一份「我应不应该死磕 Desktop」的判断表。
先说结论
把上面那句话再展开一层：
- Codex CLI：OpenAI 官方在 GitHub Release 同时发布
codex-x86_64-apple-darwin.tar.gz和codex-aarch64-apple-darwin.tar.gz。前者就是给 Intel Mac 的原生 x86_64 二进制，跟 Apple Silicon 平起平坐。npm、Homebrew Cask、直接下二进制三条路都通。 - Codex Desktop App：OpenAI 官方 GitHub issue #10410 里用户反馈在 Intel Mac 上跑出来是「禁止」图标根本启动不了。OpenAI 暂未给出 x86_64 build 时间表。社区有民间 fork 能 patch 起来跑，但要自己编译，下面单独讲。
所以如果你只是想在 Intel Mac 上用 Codex 写代码、跑 agent、做修改 commit，装 CLI 就行。不需要等 Desktop，不需要折腾 Rosetta，更不需要换机器。
你真正要解决的不是「有没有 Intel 版」，是装完之后那一连串 codex: command not found、EBADENGINE、EACCES 报错。这些跟 Intel 没关系，跟 Node 生态有关系。
Intel Mac 在 AI 编程工具里被默认歧视了一段时间。Apple 自己 2020 年宣布转 Apple Silicon 后，2023 年底基本不再卖 Intel 新机型，整个开发者生态对 Intel 的优先级一路下滑。但 2017-2020 年那批 Intel MacBook Pro 还有大量在役机器，硬件性能跑 LLM CLI 客户端完全够。这就出现一个错位：硬件没问题，工具方的 release pipeline 把你忘了。
具体到 Codex，OpenAI 在 CLI 这条线上没忘——CLI 用 Rust 写、cross compile 到 x86_64 几乎零成本，一开始就把 Intel binary 一起发出来了。Desktop App 那边是 Electron + native module + Code signing 三重负担，他们选了 Apple Silicon 先行。判断一下产品逻辑就知道，Intel Desktop 短期内不会有——OpenAI 没动机为一个被淘汰的硬件平台维护一条单独的 build pipeline。
所以心态要调整：不要等 Desktop，就用 CLI。CLI 不是「过渡方案」，是 OpenAI 这条产品线对开发者的最终形态。
CLI 和 Desktop App 不是一个东西
很多人把这两个混为一谈，然后在搜索引擎里搜「Codex Intel Mac 版本」时被官方下载页劝退，以为 Intel Mac 整个生态都缺。
它们其实是两个独立产品：
| 产品 | 形态 | macOS Intel | macOS Apple Silicon | Linux | Windows |
|---|---|---|---|---|---|
| Codex CLI | 命令行（Rust 编译） | 原生 x86_64 支持 | 原生 arm64 支持 | 支持 | 支持（PowerShell / WSL2） |
| Codex Desktop App | Electron GUI | 不支持（issue #10410） | 支持 | 不支持 | 不支持 |
CLI 是用 Rust 写的，单文件可执行，启动快、占内存少、跨架构编译没难度。Desktop 是 Electron 套壳，里面绑了 Chromium runtime、Node 子进程、native modules，每个目标架构都要单独签名打包，OpenAI 目前只优先 arm64。
判断标准很简单：如果你想要的是「在终端里跟模型聊天 + 改代码 + 跑 agent」，CLI 就够。Desktop 提供的多会话切换、可视化 diff、富文本编辑这些功能，CLI 也都有，只是文本界面。习惯 vim / tmux 的人甚至会觉得 CLI 更顺手。
类似的产品分层在 Anthropic 那边也一样。Claude 也是先有 Desktop App 后有 Claude Code CLI，两者底层模型一致但前端形态不同，开发者实际上更依赖 CLI 这条线。CCswitch 实战那篇把 Claude 桌面版和 CLI 的角色拆得很清楚，对照看 Codex 这两条线会更直观。
Intel Mac 的三条安装路径
下面按「踩坑概率从低到高」排序。
路径 1：Homebrew Cask（最省心）
brew install --cask codex
codex --version
Homebrew 帮你处理了 PATH、签名公证、版本升级。前提是你装的 Homebrew 是 Intel 版（路径在 /usr/local/bin/brew，不是 Apple Silicon 的 /opt/homebrew/bin/brew）。
升级也是 brew upgrade --cask codex 一行。99% 的 Intel Mac 用户走这条最稳。
路径 2：npm（跟 Node 生态绑死的话）
npm install -g @openai/codex
codex --version
注意包名是 @openai/codex，不是 codex。后者是别人的旧包，装完跑起来不是同一个东西。OpenAI 官方 issue #9356 就是因为模型有时候自己给用户写错升级命令导致的。
走 npm 的代价是 Node 版本要求 22+，下一节细讲。
路径 3：直接下二进制（没 Node、不想装 brew）
去 GitHub Release 页面，找 codex-x86_64-apple-darwin.tar.gz：
curl -L -o codex.tar.gz \
https://github.com/openai/codex/releases/latest/download/codex-x86_64-apple-darwin.tar.gz
tar -xzf codex.tar.gz
sudo mv codex-x86_64-apple-darwin /usr/local/bin/codex
codex --version
第一次跑可能被 Gatekeeper 拦：「无法验证开发者」。xattr -d com.apple.quarantine /usr/local/bin/codex 一句话解决。
这条路适合公司机器没有 Homebrew 权限、或者想在 Docker 镜像里 pin 死某个版本的人。
Node 22 是硬要求，不是建议
走 npm 安装时最容易翻车的一处。
@openai/codex 在 package.json 里把 engines.node 写成 >=22。Node 22 是 2024 年 10 月发布的当前 LTS。如果你机器上的 Node 是 18 或 20，npm install -g @openai/codex 会抛：
npm WARN EBADENGINE Unsupported engine {
package: '@openai/[email protected]',
required: { node: '>=22' },
current: { node: 'v20.11.0', npm: '10.2.4' }
}
EBADENGINE 只是 warning，npm 不会拒绝安装。但装完跑起来会在 ESM 解析、worker_threads 上随机崩。别为了省事忽略它。
给 nvm 用户的提醒
如果你用 nvm 管 Node 版本，npm 的 global prefix 是按 Node 版本隔离的：
~/.nvm/versions/node/v22.5.0/bin/codex # 装在 22 上
~/.nvm/versions/node/v20.11.0/bin/codex # 这里没东西
所以下面这条流水线特别常见：你在 Node 22 下装了 codex，下次开终端 nvm 默认切到 18，输 codex 就 not found。
固定 default 版本是唯一干净的解：
nvm alias default 22
nvm use default
npm install -g @openai/codex
在 ~/.zshrc 顶部加一句 nvm use default --silent，每个新终端都会先切到 22。
不想折腾 nvm 的话，直接去 nodejs.org 下 Node 22 LTS 的 .pkg 装到系统路径 /usr/local/bin/node。所有 shell（包括 GUI 应用启动的非交互 shell）都能找到。
装完跑不起来：7 个常见坑
按出现频率排序。codex: command not found 是 80% 的情况。
坑 1：PATH 没包含 npm global bin
最常见的一个。npm 装完会提示 binary 写到了 /Users/you/.npm-global/bin/codex 这种位置，但 PATH 里根本没有这个目录。
诊断：
npm prefix -g
echo $PATH | tr ':' '\n' | grep "$(npm prefix -g)/bin" || echo "NOT ON PATH"
如果是 NOT ON PATH，在 ~/.zshrc 加：
export PATH="$(npm prefix -g)/bin:$PATH"
然后 source ~/.zshrc。
注意 ~/.zshrc 只对交互 shell 生效。如果你想让 GUI 应用（比如某些 IDE 内置 terminal）也能找到 codex，要写到 ~/.zshenv 里。Apple Silicon 用户可能习惯把 PATH 设置放 .zprofile，Intel Mac 用户可以保持一致，但要确认 macOS 升级后这个文件还会被读。
坑 2：sudo 装的，权限错乱
如果你历史上 sudo npm install -g xxx 过，/usr/local/lib/node_modules 这个目录的 owner 可能混着 root 和你的账号。再装 codex 时报 EACCES: permission denied。
干净解法是把全局 prefix 换到用户目录：
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
npm install -g @openai/codex
以后所有全局包都不需要 sudo。前阵子那个 Claude Opus 写 SQL 删库的故事就是个反例——把高权限的工具链跟 AI agent 混在 root 账号上跑，出事的时候追责都难。
坑 3：Volta / asdf 用户的 shim 没生成
Volta：
volta install node@22
volta install @openai/codex
asdf：
npm install -g @openai/codex
asdf reshim nodejs
asdf 不 reshim 的话，新装的 binary 在 ~/.asdf/installs/nodejs/22.x/.npm/bin 但 PATH 里挂的是 ~/.asdf/shims/，永远找不到。
坑 4：装错了包名
npm install -g codex 装的是 1999 年的某个 mock library，不是 OpenAI Codex。看清楚是 @openai/codex，带 scope。
坑 5：装在了 Apple Silicon Homebrew 上
如果你机器是双 Homebrew（很少见，迁移过的人会有）：
/usr/local/bin/brew # Intel 版
/opt/homebrew/bin/brew # Apple Silicon 版（你机器不该有）
Intel Mac 应该只有前者。后者是迁移工具误装的，brew 自己跑不起来，会把 PATH 搞乱。brew config 看一眼 prefix 在哪。
坑 6：登录卡住，OAuth 回调到不了
第一次跑 codex，会弹浏览器要求 ChatGPT 登录。Plus / Pro / Business / Edu / Enterprise 任一档都行，免费版不行。
OAuth 回调走 http://127.0.0.1:<port>。如果你机器上有 Charles / Proxyman / VPN 客户端拦了 localhost，会卡住。临时关代理或者把 127.0.0.1 加白名单就好。Claude 接入 Charles 抓包那篇把 MCP 代理这条路讲透了，原理对 Codex 完全适用，排错时可以参考。
坑 7：装完能跑，但 codex login 报 Unauthorized
两种情况：
- 你账号没 Codex 权限：ChatGPT 免费版、Team 版的部分席位不带。去 ChatGPT 网页版看左下角能不能进 Codex 面板，进不去就是席位问题。
- 企业 SSO 没放行：你公司 ChatGPT Enterprise 管理员可能没开 Codex OAuth。让管理员去 Workspace 设置里勾上。
最近 Anthropic 7 月 8 日要强制 Claude 走身份验证，细节在这里。两家厂商都在收紧 auth 层，这条路上以后还会出更多坑。
Rosetta 在这条路上没你想的那么重要
很多 Intel Mac 用户一遇到「装不上」就第一反应「是不是要开 Rosetta」。
对 Codex CLI 来说，不需要。 x86_64 binary 是为 Intel CPU 原生编译的，根本不经 Rosetta 这层翻译。Rosetta 是给 Apple Silicon 跑 x86_64 binary 用的，方向反了。
唯一需要 Rosetta 的场景：你是 Apple Silicon 用户，但因为某些 native module 还没 arm64 build，被迫用 x86_64 版本 Node。这种情况下你装的 Codex 也是走 Rosetta 翻译的 x86_64 路径，性能损失约 10-20%。但这是 Apple Silicon 的问题，不是 Intel 的。
所以纯 Intel Mac 用户读到这一段可以放心：你装的是 native 二进制，没有性能损失。
顺带澄清一个相关误解：Apple 在 2020 年发布的 Rosetta 2 跟初代 Rosetta（PowerPC → Intel）原理不同，是 AOT + JIT 混合翻译，性能损失通常在 20% 以内。但 Codex CLI 不需要碰这层，所以你 Intel Mac 上跑 codex 的实际性能就是 Intel CPU 的原生算力，跟同代 Apple Silicon 比当然慢一截，但对 CLI 客户端来说这点延迟根本感受不到——瓶颈在网络往返延迟和 OpenAI 推理服务的响应时间，不在你本地 CPU。
也就是说，Intel Mac 跑 codex 唯一可感的性能瓶颈是网速，不是 CPU。这点跟跑本地 LLM 完全不同。
升级、版本管理与回滚
Codex CLI 迭代很快，2026 年这半年差不多每两周一个 release。三种安装路径升级命令各不一样：
# Homebrew
brew upgrade --cask codex
# npm
npm install -g @openai/codex@latest
# 直接二进制：重新下载覆盖
curl -L -o /tmp/codex.tar.gz \
https://github.com/openai/codex/releases/latest/download/codex-x86_64-apple-darwin.tar.gz
tar -xzf /tmp/codex.tar.gz -C /tmp
sudo mv /tmp/codex-x86_64-apple-darwin /usr/local/bin/codex
模型有时候会自己建议你跑 npm install -g codex（漏 scope），结果你装了个无关的旧 npm 包覆盖了 PATH。OpenAI 自己的 issue tracker 里就有这个反馈，对应 issue #9356。看到这种建议要警觉，升级命令一定要带 @openai/ 前缀。
锁定版本
生产环境或团队协作场景，建议锁版本：
codex --version # 假设当前是 0.62.1
npm install -g @openai/[email protected]
这样所有人跑的 codex 行为一致。新版本出来先在一个人机器上试，没问题再让团队跟进。
回滚
新版本如果带 regression，直接降回去：
# 看历史版本
npm view @openai/codex versions --json
# 装指定版本
npm install -g @openai/[email protected]
Homebrew 的 cask 不太支持精确版本回滚，要回到旧版本得手动下载历史 release 包。这也是我推荐 npm 路径的一个原因：版本管理粒度更细。
配置文件迁移
升级一般不动 ~/.codex/config.toml，但偶尔大版本会引入 schema 变化。升级前备份一下：
cp ~/.codex/config.toml ~/.codex/config.toml.bak.$(date +%Y%m%d)
跑新版第一次会自动迁移，迁移失败的话拿备份还原。
完整 setup 脚本：一台干净 Intel Mac 从零到能跑
如果你拿到一台干净 Intel Mac，要从零搭起 Codex 开发环境，下面这个脚本能跑通：
#!/usr/bin/env bash
set -e
# 1. 装 Homebrew（如果没装）
if ! command -v brew >/dev/null 2>&1; then
/bin/bash -c "$(curl -fsSL \
https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/usr/local/bin/brew shellenv)"
fi
# 2. 装 Node 22 LTS
brew install node@22
brew link --overwrite --force node@22
# 3. 改 npm 全局 prefix 到用户目录（避免 sudo）
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc
# 4. 装 Codex CLI
export PATH="$HOME/.npm-global/bin:$PATH"
npm install -g @openai/codex
# 5. 验证
codex --version
# 6. 首次登录（会弹浏览器）
codex login
跑完之后 codex 命令应该可用。第一次跑会触发 ChatGPT OAuth 登录，注意账号必须是 Plus / Pro / Business / Edu / Enterprise 任一档，免费 ChatGPT 账号没有 Codex 权限。
如果你不用 Homebrew，把第 1-2 步换成去 nodejs.org 下 Node 22 LTS 的 .pkg 装即可。后面 3-6 步通用。
Git 配置不要忘
Codex 会自动调 git 做 commit。如果你机器上 git 没配 user.name / user.email，commit 会失败：
git config --global user.name "你的名字"
git config --global user.email "你@example.com"
这个坑很多人在「跑 codex 让它帮我 commit」时第一次撞上。
真想跑 Desktop 版：看看这个民间 fork
GitHub 上有个项目叫 xmg2024/codex-intel-mac，专门 patch 让 Codex Desktop 在 Intel Mac 上跑起来。要自己 clone + 编译，不是开箱即用，风险自负。它修了什么：
- backdrop-filter blur on Intel UHD GPU：原版用了 CSS backdrop-filter blur 效果，Intel 集成显卡的 GPU 合成器扛不住，整片界面渲染成白块。patch 直接禁掉 blur。
- better-sqlite3 编译失败：依赖里有
better-sqlite3这个 native module，标准npm install会调 Apple Clang 编译 C++20 代码，但 Intel Mac 上的 Clang 版本通常不带 C++20 支持。patch 改成用预编译 x64 binary 直接替换。 - 从 Finder 启动 EPIPE 崩溃：Electron 默认会 attach console，如果 stdout 不是 TTY（双击启动就是这情况）就抛 EPIPE。patch 在启动脚本里加
ELECTRON_NO_ATTACH_CONSOLE=1。 - 对话自动折叠：UX 上的小坑，原版会自动折叠已完成的回合，patch 改成默认展开。
这四个 bug 单独看都很小，凑在一起就是「Intel Mac 上 OpenAI 完全没测过」的明证。
我自己的判断：不建议绝大多数人走这条路。要自己编译 + 替换 native module + patch CSS，每次官方更新都得重打一遍 patch。除非你有强烈的 GUI 偏好且接受不了 CLI，否则成本不划算。等 OpenAI 官方放 x86_64 build 更实际。
安全沙箱：Codex 跑起来之后
装上是第一步，让它能安全地跑代码是第二步。
Codex 本质上是个能在你本地执行命令、改文件、调 git 的 agent。它会犯错，会被 prompt injection 攻击，会在某些极端情况下做出灾难性操作。前阵子有个 AI agent 把服务器内核搞崩的真实案例，根因就是 agent 拿了 root 权限做了不该做的 sudo 操作。
Intel Mac 上跑 Codex 的最小安全实践：
- 专门建一个工作账号，不要用 admin 账号跑 codex。
- 项目目录隔离，每个 codex session 切到目标 repo 根目录跑，避免它误改其他项目。
- 关键操作保留 confirmation：
~/.codex/config.toml里别把auto_approve开成all，至少保留shell和git_push需要人工确认。 - 重要 repo 必须有 dirty state 检查：跑 codex 前
git status干净，跑完git diff审一遍再 commit。
更激进的方案是把 codex 跑在 VM 里。虚拟机隔离加 Git 双向同步的方案把这套搭法详细讲了。Intel Mac 跑 VM 比 Apple Silicon 容易很多（x86 客户机不需要翻译），算是 Intel Mac 用户的一个隐藏优势。
该不该为 Codex 换 Apple Silicon
Codex CLI 既然在 Intel 上跑得好，换不换机器就变成了一个独立问题。我的判断：短期不必为 Codex 换。
理由分三层：
- Codex CLI 在 Intel 上性能没短板。 上一节讲过，本地 CPU 不是瓶颈。除非你同时在跑别的吃 CPU 的本地工具（比如本地 LLM 推理、视频转码），单纯跑 Codex CLI 性能不构成换机理由。
- Desktop App 缺位不是「不能用」，是「不必用」。 你能用 CLI 完成所有 Codex 工作流，Desktop 只是另一种皮肤。Claude Desktop 的编辑器交互槽点实际上是个行业级问题，CLI 反而更能贴近你已有的开发流。
- AI 编程工具迭代太快，硬件投资周期对不上。 现在花两万换 M4 Pro，半年后 M5 又出来。Intel Mac 至少能撑到 2027 年，那时候硬件市场会更清晰。
什么情况下值得换：
- 你机器是 2017-2018 年的，电池或 SSD 已经接近寿命终点
- 你重度依赖某些只发 arm64 build 的工具（Codex Desktop 是其中一个，但少数）
- 你机器 RAM ≤ 16GB 且经常吃满
如果都不符合，Intel Mac 配 Codex CLI 至少能再战 18 个月。
Apple Silicon 用户也该看这一节
为什么 Apple Silicon 也要懂 Intel 这条线？
团队混装。 你 leader 用 Apple Silicon，你用 Intel，新来的实习生又是 Apple Silicon。如果 onboarding 文档只写「brew install --cask codex 即可」，三种机器各自踩各自的坑。
写文档时要分两条路：
- Apple Silicon：默认走 brew，path 在
/opt/homebrew/bin。 - Intel：默认走 brew，path 在
/usr/local/bin。
shell 配置也要分：
if [[ "$(uname -m)" == "arm64" ]]; then
export PATH="/opt/homebrew/bin:$PATH"
else
export PATH="/usr/local/bin:$PATH"
fi
放 ~/.zshrc 顶部。跨机器同步 dotfiles 时这一段必须有，否则 Intel Mac 用户根本找不到 brew 装的东西。
另一个常被忽略的点：arm64 binary 不能在 Intel 跑，反过来 x86_64 binary 在 Apple Silicon 上要 Rosetta 翻译。如果你直接复制队友 ~/.npm-global/ 目录过来，里面的 native module 大概率跑不起来。
CLI 之外，Intel Mac 还能用什么 AI 编程工具
如果 Codex CLI 你试下来不顺手，Intel Mac 用户还有几条退路：
- Claude Code：Anthropic 的 CLI，对 Intel Mac 支持比 Codex Desktop 好很多。有篇文章讲了 Claude Code 的长程上下文压缩机制，能感受到这边在工程上投入更深。ccvault 这种本地对话档案工具也是 Claude Code 生态产物，Intel Mac 都能跑。
- Cursor / VS Code with Copilot：纯 IDE 路线。VS Code 最近开了 BYOK 自定义模型 API，对 Intel Mac 友好度跟 Apple Silicon 没差别。
- Cline / Roo Code：开源 IDE agent，VSCode 插件形式，本地跑，不挑 CPU 架构。
- 国产替代：DeepSeek + GLM 混合调用这条路很多人在跑，GLM 编码能力和 Claude Opus 的对比也有不少实测数据。
需要注意 Claude Desktop 在代码编辑体验上不如竞品的反馈，所以选「Desktop App 还是 CLI」这件事 Anthropic 这边的答案也偏 CLI。整个行业的工程师工具流，目前是往 CLI 收。
Intel Mac 用户尤其要顺着这个趋势走——CLI 跨架构兼容性永远比 GUI 好，少操心一类 bug。
收束
回到 GSC 那个搜索词：「codex mac intel 版本」。
如果你是搜这个词进来的，最简的行动是：
brew install --cask codex
codex
如果 brew 没装，去 GitHub Release 拉 codex-x86_64-apple-darwin.tar.gz。
不需要等「Intel 版」，不需要 Rosetta，不需要换机器。CLI 已经是一等公民。
唯一卡住你的可能是 Node 22、PATH、OAuth 这三件事——它们跟 Intel 没关系，跟你机器多年沉淀的环境有关系。
至于 Desktop App，给自己定个止损线：等官方 x86_64 build 之前不投入。
