Codex 内嵌的 V8 打了 152.2.0 的标签，代码里却还锁着 150.4.0

lipengfei634626165@163.com (lpflpf) — Thu, 17 Sep 2026 09:00:00 +0800

9 月 16 日 12:58:44Z，openai/codex 打了一个标签：rusty-v8-v152.2.0。42 个产物，release 说明栏是空的。

而两天前，也就是 9 月 15 日，这个仓库合并了一个 commit（#45760），标题是"Disable V8 optimization paths affected by array sort bugs"。它干的是一件事：在 code-mode 运行时初始化时，把 Maglev、Turbolev 和 TurboFan 的数组内建内联全部关掉。

把这两件事按顺序读一遍，你会发现一个比"又发版了"有意思得多的信号：产物已经走到 152.2.0，而仓库主线还锁在 150.4.0。这个时差就是本文要拆的东西。

先说清楚边界：官方没有就 152.2.0 发布任何说明，本文不讨论这次升级有什么性能收益——仓库里查不到，我不猜。所有结论都能在下面给出的一手链接里逐条核对。

先纠正一个我刚踩过的坑：152.2.0 不在 main 上

写这篇之前最容易犯的错，是看到 9 月 16 日的新标签，就顺手写下"Cargo.toml 里 v8 = "=152.2.0""。

不对。

截至 2026-09-17 抓取的 main 分支，codex-rs/Cargo.toml 第 524 行写的是：

`1`	`v8 = "=150.4.0"`

Cargo.lock 第 16565–16568 行坐实了这一点：name = "v8"、version = "150.4.0"、checksum 42a978ff…3a49。third_party/v8/README.md 里的那张表也还停在旧值：

Current pinned versions:

Rust crate: v8 = =150.4.0

Embedded upstream V8 source for Bazel-produced release builds: 15.0.245.2

所以打了一个 tag ≠ 主线换了版本。仓库里的 third_party/v8/README.md 甚至把升版流程写成了六步，第 1 步就是"改 crate 版本并刷新 Cargo.lock"；而 9-16 那个 tag 对应的是这套流程的产物发布环节。CI 里还专门有个 v8-canary.yml，在正式升版前跑金丝雀。一条变更要走过"打标签产出 42 个归档 → 改 Cargo.toml/lock → 改 MODULE.bazel → 金丝雀验证"好几道门，任何一道没走完，主线就不会动。

这是本文第一条可以直接搬走的判断：判断一个内嵌引擎的升级"是否真的生效"，看 Cargo.toml 和 Cargo.lock，不要看 release 列表。

旁证在产物那一侧。这个 tag 的 42 个产物明显分成两族：librusty_v8_release_<target>.a.gz（6 个）和 librusty_v8_ptrcomp_sandbox_release_<target>.a.gz（24 个，Windows 上是 .lib.gz），两族都配了 src_binding_*.rs 和 .sha256。为什么必须两族并存，第四节会算这笔账。

那个真正值得看的 commit，说的是"排序会写坏数组"

回到 9 月 15 日。commit aaa2cabfb（PR #45760，作者 Kevin Liu）的正文是这么写的：

The pinned V8 can inline Array.prototype.sort with incompatible element kinds when a comparator mutates the array, allowing an object to be stored in an integer-elements array.

Disable Maglev, Turbolev, and TurboFan array builtin inlining during code-mode runtime initialization until the V8 artifacts include the upstream fix.

翻成人话：我这版 V8 在比较函数自己改了数组的情况下，会用一个类型不对的元素把整数数组写坏。在我们的产物拿到上游修复之前，先把相关的优化通道关掉。

落地在 codex-rs/code-mode-runtime/src/v8_init.rs 里，就是这一行：

`1`	`v8::V8::set_flags_from_string("--no-maglev --no-turbolev --no-turbo-inline-array-builtins");`

配套加了一个回归测试 codex-rs/code-mode-runtime/tests/array_sort.rs：它故意请求顶层优化和 Maglev 优化，然后在比较函数里 values.fill(0) 把数组类型换掉，最后断言"排序没有把对象塞进整数元素数组"，同时确认普通数字排序 [3,1,2].sort((a,b)=>a-b) 仍然返回 [1,2,3]。测试注释里那句话很直白：“Request Turbolev so initialization must also disable its Maglev frontend.”——它就是要确保这两个前端真的被关掉了。

这和 Array.prototype.sort 的一个历史漏洞方向一致。NVD 上的 CVE-2026-85046 描述是"V8 中的类型混淆，Chrome 152.0.7977.82 之前，攻击者可用一个构造的 HTML 页面在沙箱内执行任意代码"，CVSS 3.1 由 CISA-ADP 给出 8.8（HIGH），向量 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H，CWE-843。它同时在 CISA 的 Known Exploited Vulnerabilities 目录里，入库日期 2026-09-04，要求 2026-09-18 前完成缓解。

但这里必须把话说准，这是初稿最容易写错的地方：

仓库里的代码没有点名这个 CVE。 没有 CVE-2026-85046 这个字符串，也没有名为 v8_array_sort_elements_kind.patch 的补丁文件（patches/ 目录下只有 v8_module_deps.patch、v8_bazel_rules.patch、v8_source_portability.patch 等常规移植补丁）。commit 的措辞是"array sort bugs"，注释里给的是 v8 上游的修复 commit 链接 e0562d87，而 NVD 页面上 CVE-2026-85046 恰好也引用了同一个 commit。

所以正确的写法是：Codex 在关掉这些优化通道的同一天前后，V8 上游有一个被 CISA 列入已知利用目录的排序类型混淆漏洞在修，两者高度吻合；但仓库从未把它标注成 CVE-2026-85046。把引用链接放在一起是事实，说"他们就是为这个 CVE 打的补丁"是推测。

而且注意版本算术：本仓库现在锁的 crate 150.4.0 对应上游 V8 15.0.245.2，NVD 列的受影响范围是 V8 < 15.3.48——也就是说这个基座在修复范围之外，仓库里的降级标志和它自洽。顺着 rusty_v8 的版本规则（crate 大版本跟 Chrome 大版本走，152.2.0 对应 15.2.*，rusty_v8 README 首页标的 V8 版本就是 15.2.124.1）也能推出来：光换成 152.2.0 这一档，仍然没跨过 15.3.48 这条线。 这是"升个版本号就好了"这个直觉最容易翻车的地方。

至于那三个 --no- 开关本身，它是运行时的临时规避，不是补丁：仓库没有回填任何 V8 C++ 源码改动。注释里"until our V8 artifacts include the upstream fix"已经写明了它的保质期。等产物换代，这三行就该被删掉——所以你读到时请以你自己看到的 main 为准。

一个等号、三个数字、两套构建系统

现在回到那个"为什么一条变更要分好几步"的问题。答案在依赖声明本身。

codex-rs/Cargo.toml 第 524 行那个 =150.4.0，前面是等号。不是 ^，不是 ~，是精确到补丁位的锁定。整个工作区里，真正启用 V8 的只有 code-mode-runtime 一个 crate：

`1`	`v8 = { workspace = true, features = ["v8_enable_sandbox"] }`

一个做代码模式的运行时，把 JS 引擎精确锁死，还专门打开沙箱特性——这三条摆在一起说明 V8 在这里的身份不是"依赖"，而是"构建产物"。差别很大：普通依赖你写 ^，上游修 bug 你自动拿到；构建产物你必须自己产、自己发、自己验，pin 死意味着升级节奏由你自己排。

然后是那个最容易被忽略的事实：这里的 V8 有两个版本号。 crate 版本 150.4.0，内嵌的上游 V8 源码版本 15.0.245.2。这两个数不是一回事——rusty_v8 的大版本跟着 Chrome 的发布节奏走（README 原话：new major version every 4 weeks），而真正被编进二进制的 C++ 源码是那一版 V8 标号。改一个数不改另一个，链接期就出问题。

为什么会这么脆？因为同时存在两条构建路径，而它们的产物不是一回事：

本地 Cargo 构建默认走上游 denoland 预编译的 rusty_v8 归档。这是 rusty_v8 的默认行为——README 写得很清楚：cargo build 会从 GitHub 下载静态库，要改成源码编译得设 V8_FROM_SOURCE=1。这条路最省事，但它是上游原味的。

CI 和发布构建把 RUSTY_V8_ARCHIVE / RUSTY_V8_SRC_BINDING_PATH 两个环境变量指到 openai/codex 自己发布的产物上。README 里那句警告是硬规则：

Do not mix artifacts across crate versions. The archive and binding must match the exact resolved v8 crate version in codex-rs/Cargo.lock.

为什么绑定文件也要管？src_binding_*.rs 是从那一版 V8 的 C++ 头文件生成的 FFI 声明。库和声明来自不同版本，链接期就会以一堆不知所云的符号错误收场——这类错误对不熟的人极难查，所以它值得被写成一条禁令。

还有一层更现实的成本，README 自己承认了：

MSVC is not part of the Bazel-produced matrix yet. The repository’s current hermetic Windows C++ platform is windows-gnullvm/x86_64-w64-windows-gnu, so it cannot truthfully reproduce upstream’s *-pc-windows-msvc archives until we add a real MSVC-targeting C++ toolchain to the Bazel graph.

翻译一下：他们的 Bazel 能自产 Darwin / Linux GNU / Linux musl / Windows GNU 的产物，但 MSVC 那一档造不出来，只能回到上游 rusty_v8 源码单独产一份，而那份没有沙箱特性。所以 README 里也直说 Windows MSVC 仍然用上游的非沙箱预编译件。

再配上 MODULE.bazel 第 771 行那套：bazel_dep(name = "v8", version = "15.0.245.2") 加一个 archive_override，直接指向 v8/v8 仓库的 15.0.245.2.tar.gz 并挂上三个移植补丁——Bazel 这条路是"拉上游源码 + 自己打移植补丁 + 自己编"。

“内嵌 V8"听起来是把一个引擎装进二进制，实际是把 Chrome 的构建矩阵装进你的 CI。 两套构建系统、一条自建发布流水线、一条金丝雀流水线、一个要自己维护的校验和清单，外加一个暂时补不上的平台缺口——这是小团队基本扛不动的账。

1TB 是虚拟地址，沙箱管的是内存不是 API

最后一节说清楚最容易被误读的一点，因为整篇的主张都压在它身上：v8_enable_sandbox 不是“让 JS 不能干坏事"的沙箱。

rusty_v8 README 的定义是这样的：

v8_enable_sandbox: Enables v8 sandbox mode. The v8 sandbox enables improved safety while executing potentially malicious JavaScript code through the use of memory cages. Note that the v8 sandbox will allocate ~1TB of virtual memory (although this should not be an issue as many operating systems allow 128-256TB of virtual memory per process). Creating isolates with the sandbox enabled comes with API limitations and may have increased overhead. Note that enabling the V8 sandbox also implies pointer compression to be enabled as well.

四个要点，一个都不能省：

它是内存笼子，管的是内存安全。 V8 官方 sandbox 的设计目标是限制 V8 自身内存破坏漏洞的影响范围——把裸指针换成"相对沙箱基址的偏移"或"沙箱外指针表的索引”，让引擎一旦被攻破，也只能在进程虚拟地址空间的一个子集里动。它不负责限制你能调哪些 API。

那"1TB"是虚拟地址预留，不是内存占用。 README 自己补了一句"很多操作系统允许每进程 128–256TB 虚拟内存”。写成"吃 1TB 内存"是硬错误——物理内存该多少还是多少。

它是实验性特性，而且隐含打开指针压缩。 README 明确把这些 feature 归到"Experimental Features"，理由是"not as well tested and do not undergo any sort of CI related testing or prebuilt archives"——所以它们必须配合 V8_FROM_SOURCE=1 或自建归档使用。这也正是上一节那 42 个产物里"普通族"和"ptrcomp_sandbox 族"必须并存的原因：上游默认发布的预编译件里没有沙箱版，想要沙箱就得自己产。

它只在 64 位可用。 指针压缩加共享 cage 这套机制决定了这一点。

那"限制 JS 能干什么"谁来做？宿主自己做。Codex 的做法不神秘，code-mode-runtime/src/runtime/globals.rs 里就是两步：先删掉 console、Atomics、SharedArrayBuffer、WebAssembly 这些全局对象，再把受控接口装上去——tools、ALL_TOOLS，以及 text / image / audio / generatedImage / store / load / notify / yield_control / exit / setTimeout / clearTimeout 这些助手函数。模型写的 JS 调 tools.xxx()，那是一个绑到 Rust 侧的回调（runtime/callbacks.rs）。JS 世界里存在什么，完全由宿主说了算。

顺带把最常被混写的一层边界讲清：终端命令的执行走的是 OS 级沙箱（macOS Seatbelt、Linux Landlock、Windows 那套），仓库里对应 codex-linux-sandbox、windows-sandbox-rs 这些独立 crate，跟 V8 没有任何关系。V8 沙箱管的是"JS 通过引擎漏洞打到宿主进程内存"，OS 沙箱管的是"进程能碰哪些文件和网络"。Codex 是两层都做——不是二选一，是各管一段。

还有一处克制但很说明问题的设计。codex-rs/v8-poc/src/lib.rs 里有个函数直接绑定 v8__V8__IsSandboxEnabled() 符号，注释写明"rusty_v8 exposes this symbol for its own sandbox verification tests"：

#[must_use]
pub fn linked_v8_has_sandbox() -> bool {
    unsafe extern "C" {
        fn v8__V8__IsSandboxEnabled() -> bool;
    }
    unsafe { v8__V8__IsSandboxEnabled() }
}

他们不信构建配置，直接问链接进来的那个库：你到底带没带沙箱。 一个跑在别人二进制里的安全特性，值得这样验一次。

换不换，取决于你能不能接住 CVE 的回填节奏

回到你面前那个决策：Agent 要执行模型生成的代码，三条路怎么选。

进程外容器（Docker / E2B / Daytona）——隔离最彻底，代价是冷启动和运维，你得自己管生命周期、文件系统、网络和密钥策略。TanStack AI 的文档里就有一条 Daytona 驱动器，明确写着"your application remains responsible for sandbox lifecycle, filesystem, network, cleanup, and secret policy"。

QuickJS + WASM——把一个小引擎整体放到边界后面，是现在很主流的做法。LangChain 那篇讲 deep agents 的文章把机制讲得很清楚：因为 QuickJS 跑在 WASM 里，“we serialize the interpreter’s linear memory to LangGraph state, and on resume the harness restores the snapshot and feeds the result back into the call that was waiting on it”——能把一个跑到一半的程序整体冻结、存进状态、几天后恢复，这是内嵌 V8 那类"贴着宿主进程"的方案很难做的动作。代价是性能，TanStack 的文档对这一点很诚实：

Performance note: QuickJS interprets JavaScript rather than JIT-compiling it, so compute-heavy scripts run slower than with the Node driver. For typical LLM-generated scripts that are mostly waiting on external tool calls, this difference is not significant.

这句是别人家产品的文档，只能说"解释器路线在多数场景够用"，不能当成我们对 Codex 的性能评价。

内嵌真 V8——你要的是真实 JS 语义（async/await、正则、Proxy、复杂对象）+ 贴近宿主 + 内存笼子，代价就是前两节那笔账。

判断依据可以压成五个自问：

一、模型生成的代码到底需要多少 JS 语义？ 只是顺序调几个工具，QuickJS/WASM 足够；要真的写异步编排、跑正则、用 Proxy，才轮到真 V8。

二、你的分发平台有几个？ musl、aarch64、Windows MSVC 全都要的话，任何一个没有现成的沙箱产物，就得你自己产——Codex 自己就还卡在 MSVC 这一步，而它们的 Bazel 矩阵已经是同级别里相当完整的那一档了。

三、你能跟上上游 V8 的安全修复节奏吗？ 跟不上就得像他们一样 pin 住，然后等 CVE 出现时评估自己受不受影响、要不要临时关掉几个优化通道。注意这条链上的每一环都是真实的运维动作：这次 --no-maglev --no-turbolev 是 9 月 15 日合的，而 CISA 要求相关单位 9 月 18 日前完成缓解——中间只隔三天。

四、你的 CI 里塞得下第二个构建系统吗？ cargo build 的默认行为是从 GitHub 下载预编译静态库，离线或受限网络环境会直接失败（仓库里就有一个已关闭的 issue #16105 叫"nix build error - rusty_v8 download issue"），于是你又多一个 RUSTY_V8_ARCHIVE 要维护。想省掉这一层就用 RUSTY_V8_MIRROR 建本地镜像缓存，代价是又多一份要同步的东西。

五、你的安全诉求是"隔离文件和网络"还是"隔离内存破坏"？ 前者是 OS 沙箱的事，后者才是 v8_enable_sandbox。

这件事明天可以怎么用

先给你三条能立刻跑的自查命令，用来确认你自己的 V8 依赖处在什么状态：

# 1. 你的 v8 crate 是精确 pin 还是区间依赖？
grep -n '^v8' Cargo.toml && grep -n -A3 '^name = "v8"' Cargo.lock

# 2. 链接进来的 V8 到底有没有开沙箱（rusty_v8 暴露了这个符号）
#    用法照抄 codex-rs/v8-poc/src/lib.rs：
#    unsafe extern "C" { fn v8__V8__IsSandboxEnabled() -> bool; }

# 3. 查有没有为了绕 bug/CVE 而加的运行期降级标志
grep -rn 'set_flags_from_string' src/

第三条是最有价值的。一个 --no-xxx 标志，通常就是一份没写进 changelog 的漏洞公告。 它告诉你这个项目当前正扛着什么、在等谁的修复——而且它比 release note 早得多，因为降级往往是"先上规避、再等换代"这个顺序。

第四条留给判断版本号的人，是本文踩过的坑：

1
2
3

# 4. 你的内嵌引擎有两个版本号，关联关系要写下来，别靠记忆
grep -rn 'v8' third_party/*/README.md 2>/dev/null   # crate 版本 → 上游源码版本
# 然后拿去比对漏洞库里那条"受影响范围"，确认你到底在不在里面

如果自查下来你确实走的是内嵌真 V8 这条路，还有两件事值得现在就做：一是给 V8_FROM_SOURCE / RUSTY_V8_ARCHIVE / RUSTY_V8_MIRROR 这类变量在 CI 里留一条离线可复现的路径，别让构建依赖一个随时可能拿不到的 GitHub Release；二是把"跟随上游安全修复"变成一个有人负责的日程，而不是等出了 CVE 才有人想起来仓库里还 pin 着一个引擎。

至于要不要现在就从 QuickJS/WASM 换成内嵌 V8——我的建议是不要因为"Codex 也这么干"就换。他们这么干的收益是拿到真实 JS 语义和进程内内存笼子，代价是养一条 V8 的构建发布链路、在漏洞出现时自己权衡要不要临时关掉优化通道，并且要同时维护"crate 版本"和"上游源码版本"两套数字。这个取舍对他们成立，对大部分 Agent 项目不成立。

内嵌 V8 买到的是沙箱能力和真实 JS 语义，不是运行时速度；买之前先看你到底需不需要它，以及接不接得住它的安全回填节奏。

参考与验证

核验日期 2026-09-17（CST）。以下逐条为本文引用的原始出处。

标签 rusty-v8-v152.2.0（GitHub API 实测：published 2026-09-16T12:58:44Z，release body 为 None，42 个产物 = 6 个 librusty_v8_release_* + 24 个 librusty_v8_ptrcomp_sandbox_release_* + 绑定/校验和文件；对照标签序列 146.4.0 / 147.4.0 / 149.2.0 / 150.4.0 / 152.2.0）：https://github.com/openai/codex/releases/tag/rusty-v8-v152.2.0
main 分支 codex-rs/Cargo.toml 第 524 行仍为 v8 = "=150.4.0"（本文关键纠正点），codex-rs/Cargo.lock 第 16565–16568 行 name = "v8" / version = "150.4.0" / checksum 42a978ff…3a49：https://github.com/openai/codex/blob/main/codex-rs/Cargo.toml
codex-rs/code-mode-runtime/Cargo.toml 第 26 行（工作区唯一启用 V8 的 crate，v8 = { workspace = true, features = ["v8_enable_sandbox"] }）：https://github.com/openai/codex/blob/main/codex-rs/code-mode-runtime/Cargo.toml
commit aaa2cabfb / PR #45760 “Disable V8 optimization paths affected by array sort bugs”（作者 Kevin Liu，2026-09-15T18:40:08Z；改动仅 v8_init.rs +5 -0 与新增 tests/array_sort.rs +84 -0）：https://github.com/openai/codex/commit/aaa2cabfb —— 完整 commit 正文可用 GitHub API 复核：https://api.github.com/repos/openai/codex/commits/aaa2cabfb
codex-rs/code-mode-runtime/src/v8_init.rs（第 49 行降级标志 --no-maglev --no-turbolev --no-turbo-inline-array-builtins 及其注释；V8JitMode::{Enabled, Disabled}，Disabled 走 --jitless；ICU 数据 set_common_data_77(deno_core_icudata::ICU_DATA)）：https://github.com/openai/codex/blob/main/codex-rs/code-mode-runtime/src/v8_init.rs
codex-rs/code-mode-runtime/tests/array_sort.rs（请求 --allow-natives-syntax --turbolev，比较函数内 values.fill(0) 后断言元素类型未被写坏，并确认 [3,1,2].sort() 仍返回 [1,2,3]）：https://github.com/openai/codex/blob/main/codex-rs/code-mode-runtime/tests/array_sort.rs
third_party/v8/README.md（pinned v8 = =150.4.0 / embedded upstream 15.0.245.2；“Do not mix artifacts across crate versions”；MSVC 不在 Bazel 矩阵内；升版六步流程；产物两族命名；windows-gnullvm 平台说明）：https://github.com/openai/codex/blob/main/third_party/v8/README.md
MODULE.bazel 第 771 行（bazel_dep(name = "v8", version = "15.0.245.2") 与 archive_override，urls 指向 v8/v8 的 15.0.245.2.tar.gz，patches 列表为 v8_module_deps.patch / v8_bazel_rules.patch / v8_source_portability.patch）：https://github.com/openai/codex/blob/main/MODULE.bazel —— 注意：patch 列表中没有、仓库内也不存在名为 v8_array_sort_elements_kind.patch 的文件，patches/ 目录可核：https://github.com/openai/codex/tree/main/patches
.github/workflows/rusty-v8-release.yml（tag rusty-v8-v* 触发的产物发布流水线）与 .github/workflows/v8-canary.yml（升版前金丝雀）：https://github.com/openai/codex/tree/main/.github/workflows
codex-rs/code-mode-runtime/src/runtime/globals.rs（删除 console / Atomics / SharedArrayBuffer / WebAssembly；注入 tools / ALL_TOOLS / text / image / audio / generatedImage / store / load / notify / yield_control / exit / setTimeout / clearTimeout）与 src/runtime/callbacks.rs（工具回调绑定到 Rust 侧）：https://github.com/openai/codex/blob/main/codex-rs/code-mode-runtime/src/runtime/globals.rs
codex-rs/v8-poc/src/lib.rs（linked_v8_has_sandbox() 绑定 v8__V8__IsSandboxEnabled()，注释说明该符号由 rusty_v8 为自身沙箱校验测试而暴露）：https://github.com/openai/codex/blob/main/codex-rs/v8-poc/src/lib.rs
CVE-2026-85046（NVD：V8 类型混淆，Chrome < 152.0.7977.82，CWE-843；CISA-ADP 给出 CVSS 3.1 8.8 HIGH，向量 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H；CPE 列 V8 < 15.3.48；同时在 CISA KEV 目录，入库 2026-09-04、要求 2026-09-18 前缓解；NVD 引用的补丁 commit 为 v8/v8 e0562d87）：https://nvd.nist.gov/vuln/detail/CVE-2026-85046
rusty_v8 README（实验性特性 v8_enable_sandbox 原文：memory cages、~1TB 虚拟内存、128–256TB 每进程上限、API 限制与额外开销、隐含指针压缩、需 V8_FROM_SOURCE=1 或自建归档；版本规则"major version aligns with Chrome’s major version…new major version every 4 weeks"；V8_FROM_SOURCE / RUSTY_V8_ARCHIVE / RUSTY_V8_MIRROR / RUSTY_V8_MIRROR_TAG 行为；首页标注 V8 Version 15.2.124.1）：https://github.com/denoland/rusty_v8 （访问日期 2026-09-17）
LangChain「How Deep Agents Run Untrusted Code Without a Sandbox」（QuickJS 跑在 WASM 内、把解释器线性内存序列化进 LangGraph 状态并在恢复时回灌）：https://www.langchain.com/blog/running-untrusted-agent-code-without-a-sandbox （访问日期 2026-09-17）
TanStack AI「Code Mode Isolate Drivers」（Daytona 驱动器与"sandbox lifecycle, filesystem, network, cleanup, and secret policy 由应用负责"；性能注记原文 “QuickJS interprets JavaScript rather than JIT-compiling it, so compute-heavy scripts run slower than with the Node driver. For typical LLM-generated scripts that are mostly waiting on external tool calls, this difference is not significant."）：https://tanstack.com/ai/latest/docs/code-mode/code-mode-isolates （访问日期 2026-09-17）
openai/codex issue #16105 “nix build error - rusty_v8 download issue”（已关闭，用于说明 cargo build 默认下载预编译静态库这一行为在受限网络下的失败面）：https://github.com/openai/codex/issues/16105

风险与时效说明：本文关于 Codex 的结论全部基于截至 2026-09-17 的 openai/codex main 分支可见的配置、源码与 GitHub API 数据。--no-maglev --no-turbolev --no-turbo-inline-array-builtins 是当前源码状态，属于针对所 pin 版本的临时规避，注释中已写明"until our V8 artifacts include the upstream fix”，等产物换代后应被移除，你读到时可能已经变了。rusty-v8-v152.2.0 标签的存在不代表主线已采用该版本，请以 Cargo.toml / Cargo.lock 现状为准。仓库内没有可引用的性能数据，本文不讨论版本升级的性能影响。

V8 on 搬砖程序员带你飞