当你的公司电脑是Linux,家里电脑是Intel Mac,而OpenAI只给Apple Silicon发糖
一、故事的开始:一个悲伤的程序员
事情是这样的。
我,一个平平无奇的打工人,每天跟代码打交道。最近OpenAI出了个Codex桌面版,据说能直接在你电脑上跑AI辅助编程,牛逼哄哄。
我兴冲冲地打开官网,下载,双击——
![OpenAI官网:只提供macOS ARM64版本]
等一下。
我公司的电脑是Linux啊!
好吧,那我回家再装。到家打开我那台 Intel 芯片的老 Mac——
![OpenAI官网:还是只提供macOS ARM64版本]
OpenAI,你几个意思?
Apple Silicon 用户是人,我们 Intel 用户就不是人了吗?Linux 用户就连牲口都不如了吗?
二、等等,Intel Mac 其实有版本
就在我准备放弃的时候,我发现了一个惊天秘密:
OpenAI 其实给 Intel Mac 发版本!
只不过它不是通过官网下载,而是通过 Sparkle 更新通道偷偷摸摸地推送给已经安装了 ARM 版本的用户。
什么意思呢?打个比方:
ARM 版本是摆在超市货架上的商品,人人都能买。
Intel 版本是藏在仓库里的,只有已经买到 ARM 版本的人,才能通过"以旧换新"的方式拿到。
这合理吗?这不合理。
但我发现了一条线索 —— OpenAI 的 Sparkle appcast 文件里,竟然暴露了 Intel 版本的下载地址!
<enclosure url="https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-x64-26.616.32156.zip" ... />
这不就是明摆着告诉我:来呀,来下载我呀!
行,那我就不客气了。
三、下载完,然后呢?
下载下来解压,得到一个 Codex.app,双击——
"应用程序"Codex"已损坏,无法打开。你应该将它移到废纸篓。"
![经典苹果报错]
我懂了,因为我修改了 app.asar 里的代码(为了修一些东西,后面说),苹果的代码签名校验不通过了。
这时候我面临三个选择:
方案A: 花钱买 Apple Developer 账号($99/年),正经签名
方案B: ad-hoc 签名,每次右键→打开
方案C: 不签名,裸奔
故事到这里本来应该结束了,但我看了一眼我一个 Intel Mac 用户,为了用个 AI 编程工具,还得自掏腰包 99 刀?
凭什么。
既然 OpenAI 不给 Linux 和 Intel Mac 活路,那我自己来。
四:从逆向工程到自动化流水线
第一版:ARM 转 Intel 的异想天开
我的第一个想法很朴素:
把 ARM 版的 DMG 下载下来,把里面的 Codex Framework.framework 换成标准 Electron,不就全平台通吃了吗?
我吭哧吭哧写了个 pack-macos-x64.sh,解压、替换框架、复制资源,一套操作猛如虎——
打开一看:
No such binding was linked: electron_common_owl_features
哦豁。
原来 Codex Framework.framework 不是普通的 Electron,它是 OpenAI 定制的,里面有私有的 C++ 绑定。换成标准 Electron 就像给保时捷换了辆奥拓的发动机——壳子还是那个壳子,但跑不起来了。
第二版:那我不换了还不行吗
好吧,那我不换框架了。
既然 Intel 版本本来就存在(只是 OpenAI 藏着掖着),那我就直接从他们的 CDN 下载 Intel 版本,只修改 app.asar(前端 JS 包),其他一概不动。
这样:
- • ✅ 原始
Codex Framework.framework 保留(含有 electron_common_owl_features) - • ✅ 所有原生模块都是 Intel 架构的(本来就对)
听起来完美,但还有一个问题——
第三版:原生模块的诅咒
Intel 版本的 better-sqlite3 是 ARM 架构预编译的(别问为什么,问就是 OpenAI 打包时搞错了)。
所以我还得写个脚本,自动把 better-sqlite3 替换成 Intel 版本。
怎么替换?从 GitHub Releases 下载预编译包:
# 下载 Electron ABI 133 对应版本的 .node 文件
curl -fSLk "https://github.com/WiseLibs/better-sqlite3/releases/download/\
v12.9.0/better-sqlite3-v12.9.0-electron-v133-darwin-x64.tar.gz"
没错,.node 文件跟 Node.js 版本有严格的对应关系——ABI 不对,加载就报错。这就是我之前折腾了好久的 NODE_MODULE_VERSION 137 错误。
五:痛点二号——中文呢?
Intel 版本终于能跑了,但打开设置一看——语言选项里没有中文。
等等,ARM 版本明明有中文的啊?
查了一下,原来是 i18n 功能被 Statsig 云控开关给关了。Statsig 是个功能开关服务,OpenAI 可以通过它远程控制你的客户端功能。
它的代码大概是这样的:
const i18nEnabled = statsig.get("enable_i18n", false);
// 如果 enable_i18n 为 false,语言设置菜单就被隐藏了
而 Statsig 服务器给 Intel 版本的 enable_i18n 返回了 false。
那我直接把这个调用替换成 true 不就行了?
// 改前
const i18nEnabled = statsig.get("enable_i18n", false);
// 改后
const i18nEnabled = !0; // JavaScript 里的 true
这操作在游戏圈叫"破解",在我们这叫"逆向工程"
我把这个逻辑写成了补丁脚本:
python3 -c "
import re
# 匹配 X.get(\"enable_i18n\", ...) 替换为 !0
code = re.sub(
r\"[a-zA-Z_]\w*(?:\?\.|\.)get\(['\"]enable_i18n['\"][^)]*\)\",
'!0',
code
)
"
顺便还写了好几个补丁:
| | |
|---|
patch-i18n.sh | | webview/assets/*.js |
patch-devtools.sh | | .vite/build/main-*.js |
patch-updater.sh | | .vite/build/*.js |
patch-sunset.sh | | webview/assets/index-*.js |
patch-copyright.sh | | .vite/build/main-*.js |
六:痛点三号——每次更新都要手动搞?
现在问题来了:OpenAI 经常发新版本,我总不能每次出新版都手动下载、解压、补丁、签名、打包吧?
作为一个程序员,我最讨厌的事情就是重复劳动。
所以我搞了个 GitHub Actions 自动化流水线:
on:
schedule:
- cron: '0 */6 * * *' # 每6小时检查一次
workflow_dispatch: # 也支持手动触发
流程是这样婶儿的:
appcast-x64.xml(检测新版本)
│
┌────┴────┐
│ 有新版本 │ ← 没有新版本?拜拜,0 流量
└────┬────┘
│
┌────▼────┐
│ 下载补丁ASAR│ → 上传共享产物
└────┬────┘
│
┌────┴────┐──────┐
│ macOS构建 │ Linux构建 │ ← 并行执行,互不等待
└────┬────┘──────┘
│
┌────▼────┐
│ GitHub │
│ Release │
└─────────┘
这样每次 OpenAI 发布新版本,我的流水线会自动检测、下载、修补、打包、上传到 Releases。我只需要负责躺着。
而且它还支持手动指定版本号——万一哪天我想回滚到旧版本呢?
七:痛点四号——那 Linux 咋办?
我承认,Linux 版本目前还是个"半成品"。
Codex.app 的核心 AI 后端二进制(236MB 的 codex 文件)是 macOS 的 Mach-O 格式,Linux 跑不了。而且 OpenAI 也没有提供 Linux 版的二进制。
所以 Linux 版的现状是:
- • ✅ UI 能启动(因为前端是 JS,无视平台)
换句话说,Linux 用户目前只能看个启动画面。
不过话说回来,如果 OpenAI 哪天大发慈悲发布了 Linux 版的 codex 二进制,我们的打包流水线已经准备好了,直接下载替换就行。
八:签名那点事儿
前面说到,改了 app.asar 后苹果签名就失效了。
你可能会问:能不能不动签名?
答案是:不能。苹果的代码签名是对整个 app bundle 所有文件的哈希树,改了一个字节,整个签名就废了。
所以我的策略是:
- 1. ❌ 不保留原签名(已损坏,强行保留会导致"已损坏,移到废纸篓")
- 2. ❌ 不 ad-hoc 重签(会导致"Apple 无法验证"且没有"打开"按钮)
- 3. ✅ 移除签名 + 移除隔离属性(第一次会弹出"无法验证开发者",但有"打开"按钮,点一次以后就正常了)
参考项目也是这么做的。这不是 bug,是 feature——毕竟 $99/年的 Apple Developer 账号我是不会买的。
九:项目结构一览
最后,展示一下我的劳动成果:
Codex-Dmg-Trasnform/
├── scripts/
│ ├── pack-macos-x64.sh # macOS 打包脚本
│ ├── pack-linux-amd64.sh # Linux AMD64 打包
│ ├── pack-linux-arm64.sh # Linux ARM64 打包
│ ├── patches/ # ASAR 补丁合集
│ │ ├── patch-i18n.sh # 中文补丁
│ │ ├── patch-devtools.sh # 开发者工具补丁
│ │ ├── patch-updater.sh # 更新禁用补丁
│ │ └── patch-sunset.sh # 强制更新禁用补丁
│ ├── rebuild-native-modules.sh # 原生模块重建
│ └── update-integrity.sh # 签名哈希更新
├── .github/workflows/
│ └── download-and-patch.yml # 自动流水线
└── README.md
十:写在最后
这个项目从一开始的"我要在 Linux 上跑 Codex"的朴素愿望,变成了一个跨平台打包工具链。
虽然 Linux 版目前还是残废,但至少 Intel Mac 的用户可以愉快地用上中文版 Codex 了。
如果你也遇到同样的问题,欢迎来 GitHub 看看,点个 Star,或者提个 Issue。
最后的最后:
OpenAI 啊 OpenAI,你啥时候出个 Linux 版?我等得花儿都谢了。
P.S. 本篇文章所有操作均在合法范围内进行——软件是从官方 CDN 下载的,修改的是前端代码而非破解付费功能,仅供个人学习和使用。
P.P.S. 如果你在 Apple 工作,欢迎赞助我一个 Developer 账号($99),我就可以去掉那个烦人的"无法验证开发者"提示了。 😂