Commit Graph

3 Commits

  • Harden package-manager install policy (#19163)
    ## Summary
    
    This PR hardens package-manager usage across the repo to reduce
    dependency supply-chain risk. It also removes the stale `codex-cli`
    Docker path, which was already broken on `main`, instead of keeping a
    bitrotted container workflow alive.
    
    ## What changed
    
    - Updated pnpm package manager pins and workspace install settings.
    - Removed stale `codex-cli` Docker assets instead of trying to keep a
    broken local container path alive.
    - Added uv settings and lockfiles for the Python SDK packages.
    - Updated Python SDK setup docs to use `uv sync`.
    
    ## Why
    
    This is primarily a security hardening change. It reduces
    package-install and supply-chain risk by ensuring dependency installs go
    through pinned package managers, committed lockfiles, release-age
    settings, and reviewed build-script controls.
    
    For `codex-cli`, the right follow-up was to remove the local Docker path
    rather than keep patching it:
    
    - `codex-cli/Dockerfile` installed `codex.tgz` with `npm install -g`,
    which bypassed the repo lockfile and age-gated pnpm settings.
    - The local `codex-cli/scripts/build_container.sh` helper was already
    broken on `main`: it called `pnpm run build`, but
    `codex-cli/package.json` does not define a `build` script.
    - The container path itself had bitrotted enough that keeping it would
    require extra packaging-specific behavior that was not otherwise needed
    by the repo.
    
    ## Gaps addressed
    
    - Global npm installs bypassed the repo lockfile in Docker and CLI
    reinstall paths, including `codex-cli/Dockerfile` and
    `codex-cli/bin/codex.js`.
    - CI and Docker pnpm installs used `--frozen-lockfile`, but the repo was
    missing stricter pnpm workspace settings for dependency build scripts.
    - Python SDK projects had `pyproject.toml` metadata but no committed
    `uv.lock` coverage or uv age/index settings in `sdk/python` and
    `sdk/python-runtime`.
    - The secure devcontainer install path used npm/global install behavior
    without a local locked package-manager boundary.
    - The local `codex-cli` Docker helper was already broken on `main`, so
    this PR removes that stale Docker path instead of preserving a broken
    surface.
    - pnpm was already pinned, but not to the current repo-wide pnpm version
    target.
    
    ## Verification
    
    - `pnpm install --frozen-lockfile`
    - `.devcontainer/codex-install`: `pnpm install --prod --frozen-lockfile`
    - `.devcontainer/codex-install`: `./node_modules/.bin/codex --version`
    - `sdk/python`: `uv lock --check`, `uv sync --locked --all-extras
    --dry-run`, `uv build`
    - `sdk/python-runtime`: `uv lock --check`, `uv sync --locked --dry-run`,
    `uv build --wheel`
    - `pnpm -r --filter ./sdk/typescript run build`
    - `pnpm -r --filter ./sdk/typescript run lint`
    - `pnpm -r --filter ./sdk/typescript run test`
    - `node --check codex-cli/bin/codex.js`
    - `docker build -f .devcontainer/Dockerfile.secure -t codex-secure-test
    .`
    - `cargo build -p codex-cli`
    - repo-wide package-manager audit
  • Stage publishable Python runtime wheels (#18865)
    This is PR 2 of the Python SDK PyPI publishing split. [PR
    1](https://github.com/openai/codex/pull/18862) refreshed the generated
    SDK bindings; this PR makes the runtime package itself publishable, and
    PR 3 will wire the SDK package/version pinning to this runtime package.
    
    ## Summary
    - Rename the runtime distribution to `openai-codex-cli-bin` while
    keeping the import package as `codex_cli_bin`.
    - Make the runtime package wheel-only and build `py3-none-<platform>`
    wheels instead of interpreter-specific wheels.
    - Add `stage-runtime --codex-version` and `--platform-tag` so release
    staging can produce the platform wheel matrix from Codex release tags.
    - Add focused artifact workflow tests for version normalization,
    platform tag injection, and runtime wheel metadata.
    
    ## Why Rename
    There is already an unofficial PyPI package,
    [`codex-bin`](https://pypi.org/project/codex-bin/), distributing OpenAI
    Codex binaries. Publishing the official SDK runtime dependency as
    `openai-codex-cli-bin` makes the ownership clear, avoids confusing the
    SDK-pinned runtime wheel with that unowned wrapper, and keeps the import
    package unchanged as `codex_cli_bin`.
    
    ## Tests
    - `uv run --extra dev pytest
    tests/test_artifact_workflow_and_binaries.py` -> 21 passed
    - `uv run --extra dev python scripts/update_sdk_artifacts.py
    stage-runtime /tmp/codex-python-pr2-rebased/runtime-stage
    /tmp/codex-python-pr2-rebased/codex --codex-version
    rust-v0.116.0-alpha.1 --platform-tag macosx_11_0_arm64`
    - `uv run --with build --extra dev python -m build --wheel
    /tmp/codex-python-pr2-rebased/runtime-stage`
    - `uv run --with twine --extra dev twine check
    /tmp/codex-python-pr2-rebased/runtime-stage/dist/openai_codex_cli_bin-0.116.0a1-py3-none-macosx_11_0_arm64.whl`
    
    ## Note
    - Full `uv run --extra dev pytest` currently fails because regenerating
    from schemas already on `main` adds new DeviceKey Python types. I left
    that generated catch-up out of this runtime-only PR.
  • Add Python app-server SDK (#14435)
    ## TL;DR
    Bring the Python app-server SDK from `main-with-prs-13953-and-14232`
    onto current `main` as a standalone SDK-only PR.
    
    - adds the new `sdk/python` and `sdk/python-runtime` package trees
    - keeps the scope to the SDK payload only, without the unrelated
    branch-history or workflow changes from the source branch
    - regenerates `sdk/python/src/codex_app_server/generated/v2_all.py`
    against current `main` schema so the extracted SDK matches today's
    protocol definitions
    
    ## Validation
    - `PYTHONPATH=sdk/python/src python3 -m pytest sdk/python/tests`
    
    Co-authored-by: Codex <noreply@openai.com>