Cargo builds still use prebuilt rusty_v8 archives by default. Only Bazel overrides RUSTY_V8_ARCHIVE/RUSTY_V8_SRC_BINDING_PATH in MODULE.bazel to select source-built local archives for its consumer builds.

Source-built Bazel V8 artifacts enable V8's in-process sandbox by default, and the Bazel v8 crate feature selection tracks those targets. A full consumer rollout still needs matching sandbox-enabled archives for every non-source-built target. Until that artifact migration lands, the rusty_v8 publishing workflows use --config=v8-release-compat to preserve the current non-sandboxed release artifact contract.

Current pinned versions:

Rust crate: v8 = =147.4.0
Embedded upstream V8 source for musl release builds: 14.7.173.20

When bumping the Rust crate version, keep the checked-in checksum manifest and MODULE.bazel in sync:

python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
python3 .github/scripts/rusty_v8_bazel.py check-module-bazel

The commands read third_party/v8/rusty_v8_<crate_version>.sha256 by default and validate every matching rusty_v8_<crate_version> http_file entry. CI runs the check command to block checksum drift.

The consumer-facing selectors are:

//third_party/v8:rusty_v8_archive_for_target
//third_party/v8:rusty_v8_binding_for_target

Current musl release assets are expected at the tag:

rusty-v8-v<crate_version>

with these raw asset names:

librusty_v8_release_<target>.a.gz
src_binding_release_<target>.rs

During the sandbox rollout, sandbox-enabled assets are published alongside those current assets on the same tag, with the Rust crate's sandbox feature suffix in their raw names:

librusty_v8_ptrcomp_sandbox_release_<target>.a.gz
src_binding_ptrcomp_sandbox_release_<target>.rs

The dedicated publishing workflow is .github/workflows/rusty-v8-release.yml. For GNU Linux, Darwin, and Windows MSVC, the workflow checks out the exact upstream denoland/rusty_v8 tag and uses its V8_FROM_SOURCE=true Cargo/GN build to produce sandbox-profile artifacts with the same archive shape upstream publishes. Musl remains an extra platform that upstream does not publish, so tagged runs still build the current musl release pairs with our Bazel producer:

//third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_musl
//third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_musl

The same run also builds the matching sandbox pair targets:

//third_party/v8:rusty_v8_sandbox_release_pair_x86_64_apple_darwin
//third_party/v8:rusty_v8_sandbox_release_pair_aarch64_apple_darwin
//third_party/v8:rusty_v8_sandbox_release_pair_x86_64_unknown_linux_gnu
//third_party/v8:rusty_v8_sandbox_release_pair_aarch64_unknown_linux_gnu
//third_party/v8:rusty_v8_sandbox_release_pair_x86_64_unknown_linux_musl
//third_party/v8:rusty_v8_sandbox_release_pair_aarch64_unknown_linux_musl
//third_party/v8:rusty_v8_sandbox_release_pair_x86_64_pc_windows_msvc
//third_party/v8:rusty_v8_sandbox_release_pair_aarch64_pc_windows_msvc

If a tagged run targets an existing GitHub release, publication amends only the sandbox-profile files and leaves the current release-profile assets unchanged. The upstream-shaped GNU, Darwin, and MSVC builds let GN fold custom libc++ into the final archive the same way rusty_v8 does for its own releases. Musl sandbox archives still merge the matching static libc++ and libc++abi runtime libraries after the Bazel build so Cargo consumers can link them with the v8 crate's default use_custom_libcxx feature.

Cargo musl builds use RUSTY_V8_ARCHIVE plus a downloaded RUSTY_V8_SRC_BINDING_PATH to point at those openai/codex release assets directly. We do not use RUSTY_V8_MIRROR for musl because the upstream v8 crate hardcodes a v<crate_version> tag layout, while our musl artifacts are published under rusty-v8-v<crate_version>.

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

README.md

rusty_v8 Consumer Artifacts

`rusty_v8` Consumer Artifacts