Release

Release Bex Security

Publish one immutable @bex-co/bex-security version from main. A successful release has the same version in sdk/typescript/package.json, npm, the bex-v<version> Git tag, and the GitHub release.

Preconditions

1. Read the repository AGENTS.md instructions and review all material that will become public.

2. Require a clean worktree on main. Never stash, discard, amend, rebase a published commit, or force-push.

3. Fetch origin and the canonical openai/codex-security upstream. Bring local main to origin/main with a fast-forward only.

4. Confirm sdk/typescript/package.json names @bex-co/bex-security, points to the Bex repository, and retains codex-security only as a compatibility bin.

5. Authenticate to the public npm registry. When .env provides NPM_TOKEN, load it without printing it and pass it only through the process environment:

   env "npm_config_//registry.npmjs.org/:_authToken=$NPM_TOKEN" npm whoami --registry=https://registry.npmjs.org
   

   Do not create or commit an npm credentials file.

Choose The Version

Resolve the merged upstream baseline with git merge-base main upstream/main. Read the upstream package version from that commit rather than claiming an unmerged upstream release.

• Versions are <upstream-version>-bex.<release-number>.
• Use .1 for the first Bex release on a new upstream version.
• Otherwise increment the greatest published Bex release number for that exact upstream version.
• Never reuse, overwrite, deprecate, or unpublish a version.
• If npm already contains the intended version, enter recovery mode: do not bump or publish it again; verify the archive and complete only missing Git or GitHub release metadata.

Update these fields together:

• version
• bex.upstreamVersion
• bex.upstreamCommit
• .github/bex-release-notes.md release marker, heading, summary, highlights, and upstream base

Release notes must describe user-visible Bex behavior generically. Do not copy private scan targets, findings, credentials, customer context, local paths, or unreviewed commit messages into public metadata.

Validate The Exact Package

Install from the frozen lockfile, then run formatting, generated-model checks, types, tests, build, production audit, and the installed-package smoke test. Pack into an ignored release directory and run scripts/check-package.mjs on the exact tarball. Inspect its package metadata and file list before publication.

The package must expose bex-security, preserve codex-security as an alias, query @bex-co/bex-security for update notices, and contain no credentials or private release material.

Commit And Publish

1. Commit only the reviewed version, metadata, notes, documentation, tests, and release-workflow changes. Pull origin/main with rebase before the first push, resolve conflicts without losing either side, and push normally.

2. Wait for the pushed Node and container CI workflows to succeed. Fix and repeat when an in-scope failure is reproducible.

3. Create the annotated tag bex-v<version> on the verified commit and push the tag without force.

4. Publish the exact validated tarball with public access and the latest dist-tag:

   env "npm_config_//registry.npmjs.org/:_authToken=$NPM_TOKEN" npm publish <archive> --access public --tag latest --registry=https://registry.npmjs.org
   

5. Verify npm reports the expected name, version, description, repository, bins, latest dist-tag, and Bex upstream metadata. Install the registry version into a clean temporary consumer and run both CLI launchers.

6. Create a reviewed GitHub release from the existing tag, with title Bex Security <version> and .github/bex-release-notes.md as its body.

If npm publishing succeeds but a later step fails, do not create another version. Resume from registry verification and finish the missing tag or GitHub release. Report the version, upstream baseline, commit, npm URL, GitHub release URL, checks run, and final main...origin/main status.