2025-12-05 16:24:55 -08:00
|
|
|
set working-directory := "codex-rs"
|
2025-05-30 09:11:53 -07:00
|
|
|
set positional-arguments
|
|
|
|
|
|
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.
2025-04-24 13:31:40 -07:00
|
|
|
# Display help
|
|
|
|
|
help:
|
|
|
|
|
just -l
|
|
|
|
|
|
2025-05-29 15:35:14 -07:00
|
|
|
# `codex`
|
2025-09-26 18:24:01 -07:00
|
|
|
alias c := codex
|
2025-05-29 15:35:14 -07:00
|
|
|
codex *args:
|
2025-05-30 09:11:53 -07:00
|
|
|
cargo run --bin codex -- "$@"
|
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.
2025-04-24 13:31:40 -07:00
|
|
|
|
2025-05-29 15:35:14 -07:00
|
|
|
# `codex exec`
|
|
|
|
|
exec *args:
|
2025-05-30 09:11:53 -07:00
|
|
|
cargo run --bin codex -- exec "$@"
|
2025-05-29 15:35:14 -07:00
|
|
|
|
2025-06-25 13:29:03 -07:00
|
|
|
# Run the CLI version of the file-search crate.
|
|
|
|
|
file-search *args:
|
|
|
|
|
cargo run --bin codex-file-search -- "$@"
|
|
|
|
|
|
2025-11-14 12:39:58 -08:00
|
|
|
# Build the CLI and run the app-server test client
|
|
|
|
|
app-server-test-client *args:
|
|
|
|
|
cargo build -p codex-cli
|
|
|
|
|
cargo run -p codex-app-server-test-client -- --codex-bin ./target/debug/codex "$@"
|
|
|
|
|
|
2025-05-29 15:35:14 -07:00
|
|
|
# format code
|
|
|
|
|
fmt:
|
2026-01-07 12:16:38 +00:00
|
|
|
cargo fmt -- --config imports_granularity=Item 2>/dev/null
|
2025-07-17 11:40:00 -07:00
|
|
|
|
2025-08-20 09:57:55 -07:00
|
|
|
fix *args:
|
2026-02-20 23:02:24 -08:00
|
|
|
cargo clippy --fix --tests --allow-dirty "$@"
|
2025-07-17 11:40:00 -07:00
|
|
|
|
Use released DotSlash package for argument-comment lint (#15199)
## Why
The argument-comment lint now has a packaged DotSlash artifact from
[#15198](https://github.com/openai/codex/pull/15198), so the normal repo
lint path should use that released payload instead of rebuilding the
lint from source every time.
That keeps `just clippy` and CI aligned with the shipped artifact while
preserving a separate source-build path for people actively hacking on
the lint crate.
The current alpha package also exposed two integration wrinkles that the
repo-side prebuilt wrapper needs to smooth over:
- the bundled Dylint library filename includes the host triple, for
example `@nightly-2025-09-18-aarch64-apple-darwin`, and Dylint derives
`RUSTUP_TOOLCHAIN` from that filename
- on Windows, Dylint's driver path also expects `RUSTUP_HOME` to be
present in the environment
Without those adjustments, the prebuilt CI jobs fail during `cargo
metadata` or driver setup. This change makes the checked-in prebuilt
wrapper normalize the packaged library name to the plain
`nightly-2025-09-18` channel before invoking `cargo-dylint`, and it
teaches both the wrapper and the packaged runner source to infer
`RUSTUP_HOME` from `rustup show home` when the environment does not
already provide it.
After the prebuilt Windows lint job started running successfully, it
also surfaced a handful of existing anonymous literal callsites in
`windows-sandbox-rs`. This PR now annotates those callsites so the new
cross-platform lint job is green on the current tree.
## What Changed
- checked in the current
`tools/argument-comment-lint/argument-comment-lint` DotSlash manifest
- kept `tools/argument-comment-lint/run.sh` as the source-build wrapper
for lint development
- added `tools/argument-comment-lint/run-prebuilt-linter.sh` as the
normal enforcement path, using the checked-in DotSlash package and
bundled `cargo-dylint`
- updated `just clippy` and `just argument-comment-lint` to use the
prebuilt wrapper
- split `.github/workflows/rust-ci.yml` so source-package checks live in
a dedicated `argument_comment_lint_package` job, while the released lint
runs in an `argument_comment_lint_prebuilt` matrix on Linux, macOS, and
Windows
- kept the pinned `nightly-2025-09-18` toolchain install in the prebuilt
CI matrix, since the prebuilt package still relies on rustup-provided
toolchain components
- updated `tools/argument-comment-lint/run-prebuilt-linter.sh` to
normalize host-qualified nightly library filenames, keep the `rustup`
shim directory ahead of direct toolchain `cargo` binaries, and export
`RUSTUP_HOME` when needed for Windows Dylint driver setup
- updated `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
so future published DotSlash artifacts apply the same nightly-filename
normalization and `RUSTUP_HOME` inference internally
- fixed the remaining Windows lint violations in
`codex-rs/windows-sandbox-rs` by adding the required `/*param*/`
comments at the reported callsites
- documented the checked-in DotSlash file, wrapper split, archive
layout, nightly prerequisite, and Windows `RUSTUP_HOME` requirement in
`tools/argument-comment-lint/README.md`
2026-03-19 20:19:22 -07:00
|
|
|
clippy *args:
|
2026-02-20 23:02:24 -08:00
|
|
|
cargo clippy --tests "$@"
|
2025-09-26 18:24:01 -07:00
|
|
|
|
2025-07-17 11:40:00 -07:00
|
|
|
install:
|
2025-07-17 15:36:15 -07:00
|
|
|
rustup show active-toolchain
|
2025-07-17 11:40:00 -07:00
|
|
|
cargo fetch
|
2025-09-03 17:05:03 -07:00
|
|
|
|
2025-09-12 08:44:44 -07:00
|
|
|
# Run `cargo nextest` since it's faster than `cargo test`, though including
|
|
|
|
|
# --no-fail-fast is important to ensure all tests are run.
|
|
|
|
|
#
|
|
|
|
|
# Run `cargo install cargo-nextest` if you don't have it installed.
|
2026-02-20 23:02:24 -08:00
|
|
|
# Prefer this for routine local runs; use explicit `cargo test --all-features`
|
|
|
|
|
# only when you specifically need full feature coverage.
|
2025-09-12 08:44:44 -07:00
|
|
|
test:
|
|
|
|
|
cargo nextest run --no-fail-fast
|
|
|
|
|
|
2026-01-13 16:16:22 -08:00
|
|
|
# Build and run Codex from source using Bazel.
|
|
|
|
|
# Note we have to use the combination of `[no-cd]` and `--run_under="cd $PWD &&"`
|
|
|
|
|
# to ensure that Bazel runs the command in the current working directory.
|
|
|
|
|
[no-cd]
|
|
|
|
|
bazel-codex *args:
|
|
|
|
|
bazel run //codex-rs/cli:codex --run_under="cd $PWD &&" -- "$@"
|
|
|
|
|
|
2026-02-13 18:11:19 -08:00
|
|
|
[no-cd]
|
|
|
|
|
bazel-lock-update:
|
|
|
|
|
bazel mod deps --lockfile_mode=update
|
|
|
|
|
|
|
|
|
|
[no-cd]
|
|
|
|
|
bazel-lock-check:
|
|
|
|
|
./scripts/check-module-bazel-lock.sh
|
|
|
|
|
|
feat: add support for building with Bazel (#8875)
This PR configures Codex CLI so it can be built with
[Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
includes configuration so that remote builds can be done using
[BuildBuddy](https://www.buildbuddy.io).
If you are familiar with Bazel, things should work as you expect, e.g.,
run `bazel test //... --keep-going` to run all the tests in the repo,
but we have also added some new aliases in the `justfile` for
convenience:
- `just bazel-test` to run tests locally
- `just bazel-remote-test` to run tests remotely (currently, the remote
build is for x86_64 Linux regardless of your host platform). Note we are
currently seeing the following test failures in the remote build, so we
still need to figure out what is happening here:
```
failures:
suite::compact::manual_compact_twice_preserves_latest_user_messages
suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
```
- `just build-for-release` to build release binaries for all
platforms/architectures remotely
To setup remote execution:
- [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
employees should also request org access at
https://openai.buildbuddy.io/join/ with their `@openai.com` email
address.)
- [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
`~/.bazelrc` (add the line `build
--remote_header=x-buildbuddy-api-key=YOUR_KEY`)
- Use `--config=remote` in your `bazel` invocations (or add `common
--config=remote` to your `~/.bazelrc`, or use the `just` commands)
## CI
In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
(we are working on supporting Windows, but that is not ready yet). Note
that the failures we are seeing in `just bazel-remote-test` do not occur
on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
is green right now.
The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
that macOS CI jobs build _remotely_ on Linux hosts (using the
`docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
root `BUILD.bazel`) using cross-compilation to build the macOS
artifacts. Then these artifacts are downloaded locally to GitHub's macOS
runner so the tests can be executed natively. This is the relevant
config that enables this:
```
common:macos --config=remote
common:macos --strategy=remote
common:macos --strategy=TestRunner=darwin-sandbox,local
```
Because of the remote caching benefits we get from BuildBuddy, these new
CI jobs can be extremely fast! For example, consider these two jobs that
ran all the tests on Linux x86_64:
- Bazel 1m37s
https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
- Cargo 9m20s
https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
For now, we will continue to run both the Bazel and Cargo jobs for PRs,
but once we add support for Windows and running Clippy, we should be
able to cutover to using Bazel exclusively for PRs, which should still
speed things up considerably. We will probably continue to run the Cargo
jobs post-merge for commits that land on `main` as a sanity check.
Release builds will also continue to be done by Cargo for now.
Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
Earlier attempt to add support for Buck2, now abandoned:
https://github.com/openai/codex/pull/8504
---------
Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
Co-authored-by: Michael Bolin <mbolin@openai.com>
2026-01-09 14:09:43 -05:00
|
|
|
bazel-test:
|
|
|
|
|
bazel test //... --keep_going
|
|
|
|
|
|
|
|
|
|
bazel-remote-test:
|
|
|
|
|
bazel test //... --config=remote --platforms=//:rbe --keep_going
|
|
|
|
|
|
|
|
|
|
build-for-release:
|
|
|
|
|
bazel build //codex-rs/cli:release_binaries --config=remote
|
|
|
|
|
|
2025-09-03 17:05:03 -07:00
|
|
|
# Run the MCP server
|
|
|
|
|
mcp-server-run *args:
|
|
|
|
|
cargo run -p codex-mcp-server -- "$@"
|
2026-01-13 10:22:51 -08:00
|
|
|
|
|
|
|
|
# Regenerate the json schema for config.toml from the current config types.
|
|
|
|
|
write-config-schema:
|
|
|
|
|
cargo run -p codex-core --bin codex-write-config-schema
|
2026-01-29 11:11:47 +01:00
|
|
|
|
2026-02-01 23:38:43 -08:00
|
|
|
# Regenerate vendored app-server protocol schema artifacts.
|
2026-02-02 20:30:01 +00:00
|
|
|
write-app-server-schema *args:
|
|
|
|
|
cargo run -p codex-app-server-protocol --bin write_schema_fixtures -- "$@"
|
2026-02-01 23:38:43 -08:00
|
|
|
|
2026-03-09 21:11:31 -07:00
|
|
|
[no-cd]
|
|
|
|
|
write-hooks-schema:
|
|
|
|
|
cargo run --manifest-path ./codex-rs/Cargo.toml -p codex-hooks --bin write_hooks_schema_fixtures
|
|
|
|
|
|
2026-03-14 08:18:04 -07:00
|
|
|
# Run the argument-comment Dylint checks across codex-rs.
|
|
|
|
|
[no-cd]
|
|
|
|
|
argument-comment-lint *args:
|
Use released DotSlash package for argument-comment lint (#15199)
## Why
The argument-comment lint now has a packaged DotSlash artifact from
[#15198](https://github.com/openai/codex/pull/15198), so the normal repo
lint path should use that released payload instead of rebuilding the
lint from source every time.
That keeps `just clippy` and CI aligned with the shipped artifact while
preserving a separate source-build path for people actively hacking on
the lint crate.
The current alpha package also exposed two integration wrinkles that the
repo-side prebuilt wrapper needs to smooth over:
- the bundled Dylint library filename includes the host triple, for
example `@nightly-2025-09-18-aarch64-apple-darwin`, and Dylint derives
`RUSTUP_TOOLCHAIN` from that filename
- on Windows, Dylint's driver path also expects `RUSTUP_HOME` to be
present in the environment
Without those adjustments, the prebuilt CI jobs fail during `cargo
metadata` or driver setup. This change makes the checked-in prebuilt
wrapper normalize the packaged library name to the plain
`nightly-2025-09-18` channel before invoking `cargo-dylint`, and it
teaches both the wrapper and the packaged runner source to infer
`RUSTUP_HOME` from `rustup show home` when the environment does not
already provide it.
After the prebuilt Windows lint job started running successfully, it
also surfaced a handful of existing anonymous literal callsites in
`windows-sandbox-rs`. This PR now annotates those callsites so the new
cross-platform lint job is green on the current tree.
## What Changed
- checked in the current
`tools/argument-comment-lint/argument-comment-lint` DotSlash manifest
- kept `tools/argument-comment-lint/run.sh` as the source-build wrapper
for lint development
- added `tools/argument-comment-lint/run-prebuilt-linter.sh` as the
normal enforcement path, using the checked-in DotSlash package and
bundled `cargo-dylint`
- updated `just clippy` and `just argument-comment-lint` to use the
prebuilt wrapper
- split `.github/workflows/rust-ci.yml` so source-package checks live in
a dedicated `argument_comment_lint_package` job, while the released lint
runs in an `argument_comment_lint_prebuilt` matrix on Linux, macOS, and
Windows
- kept the pinned `nightly-2025-09-18` toolchain install in the prebuilt
CI matrix, since the prebuilt package still relies on rustup-provided
toolchain components
- updated `tools/argument-comment-lint/run-prebuilt-linter.sh` to
normalize host-qualified nightly library filenames, keep the `rustup`
shim directory ahead of direct toolchain `cargo` binaries, and export
`RUSTUP_HOME` when needed for Windows Dylint driver setup
- updated `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
so future published DotSlash artifacts apply the same nightly-filename
normalization and `RUSTUP_HOME` inference internally
- fixed the remaining Windows lint violations in
`codex-rs/windows-sandbox-rs` by adding the required `/*param*/`
comments at the reported callsites
- documented the checked-in DotSlash file, wrapper split, archive
layout, nightly prerequisite, and Windows `RUSTUP_HOME` requirement in
`tools/argument-comment-lint/README.md`
2026-03-19 20:19:22 -07:00
|
|
|
./tools/argument-comment-lint/run-prebuilt-linter.sh "$@"
|
|
|
|
|
|
|
|
|
|
[no-cd]
|
|
|
|
|
argument-comment-lint-from-source *args:
|
2026-03-14 08:18:04 -07:00
|
|
|
./tools/argument-comment-lint/run.sh "$@"
|
|
|
|
|
|
2026-01-29 11:11:47 +01:00
|
|
|
# Tail logs from the state SQLite database
|
|
|
|
|
log *args:
|
|
|
|
|
if [ "${1:-}" = "--" ]; then shift; fi; cargo run -p codex-state --bin logs_client -- "$@"
|