[codex] add portable binary release validation

[johnnyhuy]

Summary

• add CI coverage that smoke-tests compiled Bun artifacts across native runners, QEMU arm64 emulation, Wine, Docker multi-arch images, and packaging syntax checks
• add a release workflow that uploads compiled binaries to GitHub Releases and then verifies Homebrew, Chocolatey, and winget installs against the same release URLs used by packaging metadata
• switch the winget installer manifest to portable so release verification exercises the portable .exe flow end to end, and add renderer/package validation helpers for generated packaging assets

Why

The distribution assets added in #45, #46, #47, #48, and #49 depended on compiled Bun binaries being portable, but the repository only smoke-tested host builds and did not verify that release assets were uploaded and consumable through package-manager flows. That left a gap where packaging metadata could look correct while real installs from release URLs still failed.

What changed

• extended scripts/smoke-artifact.ts so one smoke path can validate arbitrary artifacts and wrapper runners like wine64
• added scripts/validate-packaging.ts and a mise run package-validate task to verify rendered packaging output and manifest structure from current build checksums
• expanded build-matrix.yaml with QEMU arm64 binary checks, Wine Windows binary checks, Docker amd64/arm64 image checks, and packaging validation jobs
• added release-binaries.yaml to build release artifacts, upload them to the GitHub release, and verify Homebrew, Chocolatey, and winget installation from those release-backed assets
• updated winget manifests/rendering to use the portable installer type for the compiled Windows binary

Validation

• bun scripts/build-release.ts --targets=darwin-arm64,darwin-x64,windows-x64,linux-x64-gnu,linux-x64-musl,linux-arm64-gnu,linux-arm64-musl
• bun scripts/write-checksums.ts
• bun scripts/smoke-artifact.ts
• bun scripts/validate-packaging.ts
• bunx vitest run tests/distribution/homebrew.test.ts tests/distribution/chocolatey.test.ts tests/distribution/winget.test.ts tests/distribution/npm-package.test.ts tests/build/targets.test.ts

Follow-up context

• follow-up to feat(release): add homebrew formula packaging #45, feat(release): add chocolatey packaging #46, feat(release): add winget manifests #47, feat(release): add docker musl image packaging #48, and feat(release): add npm package flow for npx and bunx #49

In general, to fix this issue you add a permissions: block to the workflow (either at the root level so it applies to all jobs, or per job) and set it to the minimum scopes required. For CI workflows that only read the code and upload artifacts (using actions that do not require repo writes), contents: read is a good minimal starting point.

For this specific workflow, the steps use:

• actions/checkout to read the repository
• jdx/mise-action, docker/setup-qemu-action, actions/upload-artifact, and actions/download-artifact
  All of these operate with the GITHUB_TOKEN at most needing read access to repository contents (and the artifact actions typically work without additional repo write permissions). There is no indication of any step that pushes commits, creates releases, or modifies issues/PRs.

The single best fix is therefore:

• Add a root-level permissions: block after the on: section (e.g., after line 8) setting contents: read. This will apply to all jobs (build, checksums, qemu-smoke, wine-smoke, docker-integration, packaging-validate, etc.) unless they override it.
• No other imports, methods, or definitions are needed since this is purely a workflow configuration change.

Concretely:

• Edit .github/workflows/build-matrix.yaml.

• Insert:

  permissions:
    contents: read

  between the on: block and the jobs: key.

To fix the problem, explicitly define restricted GITHUB_TOKEN permissions in the workflow. Since none of the shown jobs perform any GitHub write operations (they check out code, download artifacts, build and smoke‑test binaries/images), they only require read access to repository contents and, optionally, to packages if images are pushed (not shown here). The best minimal fix is to add a top‑level permissions block with contents: read, which applies to all jobs that do not override it.

Concretely, in .github/workflows/build-matrix.yaml, add a root‑level permissions: section right after the name: Build Matrix line (before on:). This will ensure that build, checksums, qemu-smoke, wine-smoke, docker-integration, packaging-validate, windows-packaging-validate, and any other jobs inherit contents: read and do not get broader defaults. No additional methods, imports, or definitions are needed—this is a pure YAML configuration change.

In general, fix this by adding an explicit permissions: block that grants only the minimal required scopes (usually contents: read) either at the workflow root (affecting all jobs) or on specific jobs. This prevents the workflow from inheriting potentially broader default permissions from the repository or organization.

For this workflow, the safest and simplest change without altering functionality is to define a workflow-level permissions block immediately after the name: (or after on:), setting contents: read. None of the shown jobs perform write operations to the repository or other resources via GITHUB_TOKEN; they mostly check out code, download artifacts, build, and run tests. actions/checkout operates fine with contents: read. Therefore, we can add:

permissions:
  contents: read

near the top of .github/workflows/build-matrix.yaml. This will apply to all jobs, including docker-integration (line 150) where CodeQL reported the issue, and will remove the warning while preserving existing behavior.

Concretely:

• Edit .github/workflows/build-matrix.yaml.
• Insert a workflow-level permissions: block between line 1 (name: Build Matrix) and line 3 (on:), or between on: and jobs:. I’ll place it right after the name: for clarity.
• No imports or additional methods are needed since this is a YAML configuration change only.

To fix this, explicitly define permissions for the GITHUB_TOKEN in the workflow and scope them as narrowly as possible. The jobs shown (docker-integration, packaging-validate, windows-packaging-validate, and the referenced checksums job) only need to read the repository contents and artifacts; they do not push commits, create releases, or modify issues/PRs. Therefore, setting contents: read at the workflow (root) level is an appropriate minimal starting point and aligns with the CodeQL suggestion.

The best minimal fix without changing existing functionality is:

• Add a permissions: block at the root of .github/workflows/build-matrix.yaml, alongside name and on, so it applies to all jobs that don’t override it.
• Set contents: read within that block. This allows actions/checkout and other read-only operations to work, while preventing write operations via GITHUB_TOKEN.
• Do not alter any job steps or add any additional scopes such as pull-requests or issues, since nothing in the provided snippet requires them.

Concretely, in .github/workflows/build-matrix.yaml, insert:

permissions:
  contents: read

between the name: Build Matrix line and the on: block (or immediately after on: if you prefer), ensuring indentation and YAML structure remain valid. No imports or external methods are needed.

In general, fix this issue by explicitly specifying a permissions: block that grants only the minimal required scopes for the GITHUB_TOKEN. This can be done at the workflow root (affecting all jobs that don’t override it) or per job. Here, all the shown jobs only read the repository (checkout, download artifacts, packaging/validation) and do not write to issues, PRs, or contents, so a minimal permissions: contents: read at the workflow root is appropriate.

The single best fix with no functional change is to add a top-level permissions: block right after the name: line (line 1) in .github/workflows/build-matrix.yaml. This will apply contents: read to all jobs, including windows-packaging-validate, and satisfies CodeQL’s recommendation. No additional imports or definitions are needed, and no existing steps/jobs need to be modified.

Specifically:

• In .github/workflows/build-matrix.yaml, insert:

permissions:
  contents: read

after line 1 (name: Build Matrix) and before the on: block at line 3. No other lines need to change.