307 Commits

This Branch

This Branch

All Branches

• 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
• Adds Azure OpenAI support (#769)

  ## Summary
  
  This PR introduces support for Azure OpenAI as a provider within the
  Codex CLI. Users can now configure the tool to leverage their Azure
  OpenAI deployments by specifying `"azure"` as the provider in
  `config.json` and setting the corresponding `AZURE_OPENAI_API_KEY` and
  `AZURE_OPENAI_API_VERSION` environment variables. This functionality is
  added alongside the existing provider options (OpenAI, OpenRouter,
  etc.).
  
  Related to #92
  
  **Note:** This PR is currently in **Draft** status because tests on the
  `main` branch are failing. It will be marked as ready for review once
  the `main` branch is stable and tests are passing.
  
  ---
  
  ## What’s Changed
  
  -   **Configuration (`config.ts`, `providers.ts`, `README.md`):**
  - Added `"azure"` to the supported `providers` list in `providers.ts`,
  specifying its name, default base URL structure, and environment
  variable key (`AZURE_OPENAI_API_KEY`).
  - Defined the `AZURE_OPENAI_API_VERSION` environment variable in
  `config.ts` with a default value (`2025-03-01-preview`).
      -   Updated `README.md` to:
          -   Include "azure" in the list of providers.
  - Add a configuration section for Azure OpenAI, detailing the required
  environment variables (`AZURE_OPENAI_API_KEY`,
  `AZURE_OPENAI_API_VERSION`) with examples.
  - **Client Instantiation (`terminal-chat.tsx`, `singlepass-cli-app.tsx`,
  `agent-loop.ts`, `compact-summary.ts`, `model-utils.ts`):**
  - Modified various components and utility functions where the OpenAI
  client is initialized.
  - Added conditional logic to check if the configured `provider` is
  `"azure"`.
  - If the provider is Azure, the `AzureOpenAI` client from the `openai`
  package is instantiated, using the configured `baseURL`, `apiKey` (from
  `AZURE_OPENAI_API_KEY`), and `apiVersion` (from
  `AZURE_OPENAI_API_VERSION`).
  - Otherwise, the standard `OpenAI` client is instantiated as before.
  -   **Dependencies:**
  - Relies on the `openai` package's built-in support for `AzureOpenAI`.
  No *new* external dependencies were added specifically for this Azure
  implementation beyond the `openai` package itself.
  
  ---
  
  ## How to Test
  
  *This has been tested locally and confirmed working with Azure OpenAI.*
  
  1.  **Configure `config.json`:**
  Ensure your `~/.codex/config.json` (or project-specific config) includes
  Azure and sets it as the active provider:
      ```json
      {
        "providers": {
          // ... other providers
          "azure": {
            "name": "AzureOpenAI",
  "baseURL": "https://YOUR_RESOURCE_NAME.openai.azure.com", // Replace
  with your Azure endpoint
            "envKey": "AZURE_OPENAI_API_KEY"
          }
        },
        "provider": "azure", // Set Azure as the active provider
        "model": "o4-mini" // Use your Azure deployment name here
        // ... other config settings
      }
      ```
  2.  **Set up Environment Variables:**
      ```bash
      # Set the API Key for your Azure OpenAI resource
      export AZURE_OPENAI_API_KEY="your-azure-api-key-here"
  
  # Set the API Version (Optional - defaults to `2025-03-01-preview` if
  not set)
  # Ensure this version is supported by your Azure deployment and endpoint
      export AZURE_OPENAI_API_VERSION="2025-03-01-preview"
      ```
  3.  **Get the Codex CLI by building from this PR branch:**
  Clone your fork, checkout this branch (`feat/azure-openai`), navigate to
  `codex-cli`, and build:
      ```bash
      # cd /path/to/your/fork/codex
      git checkout feat/azure-openai # Or your branch name
      cd codex-cli
      corepack enable
      pnpm install
      pnpm build
      ```
  4.  **Invoke Codex:**
  Run the locally built CLI using `node` from the `codex-cli` directory:
      ```bash
      node ./dist/cli.js "Explain the purpose of this PR"
      ```
  *(Alternatively, if you ran `pnpm link` after building, you can use
  `codex "Explain the purpose of this PR"` from anywhere)*.
  5. **Verify:** Confirm that the command executes successfully and
  interacts with your configured Azure OpenAI deployment.
  
  ---
  
  ## Tests
  
  - [x] Tested locally against an Azure OpenAI deployment using API Key
  authentication. Basic commands and interactions confirmed working.
  
  ---
  
  ## Checklist
  
  - [x] Added Azure provider details to configuration files
  (`providers.ts`, `config.ts`).
  - [x] Implemented conditional `AzureOpenAI` client initialization based
  on provider setting.
  -   [x] Ensured `apiVersion` is passed correctly to the Azure client.
  -   [x] Updated `README.md` with Azure OpenAI setup instructions.
  - [x] Manually tested core functionality against a live Azure OpenAI
  endpoint.
  - [x] Add/update automated tests for the Azure code path (pending `main`
  stability).
  
  cc @theabhinavdas @nikodem-wrona @fouad-openai @tibo-openai (adjust as
  needed)
  
  ---
  
  I have read the CLA Document and I hereby sign the CLA

  Govind Kamtamneni · 2025-05-09 18:11:32 -07:00
  7795272282
• 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: 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.

  Michael Bolin · 2025-05-08 16:21:11 -07:00
  a538e6acb2
• 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
• fix: increase output limits for truncating collector (#575)

  This Pull Request addresses an issue where the output of commands
  executed in the raw-exec utility was being truncated due to restrictive
  limits on the number of lines and bytes collected. The truncation caused
  the message [Output truncated: too many lines or bytes] to appear when
  processing large outputs, which could hinder the functionality of the
  CLI.
  
  Changes Made
  
  Increased the maximum output limits in the
  [createTruncatingCollector](https://github.com/openai/codex/pull/575)
  utility:
  Bytes: Increased from 10 KB to 100 KB.
  Lines: Increased from 256 lines to 1024 lines.
  Installed the @types/node package to resolve missing type definitions
  for [NodeJS](https://github.com/openai/codex/pull/575) and
  [Buffer](https://github.com/openai/codex/pull/575).
  Verified and fixed any related errors in the
  [createTruncatingCollector](https://github.com/openai/codex/pull/575)
  implementation.
  
  Issue Solved: 
  
  This PR ensures that larger outputs can be processed without truncation,
  improving the usability of the CLI for commands that generate extensive
  output. https://github.com/openai/codex/issues/509
  
  ---------
  
  Co-authored-by: Michael Bolin <bolinfest@gmail.com>

  Anil Karaka · 2025-05-05 10:26:55 -07:00
  76a979007e
• Use "Title case" for ToC (#812)
  Andrey Mishchenko · 2025-05-05 08:49:42 -07:00
  7e97980cb4
• 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
• use "Title case" in README.md (#798)
  Andrey Mishchenko · 2025-05-03 10:17:44 -07:00
  4b61fb8bab
• 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
• Configure HTTPS agent for proxies (#775)

  - Some workflows require you to route openAI API traffic through a proxy
  - See
  https://github.com/openai/openai-node/tree/v4?tab=readme-ov-file#configuring-an-https-agent-eg-for-proxies
  for more details
  
  ---------
  
  Co-authored-by: Thibault Sottiaux <tibo@openai.com>
  Co-authored-by: Fouad Matin <fouad@openai.com>

  anup-openai · 2025-05-02 12:08:13 -07:00
  f6b1ce2e3a
• update: vite version (#766)
  Fouad Matin · 2025-05-02 09:30:08 -07:00
  b864cc3810
• feat: use Landlock for sandboxing on Linux in TypeScript CLI (#763)

  Building on top of https://github.com/openai/codex/pull/757, this PR
  updates Codex to use the Landlock executor binary for sandboxing in the
  Node.js CLI. Note that Codex has to be invoked with either `--full-auto`
  or `--auto-edit` to activate sandboxing. (Using `--suggest` or
  `--dangerously-auto-approve-everything` ensures the sandboxing codepath
  will not be exercised.)
  
  When I tested this on a Linux host (specifically, `Ubuntu 24.04.1 LTS`),
  things worked as expected: I ran Codex CLI with `--full-auto` and then
  asked it to do `echo 'hello mbolin' into hello_world.txt` and it
  succeeded without prompting me.
  
  However, in my testing, I discovered that the sandboxing did *not* work
  when using `--full-auto` in a Linux Docker container from a macOS host.
  I updated the code to throw a detailed error message when this happens:
  
  
  ![image](https://github.com/user-attachments/assets/e5b99def-f00e-4ade-a0c5-2394d30df52e)

  Michael Bolin · 2025-05-01 12:34:56 -07:00
  a4b51f6b67
• 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

  Michael Bolin · 2025-05-01 08:36:07 -07:00
  3f5975ad5a
• bump(version): 0.1.2504301751 (#768)

  ## `0.1.2504301751`
  
  ### 🚀 Features
  
  - User config api key (#569)
  - `@mention` files in codex (#701)
  - Add `--reasoning` CLI flag (#314)
  - Lower default retry wait time and increase number of tries (#720)
  - Add common package registries domains to allowed-domains list (#414)
  
  ### 🪲 Bug Fixes
  
  - Insufficient quota message (#758)
  - Input keyboard shortcut opt+delete (#685)
  - `/diff` should include untracked files (#686)
  - Only allow running without sandbox if explicitly marked in safe
  container (#699)
  - Tighten up check for /usr/bin/sandbox-exec (#710)
  - Check if sandbox-exec is available (#696)
  - Duplicate messages in quiet mode (#680)

  Fouad Matin · 2025-04-30 17:55:34 -07:00
  463a230991
• fix: input keyboard shortcut opt+delete (#685)
  Fouad Matin · 2025-04-30 17:17:13 -07:00
  985fd44ec0
• feat: @mention files in codex (#701)

  Solves #700
  
  ## State of the World Before
  
  Prior to this PR, when users wanted to share file contents with Codex,
  they had two options:
  - Manually copy and paste file contents into the chat
  - Wait for the assistant to use the shell tool to view the file
  
  The second approach required the assistant to:
  1. Recognize the need to view a file
  2. Execute a shell tool call
  3. Wait for the tool call to complete
  4. Process the file contents
  
  This consumed extra tokens and reduced user control over which files
  were shared with the model.
  
  ## State of the World After
  
  With this PR, users can now:
  - Reference files directly in their chat input using the `@path` syntax
  - Have file contents automatically expanded into XML blocks before being
  sent to the LLM
  
  For example, users can type `@src/utils/config.js` in their message, and
  the file contents will be included in context. Within the terminal chat
  history, these file blocks will be collapsed back to `@path` format in
  the UI for clean presentation.
  
  Tag File suggestions:
  <img width="857" alt="file-suggestions"
  src="https://github.com/user-attachments/assets/397669dc-ad83-492d-b5f0-164fab2ff4ba"
  />
  
  Tagging files in action:
  <img width="858" alt="tagging-files"
  src="https://github.com/user-attachments/assets/0de9d559-7b7f-4916-aeff-87ae9b16550a"
  />
  
  Demo video of file tagging:
  [![Demo video of file
  tagging](https://img.youtube.com/vi/vL4LqtBnqt8/0.jpg)](https://www.youtube.com/watch?v=vL4LqtBnqt8)
  
  ## Implementation Details
  
  This PR consists of 2 main components:
  
  1. **File Tag Utilities**:
  - New `file-tag-utils.ts` utility module that handles both expansion and
  collapsing of file tags
  - `expandFileTags()` identifies `@path` tokens and replaces them with
  XML blocks containing file contents
  - `collapseXmlBlocks()` reverses the process, converting XML blocks back
  to `@path` format for UI display
  - Tokens are only expanded if they point to valid files (directories are
  ignored)
     - Expansion happens just before sending input to the model
  
  2. **Terminal Chat Integration**:
  - Leveraged the existing file system completion system for tabbing to
  support the `@path` syntax
     - Added `updateFsSuggestions` helper to manage filesystem suggestions
  - Added `replaceFileSystemSuggestion` to replace input with filesystem
  suggestions
  - Applied `collapseXmlBlocks` in the chat response rendering so that
  tagged files are shown as simple `@path` tags
  
  The PR also includes test coverage for both the UI and the file tag
  utilities.
  
  ## Next Steps
  
  Some ideas I'd like to implement if this feature gets merged:
  
  - Line selection: `@path[50:80]` to grab specific sections of files
  - Method selection: `@path#methodName` to grab just one function/class
  - Visual improvements: highlight file tags in the UI to make them more
  noticeable

  moppywhip · 2025-04-30 16:19:55 -07:00
  bc4e6db749
• fix: insufficient quota message (#758)

  This pull request includes a change to improve the error message
  displayed when there is insufficient quota in the `AgentLoop` class. The
  updated message provides more detailed information and a link for
  managing or purchasing credits.
  
  Error message improvement:
  
  *
  [`codex-cli/src/utils/agent/agent-loop.ts`](diffhunk://#diff-b15957eac2720c3f1f55aa32f172cdd0ac6969caf4e7be87983df747a9f97083L1140-R1140):
  Updated the error message in the `AgentLoop` class to include the
  specific error message (if available) and a link to manage or purchase
  credits.
  
  
  Fixes #751

  Kevin Alwell · 2025-04-30 16:00:50 -07:00
  bd82101859