Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions sdk/typescript/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,69 @@ When a newer version is available, the CLI shows the update command for your
installation method. Set `CODEX_SECURITY_NO_UPDATE_NOTICE=1` to hide the
notice. Notices are also disabled in CI and when stderr is not a terminal.

## Release and bundle provenance

A published package contains several independently versioned layers. The npm
package version is the release anchor, while the bundled plugin and the Codex
runtime dependencies have their own version fields:

| Layer | Source of truth | What it identifies |
| -------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| npm package | `sdk/typescript/package.json` and the `npm-vX.Y.Z` tag | The published SDK and CLI release |
| bundled plugin | `_bundled_plugin/.codex-plugin/plugin.json` and `BUNDLED_PLUGIN_VERSION` | The plugin manifest and compatibility version, not a content hash |
| Codex runtime | `@openai/codex` and `@openai/codex-sdk` in `package.json` | The runtime and SDK dependency versions used by the package |

For an exact, byte-for-byte reference to the bundled plugin, use its Git tree
object at the release tag. For example, replace `0.1.5` with the release you
are checking:

```bash
VERSION=0.1.5
TAG="npm-v${VERSION}"

git rev-parse "${TAG}^{commit}"
git rev-parse "${TAG}:sdk/typescript/_bundled_plugin"
git show "${TAG}:sdk/typescript/package.json" | jq -r .version
git show "${TAG}:sdk/typescript/_bundled_plugin/.codex-plugin/plugin.json" | jq -r .version
```

The first two values form the immutable release-to-bundle mapping. The npm
registry exposes release metadata that is useful for inspection:

```bash
npm view "@openai/codex-security@${VERSION}" version gitHead dist.integrity

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

npm view only reports registry metadata; it does not verify the package bytes or a signed provenance attestation. gitHead is package metadata and dist.integrity is a tarball digest, so this recipe does not establish that the npm artifact was produced from the tagged commit and bundled tree. The release workflow additionally checks the archive and runs npm audit signatures --include-attestations, then binds the attestation to the expected repository, commit, and release run. Please document comparable verification, or explicitly describe this command as metadata inspection rather than provenance verification.

```

This metadata is not signed provenance verification. To verify the published
package cryptographically, use npm's signature and attestation audit and the
release workflow's SLSA checks:

```bash
npm audit signatures \
--prefix "$CONSUMER_DIR" \
--registry=https://registry.npmjs.org/ \
--json \
--include-attestations
```

The audit must identify the public npm registry, an SLSA v1 attestation, the
exact package tarball, the protected release workflow, and the release commit.
The `npm view` fields and `dist.integrity` value are useful cross-checks, but a
matching registry record alone does not prove who built or signed the package.

The first two historical npm releases, `0.1.0` and `0.1.1`, may omit `gitHead`
from their registry metadata. For those versions only, the release workflow
recovers the commit from verified SLSA provenance and then performs the normal
integrity and provenance checks. Every later release must publish a matching
40-character `gitHead`; a missing or mismatched value fails verification.

`bundledPluginVersion` in `codex-security info --json` is useful diagnostic
metadata, but it does not replace the bundled tree hash. A runtime or catalog
version supplied by the Codex distribution is external to this repository and
cannot be inferred from the npm tag or the plugin manifest. Record that value
from the runtime's own release metadata alongside the package tag and bundled
tree hash when producing a provenance report.

## Run a scan from TypeScript

Sign in with `npx @openai/codex-security login` or set `OPENAI_API_KEY` or
Expand Down