56 Commits

• Plumb MCP turn metadata through _meta (#15190)

  ## Summary
  
  Some background. We're looking to instrument GA turns end to end. Right
  now a big gap is grouping mcp tool calls with their codex sessions. We
  send session id and turn id headers to the responses call but not the
  mcp/wham calls.
  
  Ideally we could pass the args as headers like with responses, but given
  the setup of the rmcp client, we can't send as headers without either
  changing the rmcp package upstream to allow per request headers or
  introducing a mutex which break concurrency. An earlier attempt made the
  assumption that we had 1 client per thread, which allowed us to set
  headers at the start of a turn. @pakrym mentioned that this assumption
  might break in the near future.
  
  So the solution now is to package the turn metadata/session id into the
  _meta field in the post body and pull out in codex-backend.
  
  - send turn metadata to MCP servers via `tools/call` `_meta` instead of
  assuming per-thread request headers on shared clients
  - preserve the existing `_codex_apps` metadata while adding
  `x-codex-turn-metadata` for all MCP tool calls
  - extend tests to cover both custom MCP servers and the codex apps
  search flow
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  nicholasclark-openai · 2026-03-19 22:05:13 +00:00
  2bee37fe69
• Revert "Forward session and turn headers to MCP HTTP requests" (#15185)

  Reverts openai/codex#15011
  
  Codex merged by mistake before feedback applied

  nicholasclark-openai · 2026-03-19 10:38:53 -07:00
  5ec121ba12
• Forward session and turn headers to MCP HTTP requests (#15011)

  ## Summary
  - forward request-scoped task headers through MCP tool metadata lookups
  and tool calls
  - apply those headers to streamable HTTP initialize, tools/list, and
  tools/call requests
  - update affected rmcp/core tests for the new request_headers plumbing
  
  ## Testing
  - cargo test -p codex-rmcp-client
  - cargo test -p codex-core (fails on pre-existing unrelated error in
  core/src/auth_env_telemetry.rs: missing websocket_connect_timeout_ms in
  ModelProviderInfo initializer)
  - just fix -p codex-rmcp-client
  - just fix -p codex-core (hits the same unrelated auth_env_telemetry.rs
  error)
  - just fmt
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  nicholasclark-openai · 2026-03-18 21:29:37 -07:00
  b14689df3b
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• [apps] Add tool call meta. (#14647)

  - [x] Add resource_uri and other things to _meta to shortcut resource
  lookup and speed things up.

  Matthew Zeng · 2026-03-14 22:24:13 -07:00
  49edf311ac
• client: extend custom CA handling across HTTPS and websocket clients (#14239)

  ## Stacked PRs
  
  This work is now effectively split across two steps:
  
  - #14178: add custom CA support for browser and device-code login flows,
  docs, and hermetic subprocess tests
  - #14239: extend that shared custom CA handling across Codex HTTPS
  clients and secure websocket TLS
  
  Note: #14240 was merged into this branch while it was stacked on top of
  this PR. This PR now subsumes that websocket follow-up and should be
  treated as the combined change.
  
  Builds on top of #14178.
  
  ## Problem
  
  Custom CA support landed first in the login path, but the real
  requirement is broader. Codex constructs outbound TLS clients in
  multiple places, and both HTTPS and secure websocket paths can fail
  behind enterprise TLS interception if they do not honor
  `CODEX_CA_CERTIFICATE` or `SSL_CERT_FILE` consistently.
  
  This PR broadens the shared custom-CA logic beyond login and applies the
  same policy to websocket TLS, so the enterprise-proxy story is no longer
  split between “HTTPS works” and “websockets still fail”.
  
  ## What This Delivers
  
  Custom CA support is no longer limited to login. Codex outbound HTTPS
  clients and secure websocket connections can now honor the same
  `CODEX_CA_CERTIFICATE` / `SSL_CERT_FILE` configuration, so enterprise
  proxy/intercept setups work more consistently end-to-end.
  
  For users and operators, nothing new needs to be configured beyond the
  same CA env vars introduced in #14178. The change is that more of Codex
  now respects them, including websocket-backed flows that were previously
  still using default trust roots.
  
  I also manually validated the proxy path locally with mitmproxy using:
  `CODEX_CA_CERTIFICATE=~/.mitmproxy/mitmproxy-ca-cert.pem
  HTTPS_PROXY=http://127.0.0.1:8080 just codex`
  with mitmproxy installed via `brew install mitmproxy` and configured as
  the macOS system proxy.
  
  ## Mental model
  
  `codex-client` is now the owner of shared custom-CA policy for outbound
  TLS client construction. Reqwest callers start from the builder
  configuration they already need, then pass that builder through
  `build_reqwest_client_with_custom_ca(...)`. Websocket callers ask the
  same module for a rustls client config when a custom CA bundle is
  configured.
  
  The env precedence is the same everywhere:
  - `CODEX_CA_CERTIFICATE` wins
  - otherwise fall back to `SSL_CERT_FILE`
  - otherwise use system roots
  
  The helper is intentionally narrow. It loads every usable certificate
  from the configured PEM bundle into the appropriate root store and
  returns either a configured transport or a typed error that explains
  what went wrong.
  
  ## Non-goals
  
  This does not add handshake-level integration tests against a live TLS
  endpoint. It does not validate that the configured bundle forms a
  meaningful certificate chain. It also does not try to force every
  transport in the repo through one abstraction; it extends the shared CA
  policy across the reqwest and websocket paths that actually needed it.
  
  ## Tradeoffs
  
  The main tradeoff is centralizing CA behavior in `codex-client` while
  still leaving adoption up to call sites. That keeps the implementation
  additive and reviewable, but it means the rule "outbound Codex TLS that
  should honor enterprise roots must use the shared helper" is still
  partly enforced socially rather than by types.
  
  For websockets, the shared helper only builds an explicit rustls config
  when a custom CA bundle is configured. When no override env var is set,
  websocket callers still use their ordinary default connector path.
  
  ## Architecture
  
  `codex-client::custom_ca` now owns CA bundle selection, PEM
  normalization, mixed-section parsing, certificate extraction, typed
  CA-loading errors, and optional rustls client-config construction for
  websocket TLS.
  
  The affected consumers now call into that shared helper directly rather
  than carrying login-local CA behavior:
  - backend-client
  - cloud-tasks
  - RMCP client paths that use `reqwest`
  - TUI voice HTTP paths
  - `codex-core` default reqwest client construction
  - `codex-api` websocket clients for both responses and realtime
  websocket connections
  
  The subprocess CA probe, env-sensitive integration tests, and shared PEM
  fixtures also live in `codex-client`, which is now the actual owner of
  the behavior they exercise.
  
  ## Observability
  
  The shared CA path logs:
  - which environment variable selected the bundle
  - which path was loaded
  - how many certificates were accepted
  - when `TRUSTED CERTIFICATE` labels were normalized
  - when CRLs were ignored
  - where client construction failed
  
  Returned errors remain user-facing and include the relevant env var,
  path, and remediation hint. That same error model now applies whether
  the failure surfaced while building a reqwest client or websocket TLS
  configuration.
  
  ## Tests
  
  Pure unit tests in `codex-client` cover env precedence and PEM
  normalization behavior. Real client construction remains in subprocess
  tests so the suite can control process env and avoid the macOS seatbelt
  panic path that motivated the hermetic test split.
  
  The subprocess coverage verifies:
  - `CODEX_CA_CERTIFICATE` precedence over `SSL_CERT_FILE`
  - fallback to `SSL_CERT_FILE`
  - single-cert and multi-cert bundles
  - malformed and empty-file errors
  - OpenSSL `TRUSTED CERTIFICATE` handling
  - CRL tolerance for well-formed CRL sections
  
  The websocket side is covered by the existing `codex-api` / `codex-core`
  websocket test suites plus the manual mitmproxy validation above.
  
  ---------
  
  Co-authored-by: Ivan Zakharchanka <3axap4eHko@gmail.com>
  Co-authored-by: Codex <noreply@openai.com>

  Josh McKinney · 2026-03-13 00:59:26 +00:00
  6912da84a8
• Fix MCP tool calling (#14491)

  Properly escape mcp tool names and make tools only available via
  imports.

  pakrym-oai · 2026-03-12 13:38:52 -07:00
  dadffd27d4
• use scopes_supported for OAuth when present on MCP servers (#14419)

  Fixes [#8889](https://github.com/openai/codex/issues/8889).
  
  ## Summary
  - Discover and use advertised MCP OAuth `scopes_supported` when no
  explicit or configured scopes are present.
  - Apply the same scope precedence across `mcp add`, `mcp login`, skill
  dependency auto-login, and app-server MCP OAuth login.
  - Keep discovered scopes ephemeral and non-persistent.
  - Retry once without scopes for CLI and skill auto-login flows if the
  OAuth provider rejects discovered scopes.
  
  ## Motivation
  Some MCP servers advertise the scopes they expect clients to request
  during OAuth, but Codex was ignoring that metadata and typically
  starting OAuth with no scopes unless the user manually passed `--scopes`
  or configured `server.scopes`.
  
  That made compliant MCP servers harder to use out of the box and is the
  behavior described in
  [#8889](https://github.com/openai/codex/issues/8889).
  
  This change also brings our behavior in line with the MCP authorization
  spec's scope selection guidance:
  
  https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#scope-selection-strategy
  
  ## Behavior
  Scope selection now follows this order everywhere:
  1. Explicit request scopes / CLI `--scopes`
  2. Configured `server.scopes`
  3. Discovered `scopes_supported`
  4. Legacy empty-scope behavior
  
  Compatibility notes:
  - Existing working setups keep the same behavior because explicit and
  configured scopes still win.
  - Discovered scopes are never written back into config or token storage.
  - If discovery is missing, malformed, or empty, behavior falls back to
  the previous empty-scope path.
  - App-server login gets the same precedence rules, but does not add a
  transparent retry path in this change.
  
  ## Implementation
  - Extend streamable HTTP OAuth discovery to parse and normalize
  `scopes_supported`.
  - Add a shared MCP scope resolver in `core` so all login entrypoints use
  the same precedence rules.
  - Preserve provider callback errors from the OAuth flow so CLI/skill
  flows can safely distinguish provider rejections from other failures.
  - Reuse discovered scopes from the existing OAuth support check where
  possible instead of persisting new config.

  jgershen-oai · 2026-03-12 11:57:06 -07:00
  3e96c867fe
• feat: search_tool migrate to bring you own tool of Responses API (#14274)

  ## Why
  
  to support a new bring your own search tool in Responses
  API(https://developers.openai.com/api/docs/guides/tools-tool-search#client-executed-tool-search)
  we migrating our bm25 search tool to use official way to execute search
  on client and communicate additional tools to the model.
  
  ## What
  - replace the legacy `search_tool_bm25` flow with client-executed
  `tool_search`
  - add protocol, SSE, history, and normalization support for
  `tool_search_call` and `tool_search_output`
  - return namespaced Codex Apps search results and wire namespaced
  follow-up tool calls back into MCP dispatch

  Anton Panasenko · 2026-03-11 17:51:51 -07:00
  77b0c75267
• Stabilize RMCP streamable HTTP readiness tests (#13880)

  ## What changed
  - The RMCP streamable HTTP tests now wait for metadata and tool
  readiness before issuing tool calls.
  - OAuth state is isolated per test home.
  - The helper server startup path now uses bounded bind retries so
  transient `AddrInUse` collisions do not fail the test immediately.
  
  ## Why this fixes the flake
  - The old tests could begin issuing tool requests before the helper
  server had finished advertising its metadata and tools, so the first
  request sometimes raced the server startup sequence.
  - On top of that, shared OAuth state and occasional bind collisions on
  CI runners introduced cross-test environmental noise unrelated to the
  functionality under test.
  - Readiness polling makes the client wait for an observable “server is
  ready” signal, while isolated state and bounded bind retries remove
  external contention that was causing intermittent failures.
  
  ## Scope
  - Test-only change.

  Ahmed Ibrahim · 2026-03-09 19:52:55 +00:00
  44ecc527cb
• Stabilize RMCP pid file cleanup test (#13881)

  ## What changed
  - The pid-file cleanup test now keeps polling when the pid file exists
  but is still empty.
  - Assertions only proceed once the wrapper has actually written the
  child pid.
  
  ## Why this fixes the flake
  - File creation and pid writing are not atomic as one logical action
  from the test’s point of view.
  - The previous test sometimes won the race and read the file in the tiny
  window after creation but before the pid bytes were flushed.
  - Treating “empty file” as “not ready yet” synchronizes the test on the
  real event we need: the wrapper has finished publishing the child pid.
  
  ## Scope
  - Test-only change.

  Ahmed Ibrahim · 2026-03-09 10:01:34 -07:00
  6052558a01
• [rmcp-client] Recover from streamable HTTP 404 sessions (#13514)

  ## Summary
  - add one-time session recovery in `RmcpClient` for streamable HTTP MCP
  `404` session expiry
  - rebuild the transport and retry the failed operation once after
  reinitializing the client state
  - extend the test server and integration coverage for `404`, `401`,
  single-retry, and non-session failure scenarios
  
  ## Testing
  - just fmt
  - cargo test -p codex-rmcp-client (the post-rebase run lost its final
  summary in the terminal; the suite had passed earlier before the rebase)
  - just fix -p codex-rmcp-client

  Casey Chow · 2026-03-06 10:02:42 -05:00
  b3765a07e8
• [elicitations] Switch to use MCP style elicitation payload for mcp tool approvals. (#13621)

  - [x] Switch to use MCP style elicitation payload for mcp tool
  approvals.
  - [ ] TODO: Update the UI to support the full spec.

  Matthew Zeng · 2026-03-06 01:50:26 -08:00
  98dca99db7
• Add oauth_resource handling for MCP login flows (#12866)

  Addresses bug https://github.com/openai/codex/issues/12589
  
  Builds on community PR #12763.
  
  This adds `oauth_resource` support for MCP `streamable_http` servers and
  wires it through the relevant config and login paths. It fixes the bug
  where the configured OAuth resource was not reliably included in the
  authorization request, causing MCP login to omit the expected
  `resource` parameter.

  Eric Traut · 2026-02-26 20:10:12 -08:00
  cee009d117
• Add configurable MCP OAuth callback URL for MCP login (#11382)

  ## Summary
  
  Implements a configurable MCP OAuth callback URL override for `codex mcp
  login` and app-server OAuth login flows, including support for non-local
  callback endpoints (for example, devbox ingress URLs).
  
  ## What changed
  
  - Added new config key: `mcp_oauth_callback_url` in
  `~/.codex/config.toml`.
  - OAuth authorization now uses `mcp_oauth_callback_url` as
  `redirect_uri` when set.
  - Callback handling validates the callback path against the configured
  redirect URI path.
  - Listener bind behavior is now host-aware:
  - local callback URL hosts (`localhost`, `127.0.0.1`, `::1`) bind to
  `127.0.0.1`
    - non-local callback URL hosts bind to `0.0.0.0`
  - `mcp_oauth_callback_port` remains supported and is used for the
  listener port.
  - Wired through:
    - CLI MCP login flow
    - App-server MCP OAuth login flow
    - Skill dependency OAuth login flow
  - Updated config schema and config tests.
  
  ## Why
  
  Some environments need OAuth callbacks to land on a specific reachable
  URL (for example ingress in remote devboxes), not loopback. This change
  allows that while preserving local defaults for existing users.
  
  ## Backward compatibility
  
  - No behavior change when `mcp_oauth_callback_url` is unset.
  - Existing `mcp_oauth_callback_port` behavior remains intact.
  - Local callback flows continue binding to loopback by default.
  
  ## Testing
  
  - `cargo test -p codex-rmcp-client callback -- --nocapture`
  - `cargo test -p codex-core --lib mcp_oauth_callback -- --nocapture`
  - `cargo check -p codex-cli -p codex-app-server -p codex-rmcp-client`
  
  ## Example config
  
  ```toml
  mcp_oauth_callback_port = 5555
  mcp_oauth_callback_url = "https://<devbox>-<namespace>.gateway.<cluster>.internal.api.openai.org/callback"

  dkumar-oai · 2026-02-19 13:32:10 -08:00
  1070a0a712
• 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