19 Commits

• Disallow expect via lints (#865)

  Adds `expect()` as a denied lint. Same deal applies with `unwrap()`
  where we now need to put `#[expect(...` on ones that we legit want. Took
  care to enable `expect()` in test contexts.
  
  # Tests
  
  ```
  cargo fmt
  cargo clippy --all-features --all-targets --no-deps -- -D warnings
  cargo test
  ```

  jcoens-openai · 2025-05-12 08:45:46 -07:00
  f3bd143867
• Workspace lints and disallow unwrap (#855)

  Sets submodules to use workspace lints. Added denying unwrap as a
  workspace level lint, which found a couple of cases where we could have
  propagated errors. Also manually labeled ones that were fine by my eye.

  jcoens-openai · 2025-05-08 09:46:18 -07:00
  87cf120873
• Update cargo to 2024 edition (#842)

  Some effects of this change:
  - New formatting changes across many files. No functionality changes
  should occur from that.
  - Calls to `set_env` are considered unsafe, since this only happens in
  tests we wrap them in `unsafe` blocks

  jcoens-openai · 2025-05-07 08:37:48 -07:00
  8a89d3aeda
• 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.

  Michael Bolin · 2025-05-06 17:38:56 -07:00
  c577e94b67
• feat: initial McpClient for Rust (#822)

  This PR introduces an initial `McpClient` that we will use to give Codex
  itself programmatic access to foreign MCPs. This does not wire it up in
  Codex itself yet, but the new `mcp-client` crate includes a `main.rs`
  for basic testing for now.
  
  Manually tested by sending a `tools/list` request to Codex's own MCP
  server:
  
  ```
  codex-rs$ cargo build
  codex-rs$ cargo run --bin codex-mcp-client ./target/debug/codex-mcp-server
  {
    "tools": [
      {
        "description": "Run a Codex session. Accepts configuration parameters matching the Codex Config struct.",
        "inputSchema": {
          "properties": {
            "approval-policy": {
              "description": "Execution approval policy expressed as the kebab-case variant name (`unless-allow-listed`, `auto-edit`, `on-failure`, `never`).",
              "enum": [
                "auto-edit",
                "unless-allow-listed",
                "on-failure",
                "never"
              ],
              "type": "string"
            },
            "cwd": {
              "description": "Working directory for the session. If relative, it is resolved against the server process's current working directory.",
              "type": "string"
            },
            "disable-response-storage": {
              "description": "Disable server-side response storage.",
              "type": "boolean"
            },
            "model": {
              "description": "Optional override for the model name (e.g. \"o3\", \"o4-mini\")",
              "type": "string"
            },
            "prompt": {
              "description": "The *initial user prompt* to start the Codex conversation.",
              "type": "string"
            },
            "sandbox-permissions": {
              "description": "Sandbox permissions using the same string values accepted by the CLI (e.g. \"disk-write-cwd\", \"network-full-access\").",
              "items": {
                "enum": [
                  "disk-full-read-access",
                  "disk-write-cwd",
                  "disk-write-platform-user-temp-folder",
                  "disk-write-platform-global-temp-folder",
                  "disk-full-write-access",
                  "network-full-access"
                ],
                "type": "string"
              },
              "type": "array"
            }
          },
          "required": [
            "prompt"
          ],
          "type": "object"
        },
        "name": "codex"
      }
    ]
  }
  ```

  Michael Bolin · 2025-05-05 12:52:55 -07:00
  2cf7aeeeb6
• feat: introduce mcp-server crate (#792)

  This introduces the `mcp-server` crate, which contains a barebones MCP
  server that provides an `echo` tool that echoes the user's request back
  to them.
  
  To test it out, I launched
  [modelcontextprotocol/inspector](https://github.com/modelcontextprotocol/inspector)
  like so:
  
  ```
  mcp-server$ npx @modelcontextprotocol/inspector cargo run --
  ```
  
  and opened up `http://127.0.0.1:6274` in my browser:
  
  
  ![image](https://github.com/user-attachments/assets/83fc55d4-25c2-4497-80cd-e9702283ff93)
  
  I also had to make a small fix to `mcp-types`, adding
  `#[serde(untagged)]` to a number of `enum`s.

  Michael Bolin · 2025-05-02 17:25:58 -07:00
  21cd953dbd
• feat: introduce mcp-types crate (#787)

  This adds our own `mcp-types` crate to our Cargo workspace. We vendor in
  the
  [`2025-03-26/schema.json`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/05f204513641c05bd78d056791af99c6c84520fa/schema/2025-03-26/schema.json)
  from the MCP repo and introduce a `generate_mcp_types.py` script to
  codegen the `lib.rs` from the JSON schema.
  
  Test coverage is currently light, but I plan to refine things as we
  start making use of this crate.
  
  And yes, I am aware that
  https://github.com/modelcontextprotocol/rust-sdk exists, though the
  published https://crates.io/crates/rmcp appears to be a competing
  effort. While things are up in the air, it seems better for us to
  control our own version of this code.
  
  Incidentally, Codex did a lot of the work for this PR. I told it to
  never edit `lib.rs` directly and instead to update
  `generate_mcp_types.py` and then re-run it to update `lib.rs`. It
  followed these instructions and once things were working end-to-end, I
  iteratively asked for changes to the tests until the API looked
  reasonable (and the code worked). Codex was responsible for figuring out
  what to do to `generate_mcp_types.py` to achieve the requested test/API
  changes.

  Michael Bolin · 2025-05-02 13:33:14 -07:00
  83961e0299
• chore: script to create a Rust release (#759)

  For now, keep things simple such that we never update the `version` in
  the `Cargo.toml` for the workspace root on the `main` branch. Instead,
  create a new branch for a release, push one commit that updates the
  `version`, and then tag that branch to kick off a release.
  
  To test, I ran this script and created this release job:
  
  https://github.com/openai/codex/actions/runs/14762580641

  Michael Bolin · 2025-04-30 12:39:03 -07:00
  b571249867
• 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.

  Michael Bolin · 2025-04-30 11:53:03 -07:00
  8f7a54501c
• chore: remove the REPL crate/subcommand (#754)

  @oai-ragona and I discussed it, and we feel the REPL crate has served
  its purpose, so we're going to delete the code and future archaeologists
  can find it in Git history.

  Michael Bolin · 2025-04-30 10:15:50 -07:00
  c432d9ef81
• fix: add another place where $dest was missing in rust-release.yml (#747)

  I thought https://github.com/openai/codex/pull/745 was the last fix I
  needed, but apparently not.

  Michael Bolin · 2025-04-29 20:23:54 -07:00
  e42dacbdc8
• 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.

  Michael Bolin · 2025-04-29 20:12:23 -07:00
  5122fe647f
• chore: set Cargo workspace to version 0.0.2504291954 to create a scratch release (#744)
  Michael Bolin · 2025-04-29 19:56:30 -07:00
  1a39568e03
• chore: set Cargo workspace to version 0.0.2504291926 to create a scratch release (#741)

  Needed to exercise the new release process in
  https://github.com/openai/codex/pull/671.

  Michael Bolin · 2025-04-29 19:35:37 -07:00
  85999d7277
• 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.

  Michael Bolin · 2025-04-29 19:21:26 -07:00
  411bfeb410
• [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.

  oai-ragona · 2025-04-29 16:38:47 -07:00
  cb0b0259f4
• fix: make the TUI the default/"interactive" CLI in Rust (#711)

  Originally, the `interactive` crate was going to be a placeholder for
  building out a UX that was comparable to that of the existing TypeScript
  CLI. Though after researching how Ratatui works, that seems difficult to
  do because it is designed around the idea that it will redraw the full
  screen buffer each time (and so any scrolling should be "internal" to
  your Ratatui app) whereas the TypeScript CLI expects to render the full
  history of the conversation every time(*) (which is why you can use your
  terminal scrollbar to scroll it).
  
  While it is possible to use Ratatui in a way that acts more like what
  the TypeScript CLI is doing, it is awkward and seemingly results in
  tedious code, so I think we should abandon that approach. As such, this
  PR deletes the `interactive/` folder and the code that depended on it.
  
  Further, since we added support for mousewheel scrolling in the TUI in
  https://github.com/openai/codex/pull/641, it certainly feels much better
  and the need for scroll support via the terminal scrollbar is greatly
  diminished. This is now a more appropriate default UX for the
  "multitool" CLI.
  
  (*) Incidentally, I haven't verified this, but I think this results in
  O(N^2) work in rendering, which seems potentially problematic for long
  conversations.

  Michael Bolin · 2025-04-28 13:46:22 -07:00
  cca1122ddc
• feat: introduce codex_execpolicy crate for defining "safe" commands (#634)

  As described in detail in `codex-rs/execpolicy/README.md` introduced in
  this PR, `execpolicy` is a tool that lets you define a set of _patterns_
  used to match [`execv(3)`](https://linux.die.net/man/3/execv)
  invocations. When a pattern is matched, `execpolicy` returns the parsed
  version in a structured form that is amenable to static analysis.
  
  The primary use case is to define patterns match commands that should be
  auto-approved by a tool such as Codex. This supports a richer pattern
  matching mechanism that the sort of prefix-matching we have done to
  date, e.g.:
  
  
  https://github.com/openai/codex/blob/5e40d9d2211737f46136610497bcd9a8271009e0/codex-cli/src/approvals.ts#L333-L354
  
  Note we are still playing with the API and the `system_path` option in
  particular still needs some work.

  Michael Bolin · 2025-04-24 17:14:47 -07:00
  58f0e5ab74
• 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.

  Michael Bolin · 2025-04-24 13:31:40 -07:00
  31d0d7a305