›_ Codex Issues
Codex Issues / #36698

Documented source build fails on macOS arm64: sandboxed V8 asset returns 404 and `codex-code-mode-host` is not built

Open 💬 6 comments Opened Aug 3, 2026 by noscripter

Issue body

What version of Codex CLI is running?

Source checkout of main at bb5054fe47abe73ecbbd454751066a28c89f4bb9 (codex-cli 0.0.0).

What subscription do you have?

N/A — this is a source-build failure before any API request or model invocation.

Which model were you using?

N/A.

What platform is your computer?

Darwin 25.6.0 arm64 arm
macOS 26.6 (25G72)
rustc 1.95.0 (59807616e 2026-04-14)
cargo 1.95.0 (f2d3ce0bd 2026-03-21)
toolchain: 1.95.0-aarch64-apple-darwin (repository override)

What terminal emulator and version are you using?

Not relevant; this reproduces during a non-interactive Cargo build.

Codex doctor report

Not available before applying the workaround because the documented source build does not produce a runnable local package.

What issue are you seeing?

The documented source-build flow in docs/install.md says to run:

cd codex/codex-rs
cargo build
cargo run --bin codex -- "explain this codebase to me"

This no longer works on a clean Apple Silicon checkout of current main.

There are two connected failures:

  1. Building only codex-cli produces target/debug/codex, but not the now-required sibling executable target/debug/codex-code-mode-host. Running the CLI then reports:

/path/to/codex/codex-rs/target/debug/codex-code-mode-host: No such file or directory

  1. Building the host explicitly fails while compiling v8 v150.4.0:

error: failed to run custom build command for v8 v150.4.0

static lib URL: https://github.com/denoland/rusty_v8/releases/download/v150.4.0/librusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.a.gz
HTTP Error 404: Not Found

Failed to download V8 prebuilt archive from
https://github.com/denoland/rusty_v8/releases/download/v150.4.0/librusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.a.gz

The failing filename is the sandbox-enabled ptrcomp_sandbox_release variant selected by v8_enable_sandbox. The Codex rusty-v8-v150.4.0 release contains the corresponding OpenAI-built archive and binding, and .github/actions/setup-rusty-v8/action.yml already downloads them and supplies:

RUSTY_V8_ARCHIVE
RUSTY_V8_SRC_BINDING_PATH

However, the documented direct Cargo/Just development path does not perform this setup. The repository's package builder contains similar download-and-verification logic, but it is not used by cargo build, just codex, or the source-build instructions.

This is related to, but different from, #31906. That issue concerns a Homebrew package missing the sidecar. This report concerns a clean build from source and the sandboxed V8 dependency setup.

The likely regression window is the combination of:

  • 97576b1794 — run code mode exclusively through the standalone host; and
  • 2e32d95894 — enable sandboxed V8 for code mode.

What steps can reproduce the bug?

Starting from a clean checkout:

git clone https://github.com/openai/codex.git
cd codex/codex-rs

The previously sufficient command builds the CLI but not its required host.

cargo build -p codex-cli --bin codex
./target/debug/codex

Attempt to build the missing host.

cargo build -p codex-code-mode-host --bin codex-code-mode-host

The last command fails on the Deno rusty_v8 404 shown above. Running the documented plain cargo build also reaches the same V8 failure.

What is the expected behavior?

The documented build-from-source command should produce a runnable local Codex installation from a clean checkout.

If codex-code-mode-host is mandatory, the supported local build command should:

  • build both codex and codex-code-mode-host;
  • place them where runtime discovery expects them;
  • obtain and checksum-verify the correct sandbox-enabled V8 archive and Rust binding automatically; and
  • avoid requiring contributors to discover CI-only environment variables.

Suggested fix

Preferred approach:

  1. Extract/reuse the verified V8 artifact setup already implemented by scripts/codex_package and .github/actions/setup-rusty-v8 as a first-class local developer helper.
  2. Add a supported just build recipe that runs that helper and then performs one grouped Cargo build for:

cargo build \
-p codex-cli --bin codex \
-p codex-code-mode-host --bin codex-code-mode-host

  1. Make just codex ensure the host has been built with the same V8 configuration before launching the CLI.
  2. Update docs/install.md to use this supported command instead of raw cargo build / cargo run --bin codex.
  3. Add a clean-checkout macOS arm64 CI smoke test that executes the documented source-build command and verifies both sibling binaries exist and start.

At minimum, the documentation should explain the two required binaries and show how to download and verify the Codex-hosted V8 pair before setting RUSTY_V8_ARCHIVE and RUSTY_V8_SRC_BINDING_PATH.

Confirmed workaround

Downloading the three assets below from the rusty-v8-v150.4.0 Codex release, verifying the supplied checksum file, and exporting the two paths makes the grouped build succeed:

librusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.a.gz
src_binding_ptrcomp_sandbox_release_aarch64-apple-darwin.rs
rusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.sha256

export RUSTY_V8_ARCHIVE=/path/to/librusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.a.gz
export RUSTY_V8_SRC_BINDING_PATH=/path/to/src_binding_ptrcomp_sandbox_release_aarch64-apple-darwin.rs

cargo build \
-p codex-cli --bin codex \
-p codex-code-mode-host --bin codex-code-mode-host

./target/debug/codex

With those overrides, both arm64 Mach-O binaries build successfully and the CLI resolves the host beside itself.

View original on GitHub ↗

6 Comments

dimfeld · 20 days ago

Just tried the equivalent workaround on Linux x86_64 and confirmed it works there too. I agree it would be good to either have this documented or otherwise handled in the build toolchain.

15230745073 · 18 days ago

Confirming the same failure on Windows x86_64 with rust-v0.147.0 (be6e8eac02) — this is not macOS-specific.

codex-code-mode-runtime enables the sandboxed V8 build (codex-rs/code-mode-runtime/Cargo.toml: v8 = { workspace = true, features = ["v8_enable_sandbox"] }), so the v8 crate's build script (rusty_v8 150.4.0 per Cargo.lock) requests:

rusty_v8_ptrcomp_sandbox_release_x86_64-pc-windows-msvc.lib.gz   → HTTP 404

rusty_v8 has never published a ptrcomp_sandbox variant for Windows. The complete v150.4.0 Windows asset list is:

  • rusty_v8_release_{x86_64,aarch64}-pc-windows-msvc.lib.gz
  • rusty_v8_simdutf_release_{x86_64,aarch64}-pc-windows-msvc.lib.gz

(verified today: the plain-variant URL answers 200, the ptrcomp_sandbox one 404).

Consequence: any plain cargo build / cargo test across the workspace is broken on Windows too, unless you take the multi-hour V8_FROM_SOURCE route. Workaround we use to run the rest of the test suite:

cargo nextest run --no-fail-fast --workspace \
  --exclude codex-code-mode-runtime --exclude codex-code-mode-host

cargo run --bin codex and the bazel release path (//codex-rs/cli:release_binaries) are unaffected since they don't pull in code-mode-runtime.

dimfeld · 18 days ago
unless you take the multi-hour V8_FROM_SOURCE route

No just use the workaround in the first post. Openai has their own rusty_v8 fork that contains the needed precompiled files.

yxl-lab · 17 days ago

Independent reproduction on another macOS version and current main:

Environment

  • macOS 15.5 (24F74)
  • Apple Silicon / arm64
  • rustc 1.95.0 (59807616e 2026-04-14)
  • cargo 1.95.0 (f2d3ce0bd 2026-03-21)
  • clean checkout of main at 8cabf5a6cf103cebe338d46346e43e3201e64f41

With no V8 overrides, the documented command:

cd codex-rs
cargo build

still fails while compiling v8 v150.4.0, attempting to download:

https://github.com/denoland/rusty_v8/releases/download/v150.4.0/librusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.a.gz

and receiving HTTP Error 404: Not Found.

I then downloaded these three assets from the Codex rusty-v8-v150.4.0 release:

librusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.a.gz
src_binding_ptrcomp_sandbox_release_aarch64-apple-darwin.rs
rusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.sha256

shasum -a 256 -c rusty_v8_ptrcomp_sandbox_release_aarch64-apple-darwin.sha256 reported OK for both the archive and binding. After setting RUSTY_V8_ARCHIVE and RUSTY_V8_SRC_BINDING_PATH to those verified files:

  • the grouped codex-cli + codex-code-mode-host build succeeded;
  • a subsequent full-workspace cargo build succeeded;
  • both outputs are arm64 Mach-O binaries;
  • target/debug/codex --version exits 0 and prints codex-cli 0.0.0;
  • target/debug/codex-code-mode-host --help exits 0;
  • target/debug/codex features list exits 0 and reports code_mode_host stable true.

This confirms the failure is still present on current main and is not specific to macOS 26. In this environment, supplying the Codex-hosted sandboxed V8 archive and binding was the only additional step needed to make the complete source build succeed.

yxl-lab · 17 days ago

I traced the current local, CI, and package build paths. The smallest fix appears to be an integration change rather than a new V8 downloader.

Root cause

  • docs/install.md and the root justfile use raw cargo build / cargo run --bin codex, so neither path prepares the Codex-built V8 artifacts.
  • codex-code-mode-runtime enables v8_enable_sandbox, which also enables pointer compression. Without overrides, the upstream v8 build script constructs the ptrcomp_sandbox_release filename under the Deno release URL, where that asset does not exist.
  • Both .github/actions/setup-rusty-v8/action.yml and scripts/codex_package/v8.py already resolve the exact v8 version from Cargo.lock, download the matching openai/codex release pair, verify the two checksums, and provide RUSTY_V8_ARCHIVE plus RUSTY_V8_SRC_BINDING_PATH.
  • cargo run --bin codex does not build the sibling codex-code-mode-host binary. For a normal Cargo launch, InstallContext resolves the host beside the running Codex executable, so both binaries need to be produced in the same target/profile directory.

Proposed smallest reviewable scope

If this direction matches the maintainers' intent, I would propose:

  1. Add a focused local-development build entry point that reuses scripts/codex_package/v8.py::resolve_codex_v8_cargo_env instead of duplicating download/checksum logic.
  2. Have it run one grouped Cargo build for:

``sh
cargo build \
-p codex-cli --bin codex \
-p codex-code-mode-host --bin codex-code-mode-host
``

  1. Expose that path through a supported just build recipe, and either make just codex use the same preparation/build path or document a separate launch command, depending on the preferred developer UX.
  2. Update the source-build section of docs/install.md to use the supported recipe rather than raw Cargo commands.
  3. Add focused tests for version resolution, paired environment overrides, checksum/cache behavior, and grouped command construction. A clean macOS arm64 smoke check could additionally verify that both sibling binaries are produced and start successfully if that CI cost is acceptable.

I would keep this separate from the full package builder: that builder also assembles package layout/resources and defaults to release-oriented targets, while the developer path should build for the active native Cargo target and preserve normal local iteration behavior.

I have not opened a PR because CONTRIBUTING.md states that external code contributions require an explicit invitation. Would the maintainers be willing to confirm the preferred local entry point and, if the scope above aligns, invite me to implement it?

LogCreative · 4 days ago
Openai has their own rusty_v8 fork that contains the needed precompiled files.

Just get the release from rusty-v8-release pipeline: https://github.com/openai/codex/actions/runs/30401869566 or https://github.com/openai/codex/releases/tag/rusty-v8-v150.4.0
set up RUSTY_V8_ARCHIVE and RUSTY_V8_SRC_BINDING_PATH
and it will work, including Windows platform.