ci: require manual live smoke scans for bundled MCP changes

[kmbroai]

Summary

Require a maintainer-initiated, real package scan before pull requests can merge when they change the bundled MCP runtime.

Changes

• Add a manual-only GitHub Actions workflow that builds the exact pull request commit, verifies package provenance, and completes a small real scan on Linux and Windows.
• Require successful per-platform smoke statuses for that exact commit through the existing protected Windows CI check, while letting unrelated changes pass without a live scan.
• Keep candidate builds isolated from model credentials, run the trusted scan helper from the default branch, and support short-lived workload identity or a protected environment API key.
• Add deterministic coverage for changed-file detection, renamed MCP files, stale or failed statuses, manual-only triggers, credential isolation, and token exchange.

Testing

• bun test --randomize --seed 12345 --timeout 30000 ./tests-ts/live-scan-smoke-workflow.test.ts ./tests-ts/skeleton.test.ts ./tests-ts/release-cut-workflow.test.ts — 21 passed, 82 assertions.
• tsc --noEmit and tsc -p tsconfig.build.json — passed.
• node scripts/generate-models.cjs --check — passed.
• actionlint .github/workflows/node-ci.yml .github/workflows/live-scan-smoke.yml — passed.
• Prettier, all workflow shell blocks, action SHA pinning, job permissions, manual-only triggers, and the helper credential self-test — passed.
• Packed the candidate with an immutable gitHead and validated all 203 archive entries, the bundled plugin contract, and expected commit provenance.
• The complete preexisting suite cannot run on the local sandbox because its temporary-directory mount is owned by an unmapped UID; hosted CI provides the full platform matrix.
• A real model-backed run requires the protected environment described below and was not run locally.

Risk and rollout

• Before the first bundled MCP change after merge, explicitly create and protect the security-live-smoke environment and configure either OPENAI_IDENTITY_PROVIDER_ID, OPENAI_SERVICE_ACCOUNT_ID, and OPENAI_WIF_AUDIENCE, or its protected CODEX_SECURITY_SMOKE_OPENAI_API_KEY secret.
• Smoke tests never run on push, pull request, schedule, or workflow-completion events. Maintainers initiate them with gh workflow run live-scan-smoke.yml --repo openai/codex-security --ref main --field pull_request=PR_NUMBER.
• Changes outside sdk/typescript/_bundled_plugin/mcp/ do not require the manual scan. Existing Linux, macOS, and Windows CI coverage and protected check names are preserved.
• Fork pull requests cannot receive model credentials; bundled MCP changes from external contributors must first be brought into a reviewed same-repository pull request.
• Model runs use a tiny committed fixture, four-minute scan timeout, low reasoning effort, one worker, and a $0.25 estimated-cost ceiling.

Public disclosure review

• No customer, partner, prospect, or user identities, data, or identifying details are included.
• No credentials, personal data, private source, scan findings, or nonpublic links or tickets are included.
• I reviewed the branch name, title, description, commits, changes, comments, logs, screenshots, attachments, and links for public disclosure.

[ting-hong-shieh]

Reviewed exact head 0ea332729a9bc12ba268ed98d381c1047c5e196b against current main 2f785900d2cefb932cf97fb1d675491d14790839. The focused workflow test passes with Bun 1.3.14 (12 passed, 42 expect() calls), the helper self-test passes, git diff --check passes, and the public check matrix is green.

I found one merge-gate lifecycle gap in the inline comment. The active main ruleset currently requires these contexts:

macos-latest / node-22
ubuntu-latest / node-22
windows-latest / node-22

It does not directly require codex-security/live-smoke-linux or codex-security/live-smoke-windows. The same-head transition is therefore:

first successful dispatch: live statuses succeed -> node-ci is refreshed -> protected Windows aggregate succeeds
later failed dispatch:      live statuses fail    -> refresh step is skipped -> protected Windows aggregate keeps its earlier success

I queried only the public GitHub ruleset and ran synthetic local workflow checks. I did not run a model-backed scan, call the OpenAI API, use credentials, or provide an external scan target.

[ting-hong-shieh]

Invalidate the protected gate after an unsuccessful rerun

After one successful dispatch for a head SHA, this step reruns node-ci and the required windows-latest / node-22 aggregate becomes successful. If a maintainer later dispatches the smoke workflow again for the same unchanged head and either platform fails, lines 349–365 replace the two live-smoke statuses with failure, but this step is skipped because all-passed is false. node-ci listens only to push and pull_request, and the active ruleset does not require the two live-smoke contexts directly, so nothing reevaluates the already-successful protected aggregate.

Please make pending or failed same-head runs invalidate the protected gate as well—for example, by refreshing the gate on every terminal result or by requiring the two exact-head status contexts directly—and add a success-to-failure lifecycle case to the test.