Certify that Codex versions bundled in the VS Code extension are GitHub release assets

What feature would you like to see?

Summary

Please introduce a small, documented certification process ensuring that every Codex CLI binary packaged in the Codex VS Code extension is:

1. An unmodified artifact published in a GitHub Release of openai/codex, and
2. Publicly identifiable (by version and checksum) so that security‑conscious users can verify it.

This is a narrowly scoped supply‑chain transparency request that should remain useful whether or not the VS Code extension itself is ever open‑sourced, and is intended as a follow‑up to the discussion in openai/codex#5822.

Motivation

• Supply‑chain transparency for dev tools <br>The VS Code extension can read and modify files, run commands, and delegate tasks to the cloud. Many organizations now treat IDE extensions and local CLIs as part of their software supply chain and need to be able to verify exactly which binaries they are running.
• Alignment with the open‑source Codex CLI <br>The Codex CLI is already open‑source and published on GitHub with platform‑specific binaries in each Release. The VS Code extension is documented and described publicly as being “built around the open(-source) Codex CLI”. A simple certification step that the IDE bundle uses those same published artifacts would make that story verifiable in practice.
• Security posture and audits <br>Security reviews increasingly ask: “Can you prove the binary in your IDE matches one you publicly ship, with a known SBOM and license?” A clear mapping between extension versions and Codex CLI release assets would make it much easier for users to answer “yes”.
• Reproducibility short of full open‑sourcing <br>Even if the extension code remains closed, being able to confirm that the embedded codex binaries match GitHub Release assets gives users a reproducible, auditable core for the component that actually executes commands on their machines.

Proposal

Introduce and document an internal + external certification/attestation flow along these lines:

1. Bundle only released Codex CLI binaries

• For each VS Code extension release X.Y.Z, choose a Codex CLI release (or exact tag/commit) vA.B.C from openai/codex.
• Ensure that every codex binary packed into the .vsix (for all supported platforms) is bit‑for‑bit identical to a specific asset from that GitHub Release (e.g., after extracting codex-x86_64-unknown-linux-musl from codex-x86_64-unknown-linux-musl.tar.gz).

1. Publish mapping metadata

• Maintain a small, public mapping from extension version → Codex CLI release + asset identifiers, e.g.:

``jsonc
{
"0.5.47": {
"cli_release": "0.63.0",
"binaries": {
"darwin-aarch64": "codex-aarch64-apple-darwin.tar.gz",
"linux-x86_64": "codex-x86_64-unknown-linux-musl.tar.gz",
"windows-x86_64": "codex-x86_64-pc-windows-msvc.zip"
}
}
}
``

• This could live in the openai/codex repo (e.g., docs/extension-builds.json), or in a short “Release process” section in the docs plus a table.

1. Expose the bundled Codex version in the extension UI

• Add a command like “Codex: Show bundled CLI information” that prints:
• Extension version
• Codex CLI version / tag
• (Optionally) short commit hash or build metadata
• This makes it straightforward for users to confirm “I’m running extension 0.5.47 with CLI 0.63.0” and then cross‑check that against the public mapping.

1. Document verification steps

• Provide a short how‑to that explains how a user can:
• Extract the .vsix for a given version,
• Locate the bundled codex binaries,
• Compute their SHA‑256 checksums, and
• Verify them against the checksums of the corresponding GitHub Release assets.
• For most users, even just the version → release mapping will be enough; security teams will appreciate the extra detail.

Scope requested

Concretely, this feature request asks for:

• A policy that the VS Code extension only ships Codex CLI binaries that correspond to published Release assets in openai/codex (no unpublished or internal‑only builds).
• A public, machine‑readable mapping from extension version → Codex CLI release + asset names.
• A user‑visible way (command or status panel) to see which Codex CLI version is bundled.
• Minimal documentation (a few paragraphs) describing:
• how the mapping works,
• where to find it, and
• how to verify a .vsix against the GitHub Release assets if desired.

No changes are being requested to the IDE feature set, pricing, or supported platforms—this is purely about provenance of the embedded CLI binaries.

Benefits

• Auditable supply chain

Enterprises and OSS maintainers can assert that the binary which runs in their editors is the same as the open‑source Codex CLI they’ve already reviewed and approved.

• Simpler security reviews

Many security questionnaires now explicitly ask about binary provenance. A documented mapping and verification process is a concrete, easy‑to‑link answer.

• Clearer troubleshooting

When debugging issues, both users and OpenAI staff can refer to “extension 0.5.47 with CLI 0.63.0” rather than an opaque “whatever is bundled right now”.

• Future‑proofing

If new security guidance (e.g., from regulators, large enterprise customers, or ecosystem maintainers) pushes for stronger attestation around dev‑tool binaries, having this mapping and policy in place puts Codex ahead of the curve.

Relationship to openai/codex#5822

Issue openai/codex#5822 requested open‑sourcing the VS Code extension and described a broader set of supply‑chain measures (reproducible builds, checksums for the .vsix, etc.). This request is intentionally narrower:

• It does not depend on the extension being open‑sourced.
• It focuses solely on establishing that the CLI binaries that can run commands and edit files are the same as those already shipped via GitHub Releases.
• It should be implementable with relatively small process and documentation changes, while still delivering a meaningful security and trust improvement.

If, in the future, the extension is open‑sourced or additional release‑integrity features are added, this certification mechanism would slot neatly into that broader story.

Proposed acceptance criteria

• Every published Codex VS Code extension version has:
• A documented Codex CLI release it depends on, and
• A set of GitHub Release assets that are declared to be the source of its embedded codex binaries.
• The extension provides a command or UI to reveal the bundled Codex CLI version.
• Users can follow a short, documented procedure to:
• Extract an extension .vsix,
• Find the embedded codex binary/binaries, and
• Confirm (via hash) that they match GitHub Release assets for the advertised Codex CLI version.
• The above is kept up‑to‑date for new extension releases.

Additional information

Happy to help test any verification steps or provide feedback from the perspective of teams with stricter supply‑chain requirements.