41 Commits

• rmcp-client: fix auth crash (#11692)

  Don't load auth tokens if bearer token is present. This fixes a crash I
  was getting on Linux:
  
  ```
  2026-02-12T23:26:24.999408Z DEBUG session_init: codex_core::codex: Configuring session: model=gpt-5.3-codex-spark; provider=ModelProviderInfo { name: "OpenAI", base_url: None, env_key: None, env_key_instructions: No
  ne, experimental_bearer_token: None, wire_api: Responses, query_params: None, http_headers: Some({"version": "0.0.0"}), env_http_headers: Some({"OpenAI-Project": "OPENAI_PROJECT", "OpenAI-Organization": "OPENAI_ORGA
  NIZATION"}), request_max_retries: None, stream_max_retries: None, stream_idle_timeout_ms: None, requires_openai_auth: true, supports_websockets: true }
  2026-02-12T23:26:24.999799Z TRACE session_init: codex_keyring_store: keyring.load start, service=Codex MCP Credentials, account=codex_apps|20398391ad12d90b
  
  thread 'tokio-runtime-worker' (96190) has overflowed its stack
  fatal runtime error: stack overflow, aborting
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.35s
  ```

  Max Johnson · 2026-02-13 14:32:01 -08:00
  395729910c
• Bump rmcp to 0.15 (#11539)

  https://github.com/modelcontextprotocol/rust-sdk/pull/598 in 0.14 broke
  some MCP oauth (like Linear) and
  https://github.com/modelcontextprotocol/rust-sdk/pull/641 fixed it in
  0.15

  Gabriel Peal · 2026-02-11 22:04:17 -08:00
  bd3ce98190
• Upgrade rmcp to 0.14 (#10718)

  - [x] Upgrade rmcp to 0.14

  Matthew Zeng · 2026-02-08 15:07:53 -08:00
  9f1009540b
• Process-group cleanup for stdio MCP servers to prevent orphan process storms (#10710)

  This PR changes stdio MCP child processes to run in their own process
  group
  * Add guarded teardown in codex-rmcp-client: send SIGTERM to the group
  first, then SIGKILL after a short grace period.
  * Add terminate_process_group helper in process_group.rs.
  * Add Unix regression test in process_group_cleanup.rs to verify wrapper
  + grandchild are reaped on client drop.
  
  Addresses reported MCP process/thread storm: #10581

  Eric Traut · 2026-02-06 21:26:36 -08:00
  82c981cafc
• feat: replace custom mcp-types crate with equivalents from rmcp (#10349)

  We started working with MCP in Codex before
  https://crates.io/crates/rmcp was mature, so we had our own crate for
  MCP types that was generated from the MCP schema:
  
  
  https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md
  
  Now that `rmcp` is more mature, it makes more sense to use their MCP
  types in Rust, as they handle details (like the `_meta` field) that our
  custom version ignored. Though one advantage that our custom types had
  is that our generated types implemented `JsonSchema` and `ts_rs::TS`,
  whereas the types in `rmcp` do not. As such, part of the work of this PR
  is leveraging the adapters between `rmcp` types and the serializable
  types that are API for us (app server and MCP) introduced in #10356.
  
  Note this PR results in a number of changes to
  `codex-rs/app-server-protocol/schema`, which merit special attention
  during review. We must ensure that these changes are still
  backwards-compatible, which is possible because we have:
  
  ```diff
  - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, };
  + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, };
  ```
  
  so `ContentBlock` has been replaced with the more general `JsonValue`.
  Note that `ContentBlock` was defined as:
  
  ```typescript
  export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;
  ```
  
  so the deletion of those individual variants should not be a cause of
  great concern.
  
  Similarly, we have the following change in
  `codex-rs/app-server-protocol/schema/typescript/Tool.ts`:
  
  ```
  - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, };
  + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, };
  ```
  
  so:
  
  - `annotations?: ToolAnnotations` ➡️ `JsonValue`
  - `inputSchema: ToolInputSchema` ➡️ `JsonValue`
  - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue`
  
  and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349).
  * #10357
  * __->__ #10349
  * #10356

  Michael Bolin · 2026-02-02 17:41:55 -08:00
  66447d5d2c
• Validate CODEX_HOME before resolving (#10249)

  Summary
  - require `CODEX_HOME` to point to an existing directory before
  canonicalizing and surface clear errors otherwise
  - share the same helper logic in both `core` and `rmcp-client` and add
  unit tests that cover missing, non-directory, valid, and default paths
  
  This addresses #9222

  Eric Traut · 2026-01-30 15:46:33 -08:00
  8d142fd63d
• Show OAuth error descriptions in callback responses (#9654)

  ### Motivation
  - The local OAuth callback server returned a generic "Invalid OAuth
  callback" on failures even when the query contained an
  `error_description`, making it hard to debug OAuth failures.
  
  ### Description
  - Update `codex-rs/rmcp-client/src/perform_oauth_login.rs` to surface
  `error_description` values from the callback query in the HTTP response.
  - Introduce a `CallbackOutcome` enum and change `parse_oauth_callback`
  to return it, parsing `code`, `state`, and `error_description` from the
  query string.
  - Change `spawn_callback_server` to match on `CallbackOutcome` and
  return `OAuth error: <description>` with a 400 status when
  `error_description` is present, while preserving the existing success
  and invalid flows.
  - Use inline formatting for the error response string.
  
  ### Testing
  - Ran `just fmt` in the `codex-rs` workspace to format changes
  successfully.
  - Ran `cargo test -p codex-rmcp-client` and all tests passed.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6971aadc68d0832e93159efea8cd48a9)

  blevy-oai · 2026-01-27 13:22:54 -08:00
  c7c2b3cf8d
• Fix: Render MCP image outputs regardless of ordering (#9815)

  ## What?
  - Render an MCP image output cell whenever a decodable image block
  exists in `CallToolResult.content` (including text-before-image or
  malformed image before valid image).
  
  ## Why?
  - Tool results that include caption text before the image currently drop
  the image output cell.
  - A malformed image block can also suppress later valid image output.
  
  ## How?
  - Iterate `content` and return the first successfully decoded image
  instead of only checking the first block.
  - Add unit tests that cover text-before-image ordering and
  invalid-image-before-valid.
  
  ## Before
  ```rust
  let image = match result {
      Ok(mcp_types::CallToolResult { content, .. }) => {
          if let Some(mcp_types::ContentBlock::ImageContent(image)) = content.first() {
              // decode image (fails -> None)
          } else {
              None
          }
      }
      _ => None,
  }?;
  ```
  ## After
  ```rust
  let image = result
      .as_ref()
      .ok()?
      .content
      .iter()
      .find_map(decode_mcp_image)?;
  ```
  
  ## Risk / Impact
  - Low: only affects image cell creation for MCP tool results; no change
  for non-image outputs.
  
  ## Tests
  - [x] `just fmt`
  - [x] `cargo test -p codex-tui`
  - [x] Rerun after branch update (2026-01-27): `just fmt`, `cargo test -p
  codex-tui`
  
  Manual testing
  
  # Manual testing: MCP image tool result rendering (Codex TUI)
  
  # Build the rmcp stdio test server binary:
  cd codex-rs
  cargo build -p codex-rmcp-client --bin test_stdio_server
  
  # Register the server as an MCP server (absolute path to the built binary):
  codex mcp add mcpimg -- /Users/joshka/code/codex-pr-review/codex-rs/target/debug/test_stdio_server
  
  # Then in Codex TUI, ask it to call:
  - mcpimg.image_scenario({"scenario":"image_only"})
  - mcpimg.image_scenario({"scenario":"text_then_image","caption":"Here is the image:"})
  - mcpimg.image_scenario({"scenario":"invalid_base64_then_image"})
  - mcpimg.image_scenario({"scenario":"invalid_image_bytes_then_image"})
  - mcpimg.image_scenario({"scenario":"multiple_valid_images"})
  - mcpimg.image_scenario({"scenario":"image_then_text","caption":"Here is the image:"})
  - mcpimg.image_scenario({"scenario":"text_only","caption":"Here is the image:"})
  
  # Expected:
  # - You should see an extra history cell: "tool result (image output)" when the
  #   tool result contains at least one decodable image block (even if earlier
  #   blocks are text or invalid images).
  
  
  Fixes #9814
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  K Bediako · 2026-01-27 21:14:08 +00:00
  337643b00a
• [connectors] Support connectors part 1 - App server & MCP (#9667)

  In order to make Codex work with connectors, we add a built-in gateway
  MCP that acts as a transparent proxy between the client and the
  connectors. The gateway MCP collects actions that are accessible to the
  user and sends them down to the user, when a connector action is chosen
  to be called, the client invokes the action through the gateway MCP as
  well.
  
   - [x] Add the system built-in gateway MCP to list and run connectors.
   - [x] Add the app server methods and protocol

  Matthew Zeng · 2026-01-22 16:48:43 -08:00
  a2c829a808
• Revert "feat: support proxy for ws connection" (#9693)

  Reverts openai/codex#9409

  pakrym-oai · 2026-01-22 15:57:18 +00:00
  4d48d4e0c2
• feat: support proxy for ws connection (#9409)

  unfortunately tokio-tungstenite doesn't support proxy configuration
  outbox, while https://github.com/snapview/tokio-tungstenite/pull/370 is
  in review, we can depend on source code for now.

  Anton Panasenko · 2026-01-20 09:36:30 -08:00
  7b27aa7707
• add generated jsonschema for config.toml (#8956)

  ### What
  Add JSON Schema generation for `config.toml`, with checked‑in
  `docs/config.schema.json`. We can move the schema elsewhere if preferred
  (and host it if there's demand).
  
  Add fixture test to prevent drift and `just write-config-schema` to
  regenerate on schema changes.
  
  Generate MCP config schema from `RawMcpServerConfig` instead of
  `McpServerConfig` because that is the runtime type used for
  deserialization.
  
  Populate feature flag values into generated schema so they can be
  autocompleted.
  
  ### Tests
  Added tests + regenerate script to prevent drift. Tested autocompletions
  using generated jsonschema locally with Even Better TOML.
  
  
  
  https://github.com/user-attachments/assets/5aa7cd39-520c-4a63-96fb-63798183d0bc

  sayan-oai · 2026-01-13 10:22:51 -08:00
  40e2405998
• Add static mcp callback uri support (#8971)

  Currently the callback URI for MCP authentication is dynamically
  generated. More specifically, the callback URI is dynamic because the
  port part of it is randomly chosen by the OS. This is not ideal as
  callback URIs are recommended to be static and many authorization
  servers do not support dynamic callback URIs.
  
  This PR fixes that issue by exposing a new config option named
  `mcp_oauth_callback_port`. When it is set, the callback URI is
  constructed using this port rather than a random one chosen by the OS,
  thereby making callback URI static.
  
  Related issue: https://github.com/openai/codex/issues/8827

  WhammyLeaf · 2026-01-12 16:57:04 +00:00
  d5562983d9
• feat: add support for building with Bazel (#8875)

  This PR configures Codex CLI so it can be built with
  [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
  includes configuration so that remote builds can be done using
  [BuildBuddy](https://www.buildbuddy.io).
  
  If you are familiar with Bazel, things should work as you expect, e.g.,
  run `bazel test //... --keep-going` to run all the tests in the repo,
  but we have also added some new aliases in the `justfile` for
  convenience:
  
  - `just bazel-test` to run tests locally
  - `just bazel-remote-test` to run tests remotely (currently, the remote
  build is for x86_64 Linux regardless of your host platform). Note we are
  currently seeing the following test failures in the remote build, so we
  still need to figure out what is happening here:
  
  ```
  failures:
      suite::compact::manual_compact_twice_preserves_latest_user_messages
      suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
      suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
  ```
  
  - `just build-for-release` to build release binaries for all
  platforms/architectures remotely
  
  To setup remote execution:
  - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
  employees should also request org access at
  https://openai.buildbuddy.io/join/ with their `@openai.com` email
  address.)
  - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
  `~/.bazelrc` (add the line `build
  --remote_header=x-buildbuddy-api-key=YOUR_KEY`)
  - Use `--config=remote` in your `bazel` invocations (or add `common
  --config=remote` to your `~/.bazelrc`, or use the `just` commands)
  
  ## CI
  
  In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
  uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
  (we are working on supporting Windows, but that is not ready yet). Note
  that the failures we are seeing in `just bazel-remote-test` do not occur
  on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
  is green right now.
  
  The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
  that macOS CI jobs build _remotely_ on Linux hosts (using the
  `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
  root `BUILD.bazel`) using cross-compilation to build the macOS
  artifacts. Then these artifacts are downloaded locally to GitHub's macOS
  runner so the tests can be executed natively. This is the relevant
  config that enables this:
  
  ```
  common:macos --config=remote
  common:macos --strategy=remote
  common:macos --strategy=TestRunner=darwin-sandbox,local
  ```
  
  Because of the remote caching benefits we get from BuildBuddy, these new
  CI jobs can be extremely fast! For example, consider these two jobs that
  ran all the tests on Linux x86_64:
  
  - Bazel 1m37s
  https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
  - Cargo 9m20s
  https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
  
  For now, we will continue to run both the Bazel and Cargo jobs for PRs,
  but once we add support for Windows and running Clippy, we should be
  able to cutover to using Bazel exclusively for PRs, which should still
  speed things up considerably. We will probably continue to run the Cargo
  jobs post-merge for commits that land on `main` as a sanity check.
  
  Release builds will also continue to be done by Cargo for now.
  
  Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
  Earlier attempt to add support for Buck2, now abandoned:
  https://github.com/openai/codex/pull/8504
  
  ---------
  
  Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9
• Work around crash in system-configuration library (#8954)

  This is a proposed fix for #8912
  
  Information provided by Codex:
  
  no_proxy means “don’t use any system proxy settings for this client,”
  even if macOS has proxies configured in System Settings or via
  environment. On macOS, reqwest’s proxy discovery can call into the
  system-configuration framework; that’s the code path that was panicking
  with “Attempted to create a NULL object.” By forcing a direct connection
  for the OAuth discovery request, we avoid that proxy-resolution path
  entirely, so the system-configuration crate never gets invoked and the
  panic disappears.
  
  Effectively:
  
  With proxies: reqwest asks the OS for proxy config →
  system-configuration gets touched → panic.
  With no_proxy: reqwest skips proxy lookup → no system-configuration call
  → no panic.
  So the fix doesn’t change any MCP protocol behavior; it just prevents
  the OAuth discovery probe from touching the macOS proxy APIs that are
  crashing in the reported environment.
  
  This fix changes behavior for the OAuth discovery probe used in codex
  mcp list/auth status detection. With no_proxy, that probe won’t use
  system or env proxy settings, so:
  
  If a server is only reachable via a proxy, the discovery call may fail
  and we’ll show auth as Unsupported/NotLoggedIn incorrectly.
  If the server is reachable directly (common case), behavior is
  unchanged.
  
  
  
  As an alternative, we could try to get a fix into the
  [system-configuration](https://github.com/mullvad/system-configuration-rs)
  library. It looks like this library is still under development but has
  slow release pace.

  Eric Traut · 2026-01-09 08:11:34 -07:00
  cacdae8c05
• feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496)

  This PR introduces a `codex-utils-cargo-bin` utility crate that
  wraps/replaces our use of `assert_cmd::Command` and
  `escargot::CargoBuild`.
  
  As you can infer from the introduction of `buck_project_root()` in this
  PR, I am attempting to make it possible to build Codex under
  [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to
  achieve faster incremental local builds (largely due to Buck2's
  [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/)
  build strategy, as well as benefits from its local build daemon) as well
  as faster CI builds if we invest in remote execution and caching.
  
  See
  https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages
  for more details about the performance advantages of Buck2.
  
  Buck2 enforces stronger requirements in terms of build and test
  isolation. It discourages assumptions about absolute paths (which is key
  to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment
  variables that Cargo provides are absolute paths (which
  `assert_cmd::Command` reads), this is a problem for Buck2, which is why
  we need this `codex-utils-cargo-bin` utility.
  
  My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables
  passed to a `rust_test()` build rule as relative paths.
  `codex-utils-cargo-bin` will resolve these values to absolute paths,
  when necessary.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496).
  * #8498
  * __->__ #8496

  Michael Bolin · 2025-12-23 19:29:32 -08:00
  e61bae12e3
• fix: change codex/sandbox-state/update from a notification to a request (#8142)

  Historically, `accept_elicitation_for_prompt_rule()` was flaky because
  we were using a notification to update the sandbox followed by a `shell`
  tool request that we expected to be subject to the new sandbox config,
  but because [rmcp](https://crates.io/crates/rmcp) MCP servers delegate
  each incoming message to a new Tokio task, messages are not guaranteed
  to be processed in order, so sometimes the `shell` tool call would run
  before the notification was processed.
  
  Prior to this PR, we relied on a generous `sleep()` between the
  notification and the request to reduce the change of the test flaking
  out.
  
  This PR implements a proper fix, which is to use a _request_ instead of
  a notification for the sandbox update so that we can wait for the
  response to the sandbox request before sending the request to the
  `shell` tool call. Previously, `rmcp` did not support custom requests,
  but I fixed that in
  https://github.com/modelcontextprotocol/rust-sdk/pull/590, which made it
  into the `0.12.0` release (see #8288).
  
  This PR updates `shell-tool-mcp` to expect
  `"codex/sandbox-state/update"` as a _request_ instead of a notification
  and sends the appropriate ack. Note this behavior is tied to our custom
  `codex/sandbox-state` capability, which Codex honors as an MCP client,
  which is why `core/src/mcp_connection_manager.rs` had to be updated as
  part of this PR, as well.
  
  This PR also updates the docs at `shell-tool-mcp/README.md`.

  Michael Bolin · 2025-12-18 15:32:01 -08:00
  46baedd7cb
• chore: upgrade rmcp crate from 0.10.0 to 0.12.0 (#8288)

  Version `0.12.0` includes
  https://github.com/modelcontextprotocol/rust-sdk/pull/590, which I will
  use in https://github.com/openai/codex/pull/8142.
  
  Changes:
  
  - `rmcp::model::CustomClientNotification` was renamed to
  `rmcp::model::CustomNotification`
  - a bunch of types have a `meta` field now, but it is `Option`, so I
  added `meta: None` to a bunch of things

  Michael Bolin · 2025-12-18 14:28:46 -08:00
  53f53173a8
• feat: support mcp in-session login (#7751)

  ### Summary
  * Added `mcpServer/oauthLogin` in app server for supporting in session
  MCP server login
  * Added `McpServerOauthLoginParams` and `McpServerOauthLoginResponse` to
  support above method with response returning the auth URL for consumer
  to open browser or display accordingly.
  * Added `McpServerOauthLoginCompletedNotification` which the app server
  would emit on MCP server login success or failure (i.e. timeout).
  * Refactored rmcp-client oath_login to have the ability on starting a
  auth server which the codex_message_processor uses for in-session auth.

  Shijie Rao · 2025-12-09 17:43:53 -08:00
  893f5261eb
• chore: add cargo-deny configuration (#7119)

  - add GitHub workflow running cargo-deny on push/PR
  - document cargo-deny allowlist with workspace-dep notes and advisory
  ignores
  - align workspace crates to inherit version/edition/license for
  consistent checks

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874
• feat: declare server capability in shell-tool-mcp (#7112)

  This introduces a new feature to Codex when it operates as an MCP
  _client_ where if an MCP _server_ replies that it has an entry named
  `"codex/sandbox-state"` in its _server capabilities_, then Codex will
  send it an MCP notification with the following structure:
  
  ```json
  {
    "method": "codex/sandbox-state/update",
    "params": {
      "sandboxPolicy": {
        "type": "workspace-write",
        "network-access": false,
        "exclude-tmpdir-env-var": false
        "exclude-slash-tmp": false
      },
      "codexLinuxSandboxExe": null,
      "sandboxCwd": "/Users/mbolin/code/codex2"
    }
  }
  ```
  
  or with whatever values are appropriate for the initial `sandboxPolicy`.
  
  **NOTE:** Codex _should_ continue to send the MCP server notifications
  of the same format if these things change over the lifetime of the
  thread, but that isn't wired up yet.
  
  The result is that `shell-tool-mcp` can consume these values so that
  when it calls `codex_core::exec::process_exec_tool_call()` in
  `codex-rs/exec-server/src/posix/escalate_server.rs`, it is now sure to
  call it with the correct values (whereas previously we relied on
  hardcoded values).
  
  While I would argue this is a supported use case within the MCP
  protocol, the `rmcp` crate that we are using today does not support
  custom notifications. As such, I had to patch it and I submitted it for
  review, so hopefully it will be accepted in some form:
  
  https://github.com/modelcontextprotocol/rust-sdk/pull/556
  
  To test out this change from end-to-end:
  
  - I ran `cargo build` in `~/code/codex2/codex-rs/exec-server`
  - I built the fork of Bash in `~/code/bash/bash`
  - I added the following to my `~/.codex/config.toml`:
  
  ```toml
  # Use with `codex --disable shell_tool`.
  [mcp_servers.execshell]
  args = ["--bash", "/Users/mbolin/code/bash/bash"]
  command = "/Users/mbolin/code/codex2/codex-rs/target/debug/codex-exec-mcp-server"
  ```
  
  - From `~/code/codex2/codex-rs`, I ran `just codex --disable shell_tool`
  - When the TUI started up, I verified that the sandbox mode is
  `workspace-write`
  - I ran `/mcp` to verify that the shell tool from the MCP is there:
  
  <img width="1387" height="1400" alt="image"
  src="https://github.com/user-attachments/assets/1a8addcc-5005-4e16-b59f-95cfd06fd4ab"
  />
  
  - Then I asked it:
  
  > what is the output of `gh issue list`
  
  because this should be auto-approved with our existing dummy policy:
  
  
  https://github.com/openai/codex/blob/af63e6eccc35783f1bf4dca3c61adb090efb6b8a/codex-rs/exec-server/src/posix.rs#L157-L164
  
  And it worked:
  
  <img width="1387" height="1400" alt="image"
  src="https://github.com/user-attachments/assets/7568d2f7-80da-4d68-86d0-c265a6f5e6c1"
  />

  Michael Bolin · 2025-11-21 16:11:01 -08:00
  c6f68c9df8
• support MCP elicitations (#6947)

  No support for request schema yet, but we'll at least show the message
  and allow accept/decline.
  
  <img width="823" height="551" alt="Screenshot 2025-11-21 at 2 44 05 PM"
  src="https://github.com/user-attachments/assets/6fbb892d-ca12-4765-921e-9ac4b217534d"
  />

  Jeremy Rose · 2025-11-21 14:44:53 -08:00
  7561a6aaf0
• 🐛 fix(rmcp-client): refresh OAuth tokens using expires_at (#6574)

  ## Summary
  - persist OAuth credential expiry timestamps and rehydrate `expires_in`
  - proactively refresh rmcp OAuth tokens when `expires_at` is near, then
  persist
  
  ## Testing
  - just fmt
  - just fix -p codex-rmcp-client
  - cargo test -p codex-rmcp-client
  
  Fixes #6572

  Lael · 2025-11-18 02:16:58 -05:00
  f3d4e210d8
• Fix FreeBSD/OpenBSD builds: target-specific keyring features and BSD hardening (#6680)

  ## Summary
  Builds on FreeBSD and OpenBSD were failing due to globally enabled
  Linux-specific keyring features and hardening code paths not gated by
  OS. This PR scopes keyring native backends to the
  appropriate targets, disables default features at the workspace root,
  and adds a BSD-specific hardening function. Linux/macOS/Windows behavior
  remains unchanged, while FreeBSD/OpenBSD
    now build and run with a supported backend.
  
  ## Key Changes
  
    - Keyring features:
  - Disable keyring default features at the workspace root to avoid
  pulling Linux backends on non-Linux.
  - Move native backend features into target-specific sections in the
  affected crates:
            - Linux: linux-native-async-persistent
            - macOS: apple-native
            - Windows: windows-native
            - FreeBSD/OpenBSD: sync-secret-service
    - Process hardening:
        - Add pre_main_hardening_bsd() for FreeBSD/OpenBSD, applying:
            - Set RLIMIT_CORE to 0
            - Clear LD_* environment variables
  - Simplify process-hardening Cargo deps to unconditional libc (avoid
  conflicting OS fragments).
    - No changes to CODEX_SANDBOX_* behavior.
  
  ## Rationale
  
  - Previously, enabling keyring native backends globally pulled
  Linux-only features on BSD, causing build errors.
  - Hardening logic was tailored for Linux/macOS; BSD builds lacked a
  gated path with equivalent safeguards.
  - Target-scoped features and BSD hardening make the crates portable
  across these OSes without affecting existing behavior elsewhere.
  
  ## Impact by Platform
  
    - Linux: No functional change; backends now selected via target cfg.
    - macOS: No functional change; explicit apple-native mapping.
    - Windows: No functional change; explicit windows-native mapping.
  - FreeBSD/OpenBSD: Builds succeed using sync-secret-service; BSD
  hardening applied during startup.
  
  ## Testing
  
  - Verified compilation across affected crates with target-specific
  features.
  - Smoke-checked that Linux/macOS/Windows feature sets remain identical
  functionally after scoping.
  - On BSD, confirmed keyring resolves to sync-secret-service and
  hardening compiles.
  
  ## Risks / Compatibility
  
    - Minimal risk: only feature scoping and OS-gated additions.
  - No public API changes in the crates; runtime behavior on non-BSD
  platforms is preserved.
  - On BSD, the new hardening clears LD_*; this is consistent with
  security posture on other Unix platforms.
  
  ## Reviewer Notes
  
  - Pay attention to target-specific sections for keyring in the affected
  Cargo.toml files.
  - Confirm pre_main_hardening_bsd() mirrors the safe subset of
  Linux/macOS hardening without introducing Linux-only calls.
  - Confirm no references to CODEX_SANDBOX_ENV_VAR or
  CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR were added/modified.
  
  ## Checklist
  
    - Disable keyring default features at workspace root.
  - Target-specific keyring features mapped per OS
  (Linux/macOS/Windows/BSD).
    - Add BSD hardening (RLIMIT_CORE=0, clear LD_*).
    - Simplify process-hardening dependencies to unconditional libc.
    - No changes to sandbox env var code.
    - Formatting and linting: just fmt + just fix -p for changed crates.
    - Project tests pass for changed crates; broader suite unchanged.
  
  ---------
  
  Co-authored-by: celia-oai <celia@openai.com>

  Xiao-Yong Jin · 2025-11-17 05:07:34 +00:00
  5860481bc4
• fix: resolve Windows MCP server execution for script-based tools (#3828)

  ## What?
  
  Fixes MCP server initialization failures on Windows when using
  script-based tools like `npx`, `pnpm`, and `yarn` that rely on
  `.cmd`/`.bat` files rather than `.exe` binaries.
  
  Fixes #2945
  
  ## Why?
  
  Windows users encounter "program not found" errors when configuring MCP
  servers with commands like `npx` in their `~/.codex/config.toml`. This
  happens because:
  
  - Tools like `npx` are batch scripts (`npx.cmd`) on Windows, not
  executable binaries
  - Rust's `std::process::Command` bypasses the shell and cannot execute
  these scripts directly
  - The Windows shell normally handles this by checking `PATHEXT` for
  executable extensions
  
  Without this fix, Windows users must specify full paths or add `.cmd`
  extensions manually, which breaks cross-platform compatibility.
  
  ## How?
  
  Added platform-specific program resolution using the `which` crate to
  find the correct executable path:
  
  - **Windows**: Resolves programs through PATH/PATHEXT to find
  `.cmd`/`.bat` scripts
  - **Unix**: Returns the program unchanged (no-op, as Unix handles
  scripts natively)
  
  ### Changes
  
  - Added `which = "6"` dependency to `mcp-client/Cargo.toml`
  - Implemented `program_resolver` module in `mcp_client.rs` with
  platform-specific resolution
  - Added comprehensive tests for both Windows and Unix behavior
  
  ### Testing
  
  Added platform-specific tests to verify:
  - Unix systems execute scripts without extensions
  - Windows fails without proper extensions
  - Windows succeeds with explicit extensions
  - Cross-platform resolution enables successful execution
  
  **Tested on:**
  - Windows 11 (NT 10.0.26100.0 x64)
  - PowerShell 5.1 & 7+, CMD, Git Bash
  - MCP servers: playwright, context7, supabase
  - WSL (verified no regression)
  
  **Local checks passed:**
  ```bash
  cargo test && cargo clippy --tests && cargo fmt -- --config imports_granularity=Item
  ```
  
  ### Results
  
  **Before:**
  ```
  🖐 MCP client for `playwright` failed to start: program not found
  ```
  
  **After:**
  ```
  🖐 MCP client for `playwright` failed to start: request timed out
  ```
  
  Windows users can now use simple commands like `npx` in their config
  without specifying full paths or extensions. The timeout issue is a
  separate concern that will be addressed in a follow-up PR.
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Joonsoo Lee · 2025-11-16 13:41:10 -08:00
  f828cd2897
• Upgrade rmcp to 0.8.4 (#6234)

  Picks up https://github.com/modelcontextprotocol/rust-sdk/pull/509 which
  fixes https://github.com/openai/codex/issues/6164

  Gabriel Peal · 2025-11-05 00:23:24 -05:00
  9b538a8672
• fix(windows-path): preserve PATH order; include core env vars (#5579)

  # Preserve PATH precedence & fix Windows MCP env propagation
  
  ## Problem & intent
  
  Preserve user PATH precedence and reduce Windows setup friction for MCP
  servers by avoiding PATH reordering and ensuring Windows child processes
  receive essential env vars.
  
  - Addresses: #4180 #5225 #2945 #3245 #3385 #2892 #3310 #3457 #4370  
  - Supersedes: #4182, #3866, #3828 (overlapping/inferior once this
  merges)
  - Notes: #2626 / #2646 are the original PATH-mutation sources being
  corrected.
  
  ---
  
  ## Before / After
  
  **Before**  
  - PATH was **prepended** with an `apply_patch` helper dir (Rust + Node
  wrapper), reordering tools and breaking virtualenvs/shims on
  macOS/Linux.
  - On Windows, MCP servers missed core env vars and often failed to start
  without explicit per-server env blocks.
  
  **After**  
  - Helper dir is **appended** to PATH (preserves user/tool precedence).  
  - Windows MCP child env now includes common core variables and mirrors
  `PATH` → `Path`, so typical CLIs/plugins work **without** per-server env
  blocks.
  
  ---
  
  ## Scope of change
  
  ### `codex-rs/arg0/src/lib.rs`
  - Append temp/helper dir to `PATH` instead of prepending.
  
  ### `codex-cli/bin/codex.js`
  - Mirror the same append behavior for the Node wrapper.
  
  ### `codex-rs/rmcp-client/src/utils.rs`
  - Expand Windows `DEFAULT_ENV_VARS` (e.g., `COMSPEC`, `SYSTEMROOT`,
  `PROGRAMFILES*`, `APPDATA`, etc.).
  - Mirror `PATH` → `Path` for Windows child processes.  
  - Small unit test; conditional `mut` + `clippy` cleanup.
  
  ---
  
  ## Security effects
  
  No broadened privileges. Only environment propagation for well-known
  Windows keys on stdio MCP child processes. No sandbox policy changes and
  no network additions.
  
  ---
  
  ## Testing evidence
  
  **Static**  
  - `cargo fmt`  
  - `cargo clippy -p codex-arg0 -D warnings` → **clean**  
  - `cargo clippy -p codex-rmcp-client -D warnings` → **clean**  
  - `cargo test -p codex-rmcp-client` → **13 passed**
  
  **Manual**  
  - Local verification on Windows PowerShell 5/7 and WSL (no `unused_mut`
  warnings on non-Windows targets).
  
  ---
  
  ## Checklist
  
  - [x] Append (not prepend) helper dir to PATH in Rust and Node wrappers
  - [x] Windows MCP child inherits core env vars; `PATH` mirrored to
  `Path`
  - [x] `cargo fmt` / `clippy` clean across touched crates  
  - [x] Unit tests updated/passing where applicable  
  - [x] Cross-platform behavior preserved (macOS/Linux PATH precedence
  intact)

  Curt · 2025-10-28 21:06:39 -07:00
  e9135fa7c5
• [MCP] Render MCP tool call result images to the model (#5600)

  It's pretty amazing we have gotten here without the ability for the
  model to see image content from MCP tool calls.
  
  This PR builds off of 4391 and fixes #4819. I would like @KKcorps to get
  adequete credit here but I also want to get this fix in ASAP so I gave
  him a week to update it and haven't gotten a response so I'm going to
  take it across the finish line.
  
  
  This test highlights how absured the current situation is. I asked the
  model to read this image using the Chrome MCP
  <img width="2378" height="674" alt="image"
  src="https://github.com/user-attachments/assets/9ef52608-72a2-4423-9f5e-7ae36b2b56e0"
  />
  
  After this change, it correctly outputs:
  > Captured the page: image dhows a dark terminal-style UI labeled
  `OpenAI Codex (v0.0.0)` with prompt `model: gpt-5-codex medium` and
  working directory `/codex/codex-rs`
  (and more)  
  
  Before this change, it said:
  > Took the full-page screenshot you asked for. It shows a long,
  horizontally repeating pattern of stylized people in orange, light-blue,
  and mustard clothing, holding hands in alternating poses against a white
  background. No text or other graphics-just rows of flat illustration
  stretching off to the right.
  
  Without this change, the Figma, Playwright, Chrome, and other visual MCP
  servers are pretty much entirely useless.
  
  I tested this change with the openai respones api as well as a third
  party completions api

  Gabriel Peal · 2025-10-27 17:55:57 -04:00
  b0bdc04c30
• [Auth] Add keyring support for Codex CLI (#5591)

  Follow-up PR to #5569. Add Keyring Support for Auth Storage in Codex CLI
  as well as a hybrid mode (default to persisting in keychain but fall
  back to file when unavailable.)
  
  It also refactors out the keyringstore implementation from rmcp-client
  [here](https://github.com/openai/codex/blob/main/codex-rs/rmcp-client/src/oauth.rs)
  to a new keyring-store crate.
  
  There will be a follow-up that picks the right credential mode depending
  on the config, instead of hardcoding `AuthCredentialsStoreMode::File`.

  Celia Chen · 2025-10-27 12:10:11 -07:00
  0fc295d958
• [MCP] Add support for specifying scopes for MCP oauth (#5487)

  ```
  codex mcp login server_name --scopes=scope1,scope2,scope3
  ```
  
  Fixes #5480

  Gabriel Peal · 2025-10-22 09:37:33 -07:00
  34c5a9eaa9
• [MCP] Add support for resources (#5239)

  This PR adds support for [MCP
  resources](https://modelcontextprotocol.io/specification/2025-06-18/server/resources)
  by adding three new tools for the model:
  1. `list_resources`
  2. `list_resource_templates`
  3. `read_resource`
  
  These 3 tools correspond to the [three primary MCP resource protocol
  messages](https://modelcontextprotocol.io/specification/2025-06-18/server/resources#protocol-messages).
  
  Example of listing and reading a GitHub resource tempalte
  <img width="2984" height="804" alt="CleanShot 2025-10-15 at 17 31 10"
  src="https://github.com/user-attachments/assets/89b7f215-2e2a-41c5-90dd-b932ac84a585"
  />
  
  `/mcp` with Figma configured
  <img width="2984" height="442" alt="CleanShot 2025-10-15 at 18 29 35"
  src="https://github.com/user-attachments/assets/a7578080-2ed2-4c59-b9b4-d8461f90d8ee"
  />
  
  Fixes #4956

  Gabriel Peal · 2025-10-17 01:05:15 -04:00
  40fba1bb4c
• [MCP] Allow specifying cwd and additional env vars (#5246)

  This makes stdio mcp servers more flexible by allowing users to specify
  the cwd to run the server command from and adding additional environment
  variables to be passed through to the server.
  
  Example config using the test server in this repo:
  ```toml
  [mcp_servers.test_stdio]
  cwd = "/Users/<user>/code/codex/codex-rs"
  command = "cargo"
  args = ["run", "--bin", "test_stdio_server"]
  env_vars = ["MCP_TEST_VALUE"]
  ```
  
  @bolinfest I know you hate these env var tests but let's roll with this
  for now. I may take a stab at the env guard + serial macro at some
  point.

  Gabriel Peal · 2025-10-17 00:24:43 -04:00
  bdda762deb
• [MCP] Allow specifying custom headers with streamable http servers (#5241)

  This adds two new config fields to streamable http mcp servers:
  `http_headers`: a map of key to value
  `env_http_headers` a map of key to env var which will be resolved at
  request time
  
  All headers will be passed to all MCP requests to that server just like
  authorization headers.
  
  There is a test ensuring that headers are not passed to other servers.
  
  Fixes #5180

  Gabriel Peal · 2025-10-16 23:15:47 -04:00
  a5d48a775b
• [MCP] Prompt mcp login when adding a streamable HTTP server that supports oauth (#5193)

  1. If Codex detects that a `codex mcp add -url …` server supports oauth,
  it will auto-initiate the login flow.
  2. If the TUI starts and a MCP server supports oauth but isn't logged
  in, it will give the user an explicit warning telling them to log in.

  Gabriel Peal · 2025-10-15 12:27:40 -04:00
  8a281cd1f4
• [MCP] Add auth status to MCP servers (#4918)

  This adds a queryable auth status for MCP servers which is useful:
  1. To determine whether a streamable HTTP server supports auth or not
  based on whether or not it supports RFC 8414-3.2
  2. Allow us to build a better user experience on top of MCP status

  Gabriel Peal · 2025-10-08 17:37:57 -04:00
  3c5e12e2a4
• [MCP] Add the ability to explicitly specify a credentials store (#4857)

  This lets users/companies explicitly choose whether to force/disallow
  the keyring/fallback file storage for mcp credentials.
  
  People who develop with Codex will want to use this until we sign
  binaries or else each ad-hoc debug builds will require keychain access
  on every build. I don't love this and am open to other ideas for how to
  handle that.
  
  
  ```toml
  mcp_oauth_credentials_store = "auto"
  mcp_oauth_credentials_store = "file"
  mcp_oauth_credentials_store = "keyrung"
  ```
  Defaults to `auto`

  Gabriel Peal · 2025-10-07 22:39:32 -04:00
  496cb801e1
• [MCP] Fix the bearer token authorization header (#4846)

  `http_config.auth_header` automatically added `Bearer `. By adding it
  ourselves, we were sending `Bearer Bearer <token>`.
  
  I confirmed that the GitHub MCP initialization 400s before and works
  now.
  
  I also optimized the oauth flow to not check the keyring if you
  explicitly pass in a bearer token.

  Gabriel Peal · 2025-10-06 17:41:16 -04:00
  d73055c5b1
• [MCP] Upgrade rmcp to 0.8 (#4774)

  The version with the well-known discovery and my MCP client name change
  were just released
  
  https://github.com/modelcontextprotocol/rust-sdk/releases

  Gabriel Peal · 2025-10-05 18:12:37 -04:00
  7fa5e95c1f
• [MCP] Add support for MCP Oauth credentials (#4517)

  This PR adds oauth login support to streamable http servers when
  `experimental_use_rmcp_client` is enabled.
  
  This PR is large but represents the minimal amount of work required for
  this to work. To keep this PR smaller, login can only be done with
  `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp`
  or `codex mcp list` yet. Fingers crossed that this is the last large MCP
  PR and that subsequent PRs can be smaller.
  
  Under the hood, credentials are stored using platform credential
  managers using the [keyring crate](https://crates.io/crates/keyring).
  When the keyring isn't available, it falls back to storing credentials
  in `CODEX_HOME/.credentials.json` which is consistent with how other
  coding agents handle authentication.
  
  I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able
  to test the dbus store on linux but did verify that the fallback works.
  
  One quirk is that if you have credentials, during development, every
  build will have its own ad-hoc binary so the keyring won't recognize the
  reader as being the same as the write so it may ask for the user's
  password. I may add an override to disable this or allow
  users/enterprises to opt-out of the keyring storage if it causes issues.
  
  <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40"
  src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d"
  />
  <img width="745" height="486" alt="image"
  src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e"
  />

  Gabriel Peal · 2025-10-03 13:43:12 -04:00
  1d17ca1fa3
• [MCP] Add experimental support for streamable HTTP MCP servers (#4317)

  This PR adds support for streamable HTTP MCP servers when the
  `experimental_use_rmcp_client` is enabled.
  
  To set one up, simply add a new mcp server config with the url:
  ```
  [mcp_servers.figma]
  url = "http://127.0.0.1:3845/mcp"
  ```
  
  It also supports an optional `bearer_token` which will be provided in an
  authorization header. The full oauth flow is not supported yet.
  
  The config parsing will throw if it detects that the user mixed and
  matched config fields (like command + bearer token or url + env).
  
  The best way to review it is to review `core/src` and then
  `rmcp-client/src/rmcp_client.rs` first. The rest is tests and
  propagating the `Transport` struct around the codebase.
  
  Example with the Figma MCP:
  <img width="5084" height="1614" alt="CleanShot 2025-09-26 at 13 35 40"
  src="https://github.com/user-attachments/assets/eaf2771e-df3e-4300-816b-184d7dec5a28"
  />

  Gabriel Peal · 2025-09-26 21:24:01 -04:00
  3a1be084f9
• [MCP] Introduce an experimental official rust sdk based mcp client (#4252)

  The [official Rust
  SDK](https://github.com/modelcontextprotocol/rust-sdk/tree/57fc428c578a1a3fe851ee0838bf068bda120eb3)
  has come a long way since we first started our mcp client implementation
  5 months ago and, today, it is much more complete than our own
  stdio-only implementation.
  
  This PR introduces a new config flag `experimental_use_rmcp_client`
  which will use a new mcp client powered by the sdk instead of our own.
  
  To keep this PR simple, I've only implemented the same stdio MCP
  functionality that we had but will expand on it with future PRs.
  
  ---------
  
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  Gabriel Peal · 2025-09-26 13:13:37 -04:00
  e555a36c6a