update-v8-version

Update Codex's pinned `v8` / `rusty_v8` versions, validate the release-candidate path, and investigate failed V8 canary or artifact builds. Use when asked to bump V8, update `rusty_v8` artifacts, prepare or validate a V8 release candidate, check `v8-canary`, or diagnose why a V8 version update no longer builds.

Jump to install

Repository: openai/codex
Last source activity: May 19, 2026 at 04:33
Detected SKILL.md language: English
Stars: 106,773
Forks: 16,224

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/openai/codex --skill update-v8-version

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer

2 files

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

plugin-creator

Create and scaffold plugin directories for Codex with a required `.codex-plugin/plugin.json`, optional plugin folders/files, valid manifest defaults, and personal-marketplace entries by default. Use when Codex needs to create a new personal plugin, add optional plugin structure, generate or update marketplace entries for plugin ordering and availability metadata, or update an existing local plugin during development with the CLI-driven cachebuster and reinstall flow.

2026-08-18

skill-creator

Create or update a Codex skill with appropriately scoped instructions and any needed supporting resources.

2026-08-13

imagegen

Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG/vector/code-native assets, extending an established icon or logo system, or building the visual directly in HTML/CSS/canvas.

2026-08-10

View all from this repository

Update V8 Version

Core Workflow

Read third_party/v8/README.md and follow its version-bump sequence. Treat that document as the release-process source of truth.

Inspect and update the concrete repo surfaces that carry the pin:

codex-rs/Cargo.toml
codex-rs/Cargo.lock
MODULE.bazel
third_party/v8/BUILD.bazel
third_party/v8/README.md
the matching third_party/v8/rusty_v8_<version>.sha256 manifest when the remaining prebuilt inputs change

Keep the existing checksum helpers in the loop:

python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py

Validate the release-candidate path before broadening the work:

Prefer checking the v8-canary CI result for the candidate branch or PR when one exists, using GitHub check tooling or gh as appropriate.
If CI is unavailable or the user asked for a local-only check, run the closest local validation that is practical for the changed surface and say explicitly that it is a local substitute, not the full hosted canary.

If the canary path passes, stop there. Summarize the result and encourage the user to commit the candidate changes or proceed with the release flow they requested. Do not publish tags, releases, or pushes unless the user asked.

Failure Path

Enter this path only when the canary or local build path fails.

Capture the failing target, workflow job, and first actionable error.

Compare the currently pinned version with the target version at the relevant upstream tag or SHA. Inspect both:

denoland/rusty_v8
upstream V8 source at the target Bazel-pinned version

Track build-relevant deltas rather than broad source churn:

generated binding layout changes
archive or asset naming changes
GN/Bazel target changes
custom libc++ / libc++abi / llvm-libc inputs
sandbox or pointer-compression feature relationships
patch hunks in patches/ that no longer apply or no longer match upstream

Trace each failing delta back into Codex's build graph:

MODULE.bazel
third_party/v8/BUILD.bazel
.github/scripts/rusty_v8_bazel.py
.github/workflows/v8-canary.yml
.github/workflows/rusty-v8-release.yml

Update only the pieces required to restore the target version's build and artifact contract. Keep patch explanations and doc changes close to the affected files.

Re-run the focused validation. If it becomes green, return to the normal workflow and stop with a concise summary plus the remaining release step.

Reporting

Say whether validation came from hosted v8-canary or from a local substitute.

Distinguish "version bump complete" from "release published".

When blocked, report the upstream delta that matters, the Codex file it hits, and the next concrete fix to try.