5 Commits

  • Check root Python script formatting in CI (#25165)
    ## Why
    
    Python files under `scripts/` were not covered by the repository
    formatting recipe or the CI formatting job, so formatting drift could
    merge unnoticed.
    
    ## What
    
    - Add a dedicated `scripts/pyproject.toml` and `scripts/uv.lock` so
    root-script formatting uses a locked Ruff version.
    - Extend `just fmt` to format root Python scripts and add
    `fmt-scripts-check` for CI.
    - Run `just fmt-scripts-check` from `.github/workflows/ci.yml`,
    installing `uv` through SHA-pinned `astral-sh/setup-uv` while retaining
    the `uv` `0.11.3` pin.
    - Apply Ruff formatting to the root Python scripts, including
    `scripts/just-shell.py`, and extend
    `sdk/python/tests/test_artifact_workflow_and_binaries.py` to cover the
    root formatting recipe.
    - Update `AGENTS.md` so agents run `just fmt` after code changes
    anywhere in the repository.
    
    ## Validation
    
    - Extended the existing Python SDK workflow test to assert that `just
    fmt` includes root Python scripts.
  • ci: Use codex produced v8 artifacts for release builds (#23934)
    Updates our build script to pull down the artifacts like we do in CI for
    building v8 into our targets.
    
    This changes the flow so that we now pre-install rusty v8 assets for all
    of our release targets from pre-built in workflow.
    Secondarily if running it locally we now optionally pull the assets down
    on python run assuming the user hasn't set the proper values, it then
    provides them.
    
    Sorry for the miss here.
  • release: package prebuilt resource binaries (#23759)
    ## Why
    
    Release packaging should be a staging step once release binaries have
    already been built and signed. The Windows release job was downloading
    and signing `codex-command-runner.exe` and
    `codex-windows-sandbox-setup.exe`, but `scripts/build_codex_package.py`
    still rebuilt those helpers while creating the package archives.
    
    That makes the package step slower and, more importantly, risks putting
    helper binaries in the archive that were produced after the signing
    step. Linux had the same shape for package resources: `bwrap` could be
    rebuilt by the package builder instead of being passed in as a prebuilt
    release artifact.
    
    This builds on #23752, which fixes `.tar.zst` creation when Windows
    runners rely on the repository DotSlash `zstd` wrapper.
    
    ## What changed
    
    - Add explicit prebuilt resource inputs to the Codex package builder:
      - `--bwrap-bin`
      - `--codex-command-runner-bin`
      - `--codex-windows-sandbox-setup-bin`
    - Make `.github/scripts/build-codex-package-archive.sh` pass resource
    binaries from the release output directory when they are already
    present.
    - Build Linux `bwrap` for app-server release jobs too, so app-server
    package creation does not invoke Cargo just to supply the package
    resource.
    - Keep macOS package creation as a no-Cargo path when `--entrypoint-bin`
    is provided, since macOS packages have no resource binaries.
    - Add unit coverage showing prebuilt macOS, Linux, and Windows package
    inputs result in no source-built binaries.
    
    ## Verification
    
    - `python3 -m unittest discover -s scripts/codex_package -p 'test_*.py'`
    - `python3 -m py_compile scripts/codex_package/*.py`
    - `bash -n .github/scripts/build-codex-package-archive.sh`
    - Dry-ran Linux and Windows package builds with fake prebuilt resources
    and a nonexistent Cargo path to verify the package builder did not
    invoke Cargo.
    
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23759).
    * #23760
    * __->__ #23759
  • build: package prebuilt Codex entrypoints (#23586)
    ## Why
    
    The package builder should describe the binaries it is actually
    packaging, not require callers to restate release metadata out of band.
    A caller-provided `--version` flag can drift from the workspace version,
    but running the target entrypoint to discover its version breaks
    cross-target packages when the produced binary cannot execute on the
    build host.
    
    This PR keeps package metadata tied to the repository source of truth by
    reading `[workspace.package].version` from `codex-rs/Cargo.toml`. It
    also prepares the package layout for `codex-app-server` packages: the
    same package structure can now represent either the CLI entrypoint or
    the app-server entrypoint while keeping shared sidecars such as `rg`,
    `bwrap`, and Windows sandbox helpers in the existing package
    directories.
    
    ## What changed
    
    - Removes the `--version` CLI flag from
    `scripts/build_codex_package.py`.
    - Adds Cargo.toml version discovery for `codex-package.json.version` via
    `codex-rs/Cargo.toml`.
    - Adds `--entrypoint-bin` so callers can package a prebuilt entrypoint
    instead of rebuilding it with Cargo.
    - Makes `--variant` an explicit choice between `codex` and
    `codex-app-server`, and uses it to select the cargo binary and packaged
    `bin/` entrypoint name.
    - Updates `scripts/codex_package/README.md` to document variants,
    prebuilt entrypoints, and Cargo.toml version detection.
    
    ## Verification
    
    - Compiled `scripts/build_codex_package.py` and
    `scripts/codex_package/*.py` with `PYTHONDONTWRITEBYTECODE=1`.
    - Ran `scripts/build_codex_package.py --help` and verified `--version`
    is gone while `--variant` and `--entrypoint-bin` are present.
    - Verified the package builder reads version `0.0.0` from
    `codex-rs/Cargo.toml`.
    - Built a fake cross-target `codex-app-server` package using a
    non-executable `--entrypoint-bin`; verified metadata records version
    `0.0.0`, variant `codex-app-server`, and `bin/codex-app-server` as the
    entrypoint.
  • build: add Codex package builder (#23513)
    ## Why
    
    Codex CLI packaging is currently split across npm staging, standalone
    installers, and release bundle creation, which makes it hard to define
    and validate a single valid package directory. This adds the first
    standalone package builder so later release paths can converge on the
    same canonical layout.
    
    ## What changed
    
    - Added `scripts/build_codex_package.py` as the stable executable
    wrapper around `scripts/codex_package`.
    - Added modules for CLI parsing, target metadata, grouped cargo builds,
    package layout validation, and archive writing.
    - The builder creates a package directory with `codex-package.json`,
    `bin/`, `codex-resources/`, and `codex-path`, and can serialize it as
    `.tar.gz`, `.tar.zst`, or `.zip`.
    - Source-built artifacts are built by one grouped `cargo build`: `codex`
    for all targets, `bwrap` for Linux, and the Windows sandbox helpers for
    Windows. `rg` remains an input because it is vendored from upstream
    rather than built from this repo.
    - Added `scripts/codex_package/README.md` to document the package
    layout, source-built artifacts, and cargo profile behavior.
    
    ## Verification
    
    - Ran wrapper/module syntax compilation.
    - Ran `scripts/build_codex_package.py --help` from `/private/tmp`.
    - Ran fake-cargo package/archive builds for macOS, Linux, and Windows
    target layouts, including an assertion that generated tar archives
    contain no duplicate member names.
    
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23513).
    * #23526
    * __->__ #23513