Commit Graph

26 Commits

  • fix: use continue-on-error: true to tidy up GitHub Action (#871)
    I installed the GitHub Actions extension for VS Code and it started
    giving me lint warnings about this line:
    
    
    https://github.com/openai/codex/blob/a9adb4175c8f19a97e50be53cb6f8fe7ef159762/.github/workflows/rust-ci.yml#L99
    
    Using an env var to track the state of individual steps was not great,
    so I did some research about GitHub actions, which led to the discovery
    of combining `continue-on-error: true` with `if .. steps.STEP.outcome ==
    'failure'...`.
    
    Apparently there is also a `failure()` macro that is supposed to make
    this simpler, but I saw a number of complains online about it not
    working as expected. Checking `outcome` seems maybe more reliable at the
    cost of being slightly more verbose.
  • fix: enable clippy on tests (#870)
    https://github.com/openai/codex/pull/855 added the clippy warning to
    disallow `unwrap()`, but apparently we were not verifying that tests
    were "clippy clean" in CI, so I ended up with a lot of local errors in
    VS Code.
    
    This turns on the check in CI and fixes the offenders.
  • chore: introduce codex-common crate (#843)
    I started this PR because I wanted to share the `format_duration()`
    utility function in `codex-rs/exec/src/event_processor.rs` with the TUI.
    The question was: where to put it?
    
    `core` should have as few dependencies as possible, so moving it there
    would introduce a dependency on `chrono`, which seemed undesirable.
    `core` already had this `cli` feature to deal with a similar situation
    around sharing common utility functions, so I decided to:
    
    * make `core` feature-free
    * introduce `common`
    * `common` can have as many "special interest" features as it needs,
    each of which can declare their own deps
    * the first two features of common are `cli` and `elapsed`
    
    In practice, this meant updating a number of `Cargo.toml` files,
    replacing this line:
    
    ```toml
    codex-core = { path = "../core", features = ["cli"] }
    ```
    
    with these:
    
    ```toml
    codex-core = { path = "../core" }
    codex-common = { path = "../common", features = ["cli"] }
    ```
    
    Moving `format_duration()` into its own file gave it some "breathing
    room" to add a unit test, so I had Codex generate some tests and new
    support for durations over 1 minute.
  • fix: build all crates individually as part of CI (#833)
    I discovered that `cargo build` worked for the entire workspace, but not
    for the `mcp-client` or `core` crates.
    
    * `mcp-client` failed to build because it underspecified the set of
    features it needed from `tokio`.
    * `core` failed to build because it was using a "feature" of its own
    crate in the default, no-feature version.
     
    This PR fixes the builds and adds a check in CI to defend against this
    sort of thing going forward.
  • chore: make build process a single script to run (#757)
    This introduces `./codex-cli/scripts/stage_release.sh`, which is a shell
    script that stages a release for the Node.js module in a temp directory.
    It updates the release to include these native binaries:
    
    ```
    bin/codex-linux-sandbox-arm64
    bin/codex-linux-sandbox-x64
    ```
    
    though this PR does not update Codex CLI to use them yet.
    
    When doing local development, run
    `./codex-cli/scripts/install_native_deps.sh` to install these in your
    own `bin/` folder.
    
    This PR also updates `README.md` to document the new workflow.
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/757).
    * #763
    * __->__ #757
  • chore: mark Rust releases as "prerelease" (#761)
    Apparently the URLs for draft releases cannot be downloaded using
    unauthenticated `curl`, which means the DotSlash file only works for
    users who are authenticated with `gh`. According to chat, prereleases
    _can_ be fetched with unauthenticated `curl`, so let's try that.
  • chore: Rust release, set prerelease:false and version=0.0.2504301132 (#755)
    The generated DotSlash file has URLs that refer to
    `https://github.com/openai/codex/releases/`, so let's set
    `prerelease:false` (but keep `draft:true` for now) so those URLs should
    work.
    
    Also updated `version` in Cargo workspace so I will kick off a build
    once this lands.
  • fix: remove expected dot after v in rust-v tag name (#742)
    I think this extra dot was not intentional, but I'm not sure. Certainly
    this comment suggests it should not be there:
    
    
    https://github.com/openai/codex/blob/85999d72770832e2b1b457401c6c68d86e08344b/.github/workflows/rust-release.yml#L4
  • chore: fix errors in .github/workflows/rust-release.yml and prep 0.0.2504292006 release (#745)
    Apparently I made two key mistakes in
    https://github.com/openai/codex/pull/740 (fixed in this PR):
    
    * I forgot to redefine `$dest` in the `Stage Linux-only artifacts` step
    * I did not define the `if` check correctly in the `Stage Linux-only
    artifacts` step
    
    This fixes both of those issues and bumps the workspace version to
    `0.0.2504292006` in preparation for another release attempt.
  • fix: primary output of the codex-cli crate is named codex, not codex-cli (#743)
    I just got a bunch of failures in the release workflow:
    
    https://github.com/openai/codex/actions/runs/14745492805/job/41391926707
    
    along the lines of:
    
    ```
    cp: cannot stat 'target/aarch64-unknown-linux-gnu/release/codex-cli': No such file or directory
    ```
  • feat: codex-linux-sandbox standalone executable (#740)
    This introduces a standalone executable that run the equivalent of the
    `codex debug landlock` subcommand and updates `rust-release.yml` to
    include it in the release.
    
    The idea is that we will include this small binary with the TypeScript
    CLI to provide support for Linux sandboxing.
  • [codex-rs] Add rust-release action (#671)
    Taking a pass at building artifacts per platform so we can consider
    different distribution strategies that don't require users to install
    the full `cargo` toolchain.
    
    Right now this grabs just the `codex-repl` and `codex-tui` bins for 5
    different targets and bundles them into a draft release. I think a
    clearly marked pre-release set of artifacts will unblock the next step
    of testing.
  • ci: build Rust on Windows as part of CI (#665)
    While we aren't ready to provide Windows binaries of Codex CLI, it seems
    like a good idea to ensure we guard platform-specific code
    appropriately.
  • [codex-rs] CI performance for rust (#639)
    * Refactors the rust-ci into a matrix build
    * Adds directory caching for the build artifacts
    * Adds workflow dispatch for manual testing
  • fix: add RUST_BACKTRACE=full when running cargo test in CI (#638)
    This should provide more information in the event of a failure.
  • fix: only run rust-ci.yml on PRs that modify files in codex-rs (#637)
    The `rust-ci.yml` build appears to be a bit flaky (we're looking into
    it...), so to save TypeScript contributors some noise, restrict the
    `rust-ci.yml` job so that it only runs on PRs that touch files in
    `codex-rs/`.
  • feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)
    As stated in `codex-rs/README.md`:
    
    Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
    run it. For a number of users, this runtime requirement inhibits
    adoption: they would be better served by a standalone executable. As
    maintainers, we want Codex to run efficiently in a wide range of
    environments with minimal overhead. We also want to take advantage of
    operating system-specific APIs to provide better sandboxing, where
    possible.
    
    To that end, we are moving forward with a Rust implementation of Codex
    CLI contained in this folder, which has the following benefits:
    
    - The CLI compiles to small, standalone, platform-specific binaries.
    - Can make direct, native calls to
    [seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
    [landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
    order to support sandboxing on Linux.
    - No runtime garbage collection, resulting in lower memory consumption
    and better, more predictable performance.
    
    Currently, the Rust implementation is materially behind the TypeScript
    implementation in functionality, so continue to use the TypeScript
    implmentation for the time being. We will publish native executables via
    GitHub Releases as soon as we feel the Rust version is usable.
  • add check to ensure ToC in README.md matches headings in the file (#541)
    This introduces a Python script (written by Codex!) to verify that the
    table of contents in the root `README.md` matches the headings. Like
    `scripts/asciicheck.py` in https://github.com/openai/codex/pull/513, it
    reports differences by default (and exits non-zero if there are any) and
    also has a `--fix` option to synchronize the ToC with the headings.
    
    This will be enforced by CI and the changes to `README.md` in this PR
    were generated by the script, so you can see that our ToC was missing
    some entries prior to this PR.
  • Enforce ASCII in README.md (#513)
    This all started because I was going to write a script to autogenerate
    the Table of Contents in the root `README.md`, but I noticed that the
    `href` for the "Why Codex?" heading was `#whycodex` instead of
    `#why-codex`. This piqued my curiosity and it turned out that the space
    in "Why Codex?" was not an ASCII space but **U+00A0**, a non-breaking
    space, and so GitHub ignored it when generating the `href` for the
    heading.
    
    This also meant that when I did a text search for `why codex` in the
    `README.md` in VS Code, the "Why Codex" heading did not match because of
    the presence of **U+00A0**.
    
    In short, these types of Unicode characters seem like a hazard, so I
    decided to introduce this script to flag them, and if desired, to
    replace them with "good enough" ASCII equivalents. For now, this only
    applies to the root `README.md` file, but I think we should ultimately
    apply this across our source code, as well, as we seem to have quite a
    lot of non-ASCII Unicode and it's probably going to cause `rg` to miss
    things.
    
    Contributions of this PR:
    
    * `./scripts/asciicheck.py`, which takes a list of filepaths and returns
    non-zero if any of them contain non-ASCII characters. (Currently, there
    is one exception for  aka **U+2728**, though I would like to default to
    an empty allowlist and then require all exceptions to be specified as
    flags.)
    * A `--fix` option that will attempt to rewrite files with violations
    using a equivalents from a hardcoded substitution list.
    * An update to `ci.yml` to verify `./scripts/asciicheck.py README.md`
    succeeds.
    * A cleanup of `README.md` using the `--fix` option as well as some
    editorial decisions on my part.
    * I tried to update the `href`s in the Table of Contents to reflect the
    changes in the heading titles. (TIL that if a heading has a character
    like `&` surrounded by spaces, it becomes `--` in the generated `href`.)
  • re-enable Prettier check for codex-cli in CI (#417)
    This check was lost in https://github.com/openai/codex/pull/287. Both
    the root folder and `codex-cli/` have their own `pnpm format` commands
    that check the formatting of different things.
    
    Also ran `pnpm format:fix` to fix the formatting violations that got in
    while this was disabled in CI.
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/417).
    * #420
    * #419
    * #416
    * __->__ #417
  • chore: migrate to pnpm for improved monorepo management (#287)
    # Migrate to pnpm for improved monorepo management
    
    ## Summary
    This PR migrates the Codex repository from npm to pnpm, providing faster
    dependency installation, better disk space usage, and improved monorepo
    management.
    
    ## Changes
    - Added `pnpm-workspace.yaml` to define workspace packages
    - Added `.npmrc` with optimal pnpm configuration
    - Updated root package.json with workspace scripts
    - Moved resolutions and overrides to the root package.json
    - Updated scripts to use pnpm instead of npm
    - Added documentation for the migration
    - Updated GitHub Actions workflow for pnpm
    
    ## Benefits
    - **Faster installations**: pnpm is significantly faster than npm
    - **Disk space savings**: pnpm's content-addressable store avoids
    duplication
    - **Strict dependency management**: prevents phantom dependencies
    - **Simplified monorepo management**: better workspace coordination
    - **Preparation for Turborepo**: as discussed, this is the first step
    before adding Turborepo
    
    ## Testing
    - Verified that `pnpm install` works correctly
    - Verified that `pnpm run build` completes successfully
    - Ensured all existing functionality is preserved
    
    ## Documentation
    Added a detailed migration guide in `PNPM_MIGRATION.md` explaining:
    - Why we're migrating to pnpm
    - How to use pnpm with this repository
    - Common commands and workspace-specific commands
    - Monorepo structure and configuration
    
    ## Next Steps
    As discussed, once this change is stable, we can consider adding
    Turborepo as a follow-up enhancement.
  • Initial commit
    Signed-off-by: Ilan Bigio <ilan@openai.com>