This document describes the build system, CI/CD pipelines, and distribution infrastructure for Codex. It covers the Cargo workspace structure, the Bazel build configuration, platform build matrix, code signing procedures, artifact packaging, and distribution channels (npm, Homebrew, WinGet, GitHub Releases).
For information about development environment setup and local tooling, see Development Setup. For workspace organization and crate relationships, see Repository Structure.
The Codex build and distribution system supports multiple execution modes and platforms through a layered pipeline:
rust-ci.yml, rust-ci-full.yml): Runs on pull requests and pushes to main, performing lint/test checks across all supported platforms using Cargo and Bazel.rust-release.yml, rust-release-windows.yml): Triggered by git tags matching rust-v*.*.*, builds release binaries with platform-specific code signing and optimized profiles.@openai/codex-shell-tool-mcp package.Build Targets: The release pipeline builds for platform triples including:
aarch64-apple-darwin, x86_64-apple-darwin [.github/workflows/rust-release.yml84-107]x86_64-unknown-linux-musl, aarch64-unknown-linux-musl [.github/workflows/rust-release.yml109-132]x86_64-pc-windows-msvc, aarch64-pc-windows-msvc [.github/workflows/rust-release-windows.yml25-66]Sources: [.github/workflows/rust-release.yml11-133], [.github/workflows/rust-ci.yml1-10], [.github/workflows/rust-release-windows.yml1-11]
Codex uses a hybrid build approach. While Cargo is the primary developer interface, Bazel provides hermetic builds, remote caching, and cross-compilation toolchains. For details, see Cargo Workspace Structure.
| Component | Build Tool | Primary Output / Target |
|---|---|---|
codex | Cargo / Bazel | //codex-rs/cli:codex [.github/workflows/sdk.yml102] |
codex-app-server | Cargo / Bazel | codex-app-server [.github/workflows/rust-release-windows.yml7] |
argument-comment-lint | Dylint / Bazel | tools/argument-comment-lint [.github/workflows/rust-ci.yml112-162] |
sdk/typescript | pnpm | ./sdk/typescript [.github/workflows/sdk.yml150] |
Toolchain Management: The workspace pins the Rust toolchain version to 1.95.0 [.github/workflows/rust-ci.yml75] and uses a specific nightly toolchain (nightly-2025-09-18) for specialized linting [.github/workflows/rust-ci.yml130-136].
Bazel Integration: Bazel handles complex dependencies and provides remote execution via BuildBuddy configurations [.bazelrc53-73]. It manages hermetic toolchains and uses a specific stack size (RUST_MIN_STACK=8388608) for Windows CI to prevent overflows [.bazelrc38].
Sources: [.bazelrc1-135], [.github/workflows/rust-ci.yml75-81], [justfile1-165]
The CI pipeline validates code quality and correctness on every change. For details, see CI Pipeline.
The rust-ci.yml workflow uses a changed job to analyze path changes, skipping expensive build steps if only documentation or unrelated tools were modified. It detects changes in codex-rs/*, .github/*, and tools/argument-comment-lint/* [.github/workflows/rust-ci.yml13-55].
The CI runs a comprehensive matrix across Linux, macOS, and Windows.
cargo fmt [.github/workflows/rust-ci.yml79] and cargo shear to find unused dependencies [.github/workflows/rust-ci.yml106].run-bazel-ci.sh, including cross-compiled Windows tests using x86_64-pc-windows-gnullvm [.github/workflows/bazel.yml169-181].argument-comment-lint using Dylint to enforce documentation standards on function arguments [.github/workflows/rust-ci.yml112-162].sdk.yml workflow verifies the Python and TypeScript SDKs against the Bazel-built codex binary [.github/workflows/sdk.yml85-156].Sources: [.github/workflows/rust-ci.yml13-162], [.github/workflows/bazel.yml1-181], [.github/workflows/sdk.yml1-169]
Sources: [.github/workflows/rust-ci.yml13-112], [.github/workflows/bazel.yml1-52], [.github/workflows/sdk.yml1-10]
The release pipeline automates the creation of production-ready artifacts. For details, see Release Pipeline.
Releases are triggered by pushing a tag matching rust-v*.*.* [.github/workflows/rust-release.yml12-15]. The tag-check job validates that the tag matches the version in codex-rs/Cargo.toml [.github/workflows/rust-release.yml25-54].
build_dmg flag for macOS targets to produce signed Disk Images [.github/workflows/rust-release.yml89-101].codex.exe and helper binaries like codex-windows-sandbox-setup and codex-command-runner [.github/workflows/rust-release-windows.yml28-67]. These are staged with PDB symbols for debugging [.github/workflows/rust-release-windows.yml116-135].Sources: [.github/workflows/rust-release.yml1-133], [.github/workflows/rust-release-windows.yml1-145]
Codex is distributed through multiple channels to support different user workflows. For details, see Distribution Channels.
@openai/codex-sdk and @openai/codex-shell-tool-mcp. The sdk.yml workflow builds and lints SDK packages for distribution [.github/workflows/sdk.yml149-153].codex, codex-app-server, and codex-responses-api-proxy across all matrix targets [.github/workflows/rust-release.yml88-131]..github/dotslash-config.json to map platform-specific artifacts to local executable paths [.github/dotslash-config.json1-124].Sources: [.github/workflows/rust-release.yml88-131], [.github/workflows/rust-release-windows.yml7-11], [.github/workflows/sdk.yml149-153], [.github/dotslash-config.json3-122]
Codex includes a specialized build system for patched versions of Bash and Zsh. For details, see Shell Tool MCP Build System.
The build process involves compiling shells across various OS variants (e.g., Ubuntu, macOS, Windows) to ensure compatibility with the EXEC_WRAPPER sandbox requirements. This ensures that shells used by the agent can enforce sandbox policies and report capability states.
Sources: [.github/workflows/rust-ci.yml13-60] (Scoping based on repository structure and package references).
Refresh this wiki
This wiki was recently refreshed. Please wait 4 days to refresh again.