84 Commits

• feat: Ctrl+J for newline in Rust TUI, default to one line of height (#926)

  While the `TextArea` used in the Rust TUI is "multiline," it is not like
  an HTML `<textarea>` in that it does not wrap, so there was not much
  benefit to setting `MIN_TEXTAREA_ROWS` to `3`, so this PR changes it to
  `1`. Though there are now three ways to "increase" the height due to
  actual linebreaks:
  
  * paste in multiline content (this worked before this PR)
  * pressing `Ctrl+J` will insert a newline
  * if you have your terminal emulator set such that it is possible to
  press something that `crossterm` interprets as "Enter plus some
  modifier," then now that will also work
  
  Now things look a bit more compact on startup:
  
  <img width="745" alt="image"
  src="https://github.com/user-attachments/assets/86e2857f-f31c-46f5-a80b-1ab2120b266e"
  />

  Michael Bolin · 2025-05-13 21:42:14 -07:00
  1bf00a3a95
• fix: test_dev_null_write() was not using echo as intended (#923)

  I believe this test meant to verify that echoing content to `/dev/null`
  succeeded, but instead, I believe it was testing the equivalent to `echo
  'blah > /dev/null'`.

  Michael Bolin · 2025-05-13 21:40:26 -07:00
  5bf9445351
• fix: change EventMsg enum so every variant takes a single struct (#925)

  https://github.com/openai/codex/pull/922 did this for the
  `SessionConfigured` enum variant, and I think it is generally helpful to
  be able to work with the values as each enum variant as their own type,
  so this converts the remaining variants and updates all of the
  callsites.
  
  Added a simple unit test to verify that the JSON-serialized version of
  `Event` does not have any unexpected nesting.

  Michael Bolin · 2025-05-13 20:44:42 -07:00
  a5f3a34827
• fix: tighten up some logic around session timestamps and ids (#922)

  * update `SessionConfigured` event to include the UUID for the session
  * show the UUID in the Rust TUI
  * use local timestamps in log files instead of UTC
  * include timestamps in log file names for easier discovery

  Michael Bolin · 2025-05-13 19:22:16 -07:00
  e6c206d19d
• feat: introduce --profile for Rust CLI (#921)

  This introduces a much-needed "profile" concept where users can specify
  a collection of options under one name and then pass that via
  `--profile` to the CLI.
  
  This PR introduces the `ConfigProfile` struct and makes it a field of
  `CargoToml`. It further updates
  `Config::load_from_base_config_with_overrides()` to respect
  `ConfigProfile`, overriding default values where appropriate. A detailed
  unit test is added at the end of `config.rs` to verify this behavior.
  
  Details on how to use this feature have also been added to
  `codex-rs/README.md`.

  Michael Bolin · 2025-05-13 16:52:52 -07:00
  3c03c25e56
• restructure flake for codex-rs (#888)

  Right now since the repo is having two different implementations of
  codex, flake was updated to work with both typescript implementation and
  rust implementation

  Adeeb · 2025-05-13 13:08:42 -07:00
  ae809f3721
• fix: agent instructions were not being included when ~/.codex/instructions.md was empty (#908)

  I had seen issues where `codex-rs` would not always write files without
  me pressuring it to do so, and between that and the report of
  https://github.com/openai/codex/issues/900, I decided to look into this
  further. I found two serious issues with agent instructions:
  
  (1) We were only sending agent instructions on the first turn, but
  looking at the TypeScript code, we should be sending them on every turn.
  
  (2) There was a serious issue where the agent instructions were
  frequently lost:
  
  * The TypeScript CLI appears to keep writing `~/.codex/instructions.md`:
  https://github.com/openai/codex/blob/55142e3e6caddd1e613b71bcb89385ce5cc708bf/codex-cli/src/utils/config.ts#L586
  * If `instructions.md` is present, the Rust CLI uses the contents of it
  INSTEAD OF the default prompt, even if `instructions.md` is empty:
  https://github.com/openai/codex/blob/55142e3e6caddd1e613b71bcb89385ce5cc708bf/codex-rs/core/src/config.rs#L202-L203
  
  The combination of these two things means that I have been using
  `codex-rs` without these key instructions:
  https://github.com/openai/codex/blob/main/codex-rs/core/prompt.md
  
  Looking at the TypeScript code, it appears we should be concatenating
  these three items every time (if they exist):
  
  * `prompt.md`
  * `~/.codex/instructions.md`
  * nearest `AGENTS.md`
  
  This PR fixes things so that:
  
  * `Config.instructions` is `None` if `instructions.md` is empty
  * `Payload.instructions` is now `&'a str` instead of `Option<&'a
  String>` because we should always have _something_ to send
  * `Prompt` now has a `get_full_instructions()` helper that returns a
  `Cow<str>` that will always include the agent instructions first.

  Michael Bolin · 2025-05-12 17:24:44 -07:00
  61b881d4e5
• fix: use "thinking" instead of "codex reasoning" as the label for reasoning events in the TUI (#905)
  Michael Bolin · 2025-05-12 15:19:45 -07:00
  55142e3e6c
• fix: navigate initialization phase before tools/list request in MCP client (#904)

  Apparently the MCP server implemented in JavaScript did not require the
  `initialize` handshake before responding to tool list/call, so I missed
  this.

  Michael Bolin · 2025-05-12 15:15:26 -07:00
  115fb0b95d
• 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
• fix: fix border style for BottomPane (#893)

  This PR fixes things so that:
  
  * when the `BottomPane` is in the `StatusIndicator` state, the border
  should be dim
  * when the `BottomPane` does not have input focus, the border should be
  dim
  
  To make it easier to enforce this invariant, this PR introduces
  `BottomPane::set_state()` that will:
  
  * update `self.state`
  * call `update_border_for_input_focus()`
  * request a repaint
  
  This should make it easier to enforce other updates for state changes
  going forward.

  Michael Bolin · 2025-05-10 23:34:13 -07:00
  a1f51bf91b
• feat: include "reasoning" messages in Rust TUI (#892)

  As shown in the screenshot, we now include reasoning messages from the
  model in the TUI under the heading "codex reasoning":
  
  
  ![image](https://github.com/user-attachments/assets/d8eb3dc3-2f9f-4e95-847e-d24b421249a8)
  
  To ensure these are visible by default when using `o4-mini`, this also
  changes the default value for `summary` (formerly `generate_summary`,
  which is deprecated in favor of `summary` according to the docs) from
  unset to `"auto"`.

  Michael Bolin · 2025-05-10 21:43:27 -07:00
  b4785b5f88
• feat: add support for AGENTS.md in Rust CLI (#885)

  The TypeScript CLI already has support for including the contents of
  `AGENTS.md` in the instructions sent with the first turn of a
  conversation. This PR brings this functionality to the Rust CLI.
  
  To be considered, `AGENTS.md` must be in the `cwd` of the session, or in
  one of the parent folders up to a Git/filesystem root (whichever is
  encountered first).
  
  By default, a maximum of 32 KiB of `AGENTS.md` will be included, though
  this is configurable using the new-in-this-PR `project_doc_max_bytes`
  option in `config.toml`.

  Michael Bolin · 2025-05-10 17:52:59 -07:00
  2b122da087
• feat: experimental env var: CODEX_SANDBOX_NETWORK_DISABLED (#879)

  When using Codex to develop Codex itself, I noticed that sometimes it
  would try to add `#[ignore]` to the following tests:
  
  ```
  keeps_previous_response_id_between_tasks()
  retries_on_early_close()
  ```
  
  Both of these tests start a `MockServer` that launches an HTTP server on
  an ephemeral port and requires network access to hit it, which the
  Seatbelt policy associated with `--full-auto` correctly denies. If I
  wasn't paying attention to the code that Codex was generating, one of
  these `#[ignore]` annotations could have slipped into the codebase,
  effectively disabling the test for everyone.
  
  To that end, this PR enables an experimental environment variable named
  `CODEX_SANDBOX_NETWORK_DISABLED` that is set to `1` if the
  `SandboxPolicy` used to spawn the process does not have full network
  access. I say it is "experimental" because I'm not convinced this API is
  quite right, but we need to start somewhere. (It might be more
  appropriate to have an env var like `CODEX_SANDBOX=full-auto`, but the
  challenge is that our newer `SandboxPolicy` abstraction does not map to
  a simple set of enums like in the TypeScript CLI.)
  
  We leverage this new functionality by adding the following code to the
  aforementioned tests as a way to "dynamically disable" them:
  
  ```rust
  if std::env::var(CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR).is_ok() {
      println!(
          "Skipping test because it cannot execute when network is disabled in a Codex sandbox."
      );
      return;
  }
  ```
  
  We can use the `debug seatbelt --full-auto` command to verify that
  `cargo test` fails when run under Seatbelt prior to this change:
  
  ```
  $ cargo run --bin codex -- debug seatbelt --full-auto -- cargo test
  ---- keeps_previous_response_id_between_tasks stdout ----
  
  thread 'keeps_previous_response_id_between_tasks' panicked at /Users/mbolin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wiremock-0.6.3/src/mock_server/builder.rs:107:46:
  Failed to bind an OS port for a mock server.: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  
  
  failures:
      keeps_previous_response_id_between_tasks
  
  test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
  
  error: test failed, to rerun pass `-p codex-core --test previous_response_id`
  ```
  
  Though after this change, the above command succeeds! This means that,
  going forward, when Codex operates on Codex itself, when it runs `cargo
  test`, only "real failures" should cause the command to fail.
  
  As part of this change, I decided to tighten up the codepaths for
  running `exec()` for shell tool calls. In particular, we do it in `core`
  for the main Codex business logic itself, but we also expose this logic
  via `debug` subcommands in the CLI in the `cli` crate. The logic for the
  `debug` subcommands was not quite as faithful to the true business logic
  as I liked, so I:
  
  * refactored a bit of the Linux code, splitting `linux.rs` into
  `linux_exec.rs` and `landlock.rs` in the `core` crate.
  * gating less code behind `#[cfg(target_os = "linux")]` because such
  code does not get built by default when I develop on Mac, which means I
  either have to build the code in Docker or wait for CI signal
  * introduced `macro_rules! configure_command` in `exec.rs` so we can
  have both sync and async versions of this code. The synchronous version
  seems more appropriate for straight threads or potentially fork/exec.

  Michael Bolin · 2025-05-09 18:29:34 -07:00
  fde48aaa0d
• feat: Allow pasting newlines (#866)

  Noticed that when pasting multi-line blocks, each newline was treated
  like a new submission.
  Update tui to handle Paste directly and map newlines to shift+enter.
  
  # Test
  
  Copied this into clipboard:
  ```
  Do nothing.
  Explain this repo to me.
  ```
  
  Pasted in and saw multi-line input. Hitting Enter then submitted the
  full block.

  jcoens-openai · 2025-05-09 11:33:46 -07:00
  78843c3940
• chore: refactor exec() into spawn_child() and consume_truncated_output() (#878)

  This PR is a straight refactor so that creating the `Child` process for
  an `shell` tool call and consuming its output can be separate concerns.
  For the actual tool call, we will always apply
  `consume_truncated_output()`, but for the top-level debug commands in
  the CLI (e.g., `debug seatbelt` and `debug landlock`), we only want to
  use the `spawn_child()` part of `exec()`.
  
  We want the subcommands to match the `shell` tool call usage as
  faithfully as possible. This becomes more important when we introduce a
  new parameter to `spawn_child()` in
  https://github.com/openai/codex/pull/879.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/878).
  * #879
  * __->__ #878

  Michael Bolin · 2025-05-09 11:03:58 -07:00
  93817643ee
• fix: make McpConnectionManager tolerant of MCPs that fail to start (#854)

  I added a typo in my `config.toml` such that the `command` for one of my
  `mcp_servers` did not exist and I verified that the error was surfaced
  in the TUI (and that I was still able to use Codex).
  
  
  ![image](https://github.com/user-attachments/assets/f13cc08c-f4c6-40ec-9ab4-a9d75e03152f)

  Michael Bolin · 2025-05-08 23:45:54 -07:00
  27198bfe11
• fix: get responses API working again in Rust (#872)

  I inadvertently regressed support for the Responses API when adding
  support for the chat completions API in
  https://github.com/openai/codex/pull/862. This should get both APIs
  working again, but the chat completions codepath seems more complex than
  necessary. I'll try to clean that up shortly, but I want to get things
  working again ASAP.

  Michael Bolin · 2025-05-08 22:49:15 -07:00
  b940adae8e
• feat: support the chat completions API in the Rust CLI (#862)

  This is a substantial PR to add support for the chat completions API,
  which in turn makes it possible to use non-OpenAI model providers (just
  like in the TypeScript CLI):
  
  * It moves a number of structs from `client.rs` to `client_common.rs` so
  they can be shared.
  * It introduces support for the chat completions API in
  `chat_completions.rs`.
  * It updates `ModelProviderInfo` so that `env_key` is `Option<String>`
  instead of `String` (for e.g., ollama) and adds a `wire_api` field
  * It updates `client.rs` to choose between `stream_responses()` and
  `stream_chat_completions()` based on the `wire_api` for the
  `ModelProviderInfo`
  * It updates the `exec` and TUI CLIs to no longer fail if the
  `OPENAI_API_KEY` environment variable is not set
  * It updates the TUI so that `EventMsg::Error` is displayed more
  prominently when it occurs, particularly now that it is important to
  alert users to the `CodexErr::EnvVar` variant.
  * `CodexErr::EnvVar` was updated to include an optional `instructions`
  field so we can preserve the behavior where we direct users to
  https://platform.openai.com if `OPENAI_API_KEY` is not set.
  * Cleaned up the "welcome message" in the TUI to ensure the model
  provider is displayed.
  * Updated the docs in `codex-rs/README.md`.
  
  To exercise the chat completions API from OpenAI models, I added the
  following to my `config.toml`:
  
  ```toml
  model = "gpt-4o"
  model_provider = "openai-chat-completions"
  
  [model_providers.openai-chat-completions]
  name = "OpenAI using Chat Completions"
  base_url = "https://api.openai.com/v1"
  env_key = "OPENAI_API_KEY"
  wire_api = "chat"
  ```
  
  Though to test a non-OpenAI provider, I installed ollama with mistral
  locally on my Mac because ChatGPT said that would be a good match for my
  hardware:
  
  ```shell
  brew install ollama
  ollama serve
  ollama pull mistral
  ```
  
  Then I added the following to my `~/.codex/config.toml`:
  
  ```toml
  model = "mistral"
  model_provider = "ollama"
  ```
  
  Note this code could certainly use more test coverage, but I want to get
  this in so folks can start playing with it.
  
  For reference, I believe https://github.com/openai/codex/pull/247 was
  roughly the comparable PR on the TypeScript side.

  Michael Bolin · 2025-05-08 21:46:06 -07:00
  e924070cee
• 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.

  Michael Bolin · 2025-05-08 16:02:56 -07:00
  a9adb4175c
• fix: remove wrapping in Rust TUI that was incompatible with scrolling math (#868)

  I noticed that sometimes I would enter a new message, but it would not
  show up in the conversation history. Even if I focused the conversation
  history and tried to scroll it to the bottom, I could not bring it into
  view. At first, I was concerned that messages were not making it to the
  UI layer, but I added debug statements and verified that was not the
  issue.
  
  It turned out that, previous to this PR, lines that are wider than the
  viewport take up multiple lines of vertical space because `wrap()` was
  set on the `Paragraph` inside the scroll pane. Unfortunately, that broke
  our "scrollbar math" that assumed each `Line` contributes one line of
  height in the UI.
  
  This PR removes the `wrap()`, but introduces a new issue, which is that
  now you cannot see long lines without resizing your terminal window. For
  now, I filed an issue here:
  
  https://github.com/openai/codex/issues/869
  
  I think the long-term fix is to fix our math so it calculates the height
  of a `Line` after it is wrapped given the current width of the viewport.

  Michael Bolin · 2025-05-08 15:17:17 -07:00
  699ec5a87f
• 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
• fix: remove clap dependency from core crate (#860)
  Michael Bolin · 2025-05-07 19:33:09 -07:00
  9fdf2fa066
• feat: read model_provider and model_providers from config.toml (#853)

  This is the first step in supporting other model providers in the Rust
  CLI. Specifically, this PR adds support for the new entries in `Config`
  and `ConfigOverrides` to specify a `ModelProviderInfo`, which is the
  basic config needed for an LLM provider. This PR does not get us all the
  way there yet because `client.rs` still categorically appends
  `/responses` to the URL and expects the endpoint to support the OpenAI
  Responses API. Will fix that next!

  Michael Bolin · 2025-05-07 17:38:28 -07:00
  86022f097e
• fix: creating an instance of Codex requires a Config (#859)

  I discovered that I accidentally introduced a change in
  https://github.com/openai/codex/pull/829 where we load a fresh `Config`
  in the middle of `codex.rs`:
  
  
  https://github.com/openai/codex/blob/c3e10e180a341e719f61014ea508f6d9dbffe05b/codex-rs/core/src/codex.rs#L515-L522
  
  This is not good because the `Config` could differ from the one that has
  the user's overrides specified from the CLI. Also, in unit tests, it
  means the `Config` was picking up my personal settings as opposed to
  using a vanilla config, which was problematic.
  
  This PR cleans things up by moving the common case where
  `Op::ConfigureSession` is derived from `Config` (originally done in
  `codex_wrapper.rs`) and making it the standard way to initialize `Codex`
  by putting it in `Codex::spawn()`. Note this also eliminates quite a bit
  of boilerplate from the tests and relieves the caller of the
  responsibility of minting out unique IDs when invoking `submit()`.

  Michael Bolin · 2025-05-07 16:33:28 -07:00
  cfe50c7107
• fix: remove CodexBuilder and Recorder (#858)

  These abstractions were originally created exclusively for the REPL,
  which was removed in https://github.com/openai/codex/pull/754.
  Currently, the create some unnecessary Tokio tasks, so we are better off
  without them. (We can always bring this back if we have a new use case.)

  Michael Bolin · 2025-05-07 16:11:42 -07:00
  c3e10e180a
• feat: save session transcripts when using Rust CLI (#845)

  This adds support for saving transcripts when using the Rust CLI. Like
  the TypeScript CLI, it saves the transcript to `~/.codex/sessions`,
  though it uses JSONL for the file format (and `.jsonl` for the file
  extension) so that even if Codex crashes, what was written to the
  `.jsonl` file should generally still be valid JSONL content.

  Michael Bolin · 2025-05-07 13:49:15 -07:00
  42617f8726
• fix: add optional timeout to McpClient::send_request() (#852)

  We now impose a 10s timeout on the initial `tools/list` request to an
  MCP server. We do not apply a timeout for other types of requests yet,
  but we should start enforcing those, as well.

  Michael Bolin · 2025-05-07 12:56:38 -07:00
  9da6ebef3f
• feat: introduce the use of tui-markdown (#851)

  This introduces the use of the `tui-markdown` crate to parse an
  assistant message as Markdown and style it using ANSI for a better user
  experience. As shown in the screenshot below, it has support for syntax
  highlighting for _tagged_ fenced code blocks:
  
  <img width="907" alt="image"
  src="https://github.com/user-attachments/assets/900dc229-80bb-46e8-b1bb-efee4c70ba3c"
  />
  
  That said, `tui-markdown` is not as configurable (or stylish!) as
  https://www.npmjs.com/package/marked-terminal, which is what we use in
  the TypeScript CLI. In particular:
  
  * The styles are hardcoded and `tui_markdown::from_str()` does not take
  any options whatsoever. It uses "bold white" for inline code style which
  does not stand out as much as the yellow used by `marked-terminal`:
  
  
  https://github.com/joshka/tui-markdown/blob/65402cbda70325f34e7ddf6fe1ec629bcd9459cf/tui-markdown/src/lib.rs#L464
  
  I asked Codex to take a first pass at this and it came up with:
  
  https://github.com/joshka/tui-markdown/pull/80
  
  * If a fenced code block is not tagged, then it does not get
  highlighted. I would rather add some logic here:
  
  
  https://github.com/joshka/tui-markdown/blob/65402cbda70325f34e7ddf6fe1ec629bcd9459cf/tui-markdown/src/lib.rs#L262
  
  that uses something like https://pypi.org/project/guesslang/ to examine
  the value of `text` and try to use the appropriate syntax highlighter.
  
  * When we have a fenced code block, we do not want to show the opening
  and closing triple backticks in the output.
  
  To unblock ourselves, we might want to bundle our own fork of
  `tui-markdown` temporarily until we figure out what the shape of the API
  should be and then try to upstream it.

  Michael Bolin · 2025-05-07 10:46:32 -07:00
  0360b4d0d7
• Update submodules version to come from the workspace (#850)

  Tie the version of submodules to the workspace version.

  jcoens-openai · 2025-05-07 10:08:06 -07:00
  a080d7b0fd
• 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: show MCP tool calls in codex exec subcommand (#841)

  This is analogous to the change for the TUI in
  https://github.com/openai/codex/pull/836, but for `codex exec`.
  
  To test, I ran:
  
  ```
  cargo run --bin codex-exec -- 'what is the weather in wellesley ma tomorrow'
  ```
  
  and saw:
  
  
  ![image](https://github.com/user-attachments/assets/5714e07f-88c7-4dd9-aa0d-be54c1670533)

  Michael Bolin · 2025-05-06 16:52:43 -07:00
  7d8b38b37b
• feat: drop support for q in the Rust TUI since we already support ctrl+d (#799)

  Out of the box, we will make `/` the only official "escape sequence" for
  commands in the Rust TUI. We will look to support `q` (or any string you
  want to use as a "macro") via a plugin, but not make it part of the
  default experience.
  
  Existing `q` users will have to get by with `ctrl+d` for now.

  Michael Bolin · 2025-05-06 16:34:17 -07:00
  6f87f4c69f
• fix: make all fields of Session struct private again (#840)

  https://github.com/openai/codex/pull/829 noted it introduced a circular
  dep between `codex.rs` and `mcp_tool_call.rs`. This attempts to clean
  things up: the circular dep still exists, but at least all the fields of
  `Session` are private again.

  Michael Bolin · 2025-05-06 16:21:35 -07:00
  aa36a15f9f
• feat: show MCP tool calls in TUI (#836)

  Adds logic for the `McpToolCallBegin` and `McpToolCallEnd` events in
  `codex-rs/tui/src/chatwidget.rs` so they get entries in the conversation
  history in the TUI.
  
  Building on top of https://github.com/openai/codex/pull/829, here is the
  result of running:
  
  ```
  cargo run --bin codex -- 'what is the weather in san francisco tomorrow'
  ```
  
  
  ![image](https://github.com/user-attachments/assets/db4a79bb-4988-46cb-acb2-446d5ba9e058)

  Michael Bolin · 2025-05-06 16:12:15 -07:00
  88e7ca5f2b
• feat: support mcp_servers in config.toml (#829)

  This adds initial support for MCP servers in the style of Claude Desktop
  and Cursor. Note this PR is the bare minimum to get things working end
  to end: all configured MCP servers are launched every time Codex is run,
  there is no recovery for MCP servers that crash, etc.
  
  (Also, I took some shortcuts to change some fields of `Session` to be
  `pub(crate)`, which also means there are circular deps between
  `codex.rs` and `mcp_tool_call.rs`, but I will clean that up in a
  subsequent PR.)
  
  `codex-rs/README.md` is updated as part of this PR to explain how to use
  this feature. There is a bit of plumbing to route the new settings from
  `Config` to the business logic in `codex.rs`. The most significant
  chunks for new code are in `mcp_connection_manager.rs` (which defines
  the `McpConnectionManager` struct) and `mcp_tool_call.rs`, which is
  responsible for tool calls.
  
  This PR also introduces new `McpToolCallBegin` and `McpToolCallEnd`
  event types to the protocol, but does not add any handlers for them.
  (See https://github.com/openai/codex/pull/836 for initial usage.)
  
  To test, I added the following to my `~/.codex/config.toml`:
  
  ```toml
  # Local build of https://github.com/hideya/mcp-server-weather-js
  [mcp_servers.weather]
  command = "/Users/mbolin/code/mcp-server-weather-js/dist/index.js"
  args = []
  ```
  
  And then I ran the following:
  
  ```
  codex-rs$ cargo run --bin codex exec 'what is the weather in san francisco'
  [2025-05-06T22:40:05] Task started: 1
  [2025-05-06T22:40:18] Agent message: Here’s the latest National Weather Service forecast for San Francisco (downtown, near 37.77° N, 122.42° W):
  
  This Afternoon (Tue):
  • Sunny, high near 69 °F
  • West-southwest wind around 12 mph
  
  Tonight:
  • Partly cloudy, low around 52 °F
  • SW wind 7–10 mph
  ...
  ```
  
  Note that Codex itself is not able to make network calls, so it would
  not normally be able to get live weather information like this. However,
  the weather MCP is [currently] not run under the Codex sandbox, so it is
  able to hit `api.weather.gov` and fetch current weather information.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/829).
  * #836
  * __->__ #829

  Michael Bolin · 2025-05-06 15:47:59 -07:00
  147a940449
• 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.

  Michael Bolin · 2025-05-06 12:02:49 -07:00
  49d040215a
• feat: update McpClient::new_stdio_client() to accept an env (#831)

  Cleans up the signature for `new_stdio_client()` to more closely mirror
  how MCP servers are declared in config files (`command`, `args`, `env`).
  Also takes a cue from Claude Code where the MCP server is launched with
  a restricted `env` so that it only includes "safe" things like `USER`
  and `PATH` (see the `create_env_for_mcp_server()` function introduced in
  this PR for details) by default, as it is common for developers to have
  sensitive API keys present in their environment that should only be
  forwarded to the MCP server when the user has explicitly configured it
  to do so.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/831).
  * #829
  * __->__ #831

  Michael Bolin · 2025-05-06 11:14:47 -07:00
  5f1b8f707c
• 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: make Codex available as a tool when running it as an MCP server (#811)

  This PR replaces the placeholder `"echo"` tool call in the MCP server
  with a `"codex"` tool that calls Codex. Events such as
  `ExecApprovalRequest` and `ApplyPatchApprovalRequest` are not handled
  properly yet, but I have `approval_policy = "never"` set in my
  `~/.codex/config.toml` such that those codepaths are not exercised.
  
  The schema for this MPC tool is defined by a new `CodexToolCallParam`
  struct introduced in this PR. It is fairly similar to `ConfigOverrides`,
  as the param is used to help create the `Config` used to start the Codex
  session, though it also includes the `prompt` used to kick off the
  session.
  
  This PR also introduces the use of the third-party `schemars` crate to
  generate the JSON schema, which is verified in the
  `verify_codex_tool_json_schema()` unit test.
  
  Events that are dispatched during the Codex session are sent back to the
  MCP client as MCP notifications. This gives the client a way to monitor
  progress as the tool call itself may take minutes to complete depending
  on the complexity of the task requested by the user.
  
  In the video below, I launched the server via:
  
  ```shell
  mcp-server$ RUST_LOG=debug npx @modelcontextprotocol/inspector cargo run --
  ```
  
  In the video, you can see the flow of:
  
  * requesting the list of tools
  * choosing the **codex** tool
  * entering a value for **prompt** and then making the tool call
  
  Note that I left the other fields blank because when unspecified, the
  values in my `~/.codex/config.toml` were used:
  
  
  https://github.com/user-attachments/assets/1975058c-b004-43ef-8c8d-800a953b8192
  
  Note that while using the inspector, I did run into
  https://github.com/modelcontextprotocol/inspector/issues/293, though the
  tip about ensuring I had only one instance of the **MCP Inspector** tab
  open in my browser seemed to fix things.

  Michael Bolin · 2025-05-05 07:16:19 -07:00
  2b72d05c5e
• fix: ensure apply_patch resolves relative paths against workdir or project cwd (#810)

  https://github.com/openai/codex/pull/800 kicked off some work to be more
  disciplined about honoring the `cwd` param passed in rather than
  assuming `std::env::current_dir()` as the `cwd`. As part of this, we
  need to ensure `apply_patch` calls honor the appropriate `cwd` as well,
  which is significant if the paths in the `apply_patch` arg are not
  absolute paths themselves. Failing that:
  
  - The `apply_patch` function call can contain an optional`workdir`
  param, so:
  - If specified and is an absolute path, it should be used to resolve
  relative paths
  - If specified and is a relative path, should be resolved against
  `Config.cwd` and then any relative paths will be resolved against the
  result
  - If `workdir` is not specified on the function call, relative paths
  should be resolved against `Config.cwd`
  
  Note that we had a similar issue in the TypeScript CLI that was fixed in
  https://github.com/openai/codex/pull/556.
  
  As part of the fix, this PR introduces `ApplyPatchAction` so clients can
  deal with that instead of the raw `HashMap<PathBuf,
  ApplyPatchFileChange>`. This enables us to enforce, by construction,
  that all paths contained in the `ApplyPatchAction` are absolute paths.

  Michael Bolin · 2025-05-04 12:32:51 -07:00
  5d924d44cf
• fix: is_inside_git_repo should take the directory as a param (#809)

  https://github.com/openai/codex/pull/800 made `cwd` a property of
  `Config` and made it so the `cwd` is not necessarily
  `std::env::current_dir()`. As such, `is_inside_git_repo()` should check
  `Config.cwd` rather than `std::env::current_dir()`.
  
  This PR updates `is_inside_git_repo()` to take `Config` instead of an
  arbitrary `PathBuf` to force the check to operate on a `Config` where
  `cwd` has been resolved to what the user specified.

  Michael Bolin · 2025-05-04 11:39:10 -07:00
  a134bdde49
• fix: TUI should use cwd from Config (#808)

  https://github.com/openai/codex/pull/800 made `cwd` a property of
  `Config`, so the TUI should use this instead of running
  `std::env::current_dir()`.

  Michael Bolin · 2025-05-04 11:12:40 -07:00
  cd12f0c24a
• feat: make cwd a required field of Config so we stop assuming std::env::current_dir() in a session (#800)

  In order to expose Codex via an MCP server, I realized that we should be
  taking `cwd` as a parameter rather than assuming
  `std::env::current_dir()` as the `cwd`. Specifically, the user may want
  to start a session in a directory other than the one where the MCP
  server has been started.
  
  This PR makes `cwd: PathBuf` a required field of `Session` and threads
  it all the way through, though I think there is still an issue with not
  honoring `workdir` for `apply_patch`, which is something we also had to
  fix in the TypeScript version: https://github.com/openai/codex/pull/556.
  
  This also adds `-C`/`--cd` to change the cwd via the command line.
  
  To test, I ran:
  
  ```
  cargo run --bin codex -- exec -C /tmp 'show the output of ls'
  ```
  
  and verified it showed the contents of my `/tmp` folder instead of
  `$PWD`.

  Michael Bolin · 2025-05-04 10:57:12 -07:00
  421e159888
• doc: update the config.toml documentation for the Rust CLI in codex-rs/README.md (#795)

  https://github.com/openai/codex/pull/793 had important information on
  the `notify` config option that seemed worth memorializing, so this PR
  updates the documentation about all of the configurable options in
  `~/.codex/config.toml`.

  Michael Bolin · 2025-05-02 20:32:24 -07:00
  0442458309
• feat: configurable notifications in the Rust CLI (#793)

  With this change, you can specify a program that will be executed to get
  notified about events generated by Codex. The notification info will be
  packaged as a JSON object. The supported notification types are defined
  by the `UserNotification` enum introduced in this PR. Initially, it
  contains only one variant, `AgentTurnComplete`:
  
  ```rust
  pub(crate) enum UserNotification {
      #[serde(rename_all = "kebab-case")]
      AgentTurnComplete {
          turn_id: String,
  
          /// Messages that the user sent to the agent to initiate the turn.
          input_messages: Vec<String>,
  
          /// The last message sent by the assistant in the turn.
          last_assistant_message: Option<String>,
      },
  }
  ```
  
  This is intended to support the common case when a "turn" ends, which
  often means it is now your chance to give Codex further instructions.
  
  For example, I have the following in my `~/.codex/config.toml`:
  
  ```toml
  notify = ["python3", "/Users/mbolin/.codex/notify.py"]
  ```
  
  I created my own custom notifier script that calls out to
  [terminal-notifier](https://github.com/julienXX/terminal-notifier) to
  show a desktop push notification on macOS. Contents of `notify.py`:
  
  ```python
  #!/usr/bin/env python3
  
  import json
  import subprocess
  import sys
  
  
  def main() -> int:
      if len(sys.argv) != 2:
          print("Usage: notify.py <NOTIFICATION_JSON>")
          return 1
  
      try:
          notification = json.loads(sys.argv[1])
      except json.JSONDecodeError:
          return 1
  
      match notification_type := notification.get("type"):
          case "agent-turn-complete":
              assistant_message = notification.get("last-assistant-message")
              if assistant_message:
                  title = f"Codex: {assistant_message}"
              else:
                  title = "Codex: Turn Complete!"
              input_messages = notification.get("input_messages", [])
              message = " ".join(input_messages)
              title += message
          case _:
              print(f"not sending a push notification for: {notification_type}")
              return 0
  
      subprocess.check_output(
          [
              "terminal-notifier",
              "-title",
              title,
              "-message",
              message,
              "-group",
              "codex",
              "-ignoreDnD",
              "-activate",
              "com.googlecode.iterm2",
          ]
      )
  
      return 0
  
  
  if __name__ == "__main__":
      sys.exit(main())
  ```
  
  For reference, here are related PRs that tried to add this functionality
  to the TypeScript version of the Codex CLI:
  
  * https://github.com/openai/codex/pull/160
  * https://github.com/openai/codex/pull/498

  Michael Bolin · 2025-05-02 19:48:13 -07:00
  a180ed44e8
• 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
• fix: mcp-types serialization wasn't quite working (#791)

  While creating a basic MCP server in
  https://github.com/openai/codex/pull/792, I discovered a number of bugs
  with the initial `mcp-types` crate that I needed to fix in order to
  implement the server.
  
  For example, I discovered that when serializing a message, `"jsonrpc":
  "2.0"` was not being included.
  
  I changed the codegen so that the field is added as:
  
  ```rust
      #[serde(rename = "jsonrpc", default = "default_jsonrpc")]
      pub jsonrpc: String,
  ```
  
  This ensures that the field is serialized as `"2.0"`, though the field
  still has to be assigned, which is tedious. I may experiment with
  `Default` or something else in the future. (I also considered creating a
  custom serializer, but I'm not sure it's worth the trouble.)
  
  While here, I also added `MCP_SCHEMA_VERSION` and `JSONRPC_VERSION` as
  `pub const`s for the crate.
  
  I also discovered that MCP rejects sending `null` for optional fields,
  so I had to add `#[serde(skip_serializing_if = "Option::is_none")]` on
  `Option` fields.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/791).
  * #792
  * __->__ #791

  Michael Bolin · 2025-05-02 16:38:05 -07:00
  865e518771
• 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