41 Commits

• feat: load from plugins (#12864)

  Support loading plugins.
  
  Plugins can now be enabled via [plugins.<name>] in config.toml. They are
  loaded as first-class entities through PluginsManager, and their default
  skills/ and .mcp.json contributions are integrated into the existing
  skills and MCP flows.

  xl-openai · 2026-03-01 10:50:56 -08:00
  752402c4fe
• 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
• chore: remove codex-core public protocol/shell re-exports (#12432)

  ## Why
  
  `codex-rs/core/src/lib.rs` re-exported a broad set of types and modules
  from `codex-protocol` and `codex-shell-command`. That made it easy for
  workspace crates to import those APIs through `codex-core`, which in
  turn hides dependency edges and makes it harder to reduce compile-time
  coupling over time.
  
  This change removes those public re-exports so call sites must import
  from the source crates directly. Even when a crate still depends on
  `codex-core` today, this makes dependency boundaries explicit and
  unblocks future work to drop `codex-core` dependencies where possible.
  
  ## What Changed
  
  - Removed public re-exports from `codex-rs/core/src/lib.rs` for:
  - `codex_protocol::protocol` and related protocol/model types (including
  `InitialHistory`)
    - `codex_protocol::config_types` (`protocol_config_types`)
  - `codex_shell_command::{bash, is_dangerous_command, is_safe_command,
  parse_command, powershell}`
  - Migrated workspace Rust call sites to import directly from:
    - `codex_protocol::protocol`
    - `codex_protocol::config_types`
    - `codex_protocol::models`
    - `codex_shell_command`
  - Added explicit `Cargo.toml` dependencies (`codex-protocol` /
  `codex-shell-command`) in crates that now import those crates directly.
  - Kept `codex-core` internal modules compiling by using `pub(crate)`
  aliases in `core/src/lib.rs` (internal-only, not part of the public
  API).
  - Updated the two utility crates that can already drop a `codex-core`
  dependency edge entirely:
    - `codex-utils-approval-presets`
    - `codex-utils-cli`
  
  ## Verification
  
  - `cargo test -p codex-utils-approval-presets`
  - `cargo test -p codex-utils-cli`
  - `cargo check --workspace --all-targets`
  - `just clippy`

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• 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
• feat: split codex-common into smaller utils crates (#11422)

  We are removing feature-gated shared crates from the `codex-rs`
  workspace. `codex-common` grouped several unrelated utilities behind
  `[features]`, which made dependency boundaries harder to reason about
  and worked against the ongoing effort to eliminate feature flags from
  workspace crates.
  
  Splitting these utilities into dedicated crates under `utils/` aligns
  this area with existing workspace structure and keeps each dependency
  explicit at the crate boundary.
  
  ## What changed
  
  - Removed `codex-rs/common` (`codex-common`) from workspace members and
  workspace dependencies.
  - Added six new utility crates under `codex-rs/utils/`:
    - `codex-utils-cli`
    - `codex-utils-elapsed`
    - `codex-utils-sandbox-summary`
    - `codex-utils-approval-presets`
    - `codex-utils-oss`
    - `codex-utils-fuzzy-match`
  - Migrated the corresponding modules out of `codex-common` into these
  crates (with tests), and added matching `BUILD.bazel` targets.
  - Updated direct consumers to use the new crates instead of
  `codex-common`:
    - `codex-rs/cli`
    - `codex-rs/tui`
    - `codex-rs/exec`
    - `codex-rs/app-server`
    - `codex-rs/mcp-server`
    - `codex-rs/chatgpt`
    - `codex-rs/cloud-tasks`
  - Updated workspace lockfile entries to reflect the new dependency graph
  and removal of `codex-common`.

  Michael Bolin · 2026-02-11 12:59:24 +00:00
  8b7f8af343
• Handle required MCP startup failures across components (#10902)

  Summary
  - add a `required` flag for MCP servers everywhere config/CLI data is
  touched so mandatory helpers can be round-tripped
  - have `codex exec` and `codex app-server` thread start/resume fail fast
  when required MCPs fail to initialize

  jif-oai · 2026-02-06 17:14:37 +01:00
  aab61934af
• [skills] Auto install MCP dependencies when running skils with dependency specs. (#9982)

  Auto install MCP dependencies when running skils with dependency specs.

  Matthew Zeng · 2026-01-27 19:02:45 -08:00
  3bb8e69dd3
• Add MCP server scopes config and use it as fallback for OAuth login (#9647)

  ### Motivation
  - Allow MCP OAuth flows to request scopes defined in `config.toml`
  instead of requiring users to always pass `--scopes` on the CLI.
  CLI/remote parameters should still override config values.
  
  ### Description
  - Add optional `scopes: Option<Vec<String>>` to `McpServerConfig` and
  `RawMcpServerConfig`, and propagate it through deserialization and the
  built config types.
  - Serialize `scopes` into the MCP server TOML via
  `serialize_mcp_server_table` in `core/src/config/edit.rs` and include
  `scopes` in the generated config schema (`core/config.schema.json`).
  - CLI: update `codex-rs/cli/src/mcp_cmd.rs` `run_login` to fall back to
  `server.scopes` when the `--scopes` flag is empty, with explicit CLI
  scopes still taking precedence.
  - App server: update
  `codex-rs/app-server/src/codex_message_processor.rs`
  `mcp_server_oauth_login` to use `params.scopes.or_else(||
  server.scopes.clone())` so the RPC path also respects configured scopes.
  - Update many test fixtures to initialize the new `scopes` field (set to
  `None`) so test code builds with the new struct field.
  
  ### Testing
  - Ran config tooling and formatters: `just write-config-schema`
  (succeeded), `just fmt` (succeeded), and `just fix -p codex-core`, `just
  fix -p codex-cli`, `just fix -p codex-app-server` (succeeded where
  applicable).
  - Ran unit tests for the CLI: `cargo test -p codex-cli` (passed).
  - Ran unit tests for core: `cargo test -p codex-core` (ran; many tests
  passed but several failed, including model refresh/403-related tests,
  shell snapshot/timeouts, and several `unified_exec` expectations).
  - Ran app-server tests: `cargo test -p codex-app-server` (ran; many
  integration-suite tests failed due to mocked/remote HTTP 401/403
  responses and wiremock expectations).
  
  If you want, I can split the tests into smaller focused runs or help
  debug the failing integration tests (they appear to be unrelated to the
  config change and stem from external HTTP/mocking behaviors encountered
  during the test runs).
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_69718f505914832ea1f334b3ba064553)

  blevy-oai · 2026-01-26 14:13:04 -08:00
  bdc4742bfc
• docs: fix outdated MCP subcommands documentation (#9622)
  Tien Nguyen · 2026-01-21 11:17:37 -08:00
  68b8381723
• Propagate MCP disabled reason (#9207)

  Indicate why MCP servers are disabled when they are disabled by
  requirements:
  
  ```
  ➜  codex git:(main) ✗ just codex mcp list
  cargo run --bin codex -- "$@"
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.27s
       Running `target/debug/codex mcp list`
  Name         Command          Args  Env  Cwd  Status                                                                  Auth
  docs         docs-mcp         -     -    -    disabled: requirements (MDM com.openai.codex:requirements_toml_base64)  Unsupported
  hello_world  hello-world-mcp  -     -    -    disabled: requirements (MDM com.openai.codex:requirements_toml_base64)  Unsupported
  
  ➜  codex git:(main) ✗ just c
  cargo run --bin codex -- "$@"
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.90s
       Running `target/debug/codex`
  ╭─────────────────────────────────────────────╮
  │ >_ OpenAI Codex (v0.0.0)                    │
  │                                             │
  │ model:     gpt-5.2 xhigh   /model to change │
  │ directory: ~/code/codex/codex-rs            │
  ╰─────────────────────────────────────────────╯
  
  /mcp
  
  🔌  MCP Tools
  
    • No MCP tools available.
  
    • docs (disabled)
      • Reason: requirements (MDM com.openai.codex:requirements_toml_base64)
  
    • hello_world (disabled)
      • Reason: requirements (MDM com.openai.codex:requirements_toml_base64)
  ```

  gt-oai · 2026-01-15 17:24:00 +00:00
  f6df1596eb
• Restrict MCP servers from requirements.toml (#9101)

  Enterprises want to restrict the MCP servers their users can use.
  
  Admins can now specify an allowlist of MCPs in `requirements.toml`. The
  MCP servers are matched on both Name and Transport (local path or HTTP
  URL) -- both must match to allow the MCP server. This prevents
  circumventing the allowlist by renaming MCP servers in user config. (It
  is still possible to replace the local path e.g. rewrite say
  `/usr/local/github-mcp` with a nefarious MCP. We could allow hash
  pinning in the future, but that would break updates. I also think this
  represents a broader, out-of-scope problem.)
  
  We introduce a new field to Constrained: "normalizer". In general, it is
  a fn(T) -> T and applies when `Constrained<T>.set()` is called. In this
  particular case, it disables MCP servers which do not match the
  allowlist. An alternative solution would remove this and instead throw a
  ConstraintError. That would stop Codex launching if any MCP server was
  configured which didn't match. I think this is bad.
  
  We currently reuse the enabled flag on MCP servers to disable them, but
  don't propagate any information about why they are disabled. I'd like to
  add that in a follow up PR, possibly by switching out enabled with an
  enum.
  
  In action:
  
  ```
  # MCP server config has two MCPs. We are going to allowlist one of them.
  ➜  codex git:(gt/restrict-mcps) ✗ cat ~/.codex/config.toml | grep mcp_servers -A1
  [mcp_servers.hello_world]
  command = "hello-world-mcp"
  --
  [mcp_servers.docs]
  command = "docs-mcp"
  
  # Restrict the MCPs to the hello_world MCP.
  ➜  codex git:(gt/restrict-mcps) ✗ defaults read com.openai.codex requirements_toml_base64 | base64 -d
  [mcp_server_allowlist.hello_world]
  command = "hello-world-mcp"
  
  # List the MCPs, observe hello_world is enabled and docs is disabled.
  ➜  codex git:(gt/restrict-mcps) ✗ just codex mcp list
  cargo run --bin codex -- "$@"
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.25s
       Running `target/debug/codex mcp list`
  Name         Command          Args  Env  Cwd  Status    Auth
  docs         docs-mcp         -     -    -    disabled  Unsupported
  hello_world  hello-world-mcp  -     -    -    enabled   Unsupported
  
  # Remove the restrictions.
  ➜  codex git:(gt/restrict-mcps) ✗ defaults delete com.openai.codex requirements_toml_base64
  
  # Observe both MCPs are enabled.
  ➜  codex git:(gt/restrict-mcps) ✗ just codex mcp list
  cargo run --bin codex -- "$@"
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.25s
       Running `target/debug/codex mcp list`
  Name         Command          Args  Env  Cwd  Status   Auth
  docs         docs-mcp         -     -    -    enabled  Unsupported
  hello_world  hello-world-mcp  -     -    -    enabled  Unsupported
  
  # A new requirements that updates the command to one that does not match.
  ➜  codex git:(gt/restrict-mcps) ✗ cat ~/requirements.toml
  [mcp_server_allowlist.hello_world]
  command = "hello-world-mcp-v2"
  
  # Use those requirements.
  ➜  codex git:(gt/restrict-mcps) ✗ defaults write com.openai.codex requirements_toml_base64 "$(base64 -i /Users/gt/requirements.toml)"
  
  # Observe both MCPs are disabled.
  ➜  codex git:(gt/restrict-mcps) ✗ just codex mcp list
  cargo run --bin codex -- "$@"
      Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.75s
       Running `target/debug/codex mcp list`
  Name         Command          Args  Env  Cwd  Status    Auth
  docs         docs-mcp         -     -    -    disabled  Unsupported
  hello_world  hello-world-mcp  -     -    -    disabled  Unsupported
  ```

  gt-oai · 2026-01-13 19:45:00 +00:00
  2651980bdf
• 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
• Chore: remove rmcp feature and exp flag usages (#8087)

  ### Summary
  With codesigning on Mac, Windows and Linux, we should be able to safely
  remove `features.rmcp_client` and `use_experimental_use_rmcp_client`
  check from the codebase now.

  Shijie Rao · 2025-12-20 14:18:00 -08:00
  987dd7fde3
• chore: cleanup Config instantiation codepaths (#8226)

  This PR does various types of cleanup before I can proceed with more
  ambitious changes to config loading.
  
  First, I noticed duplicated code across these two methods:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L314-L324
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L334-L344
  
  This has now been consolidated in
  `load_config_as_toml_with_cli_overrides()`.
  
  Further, I noticed that `Config::load_with_cli_overrides()` took two
  similar arguments:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L308-L311
  
  The difference between `cli_overrides` and `overrides` was not
  immediately obvious to me. At first glance, it appears that one should
  be able to be expressed in terms of the other, but it turns out that
  some fields of `ConfigOverrides` (such as `cwd` and
  `codex_linux_sandbox_exe`) are, by design, not configurable via a
  `.toml` file or a command-line `--config` flag.
  
  That said, I discovered that many callers of
  `Config::load_with_cli_overrides()` were passing
  `ConfigOverrides::default()` for `overrides`, so I created two separate
  methods:
  
  - `Config::load_with_cli_overrides(cli_overrides: Vec<(String,
  TomlValue)>)`
  - `Config::load_with_cli_overrides_and_harness_overrides(cli_overrides:
  Vec<(String, TomlValue)>, harness_overrides: ConfigOverrides)`
  
  The latter has a long name, as it is _not_ what should be used in the
  common case, so the extra typing is designed to draw attention to this
  fact. I tried to update the existing callsites to use the shorter name,
  where possible.
  
  Further, in the cases where `ConfigOverrides` is used, usually only a
  limited subset of fields are actually set, so I updated the declarations
  to leverage `..Default::default()` where possible.

  Michael Bolin · 2025-12-17 18:01:17 -08:00
  a8797019a1
• Update RMCP client config guidance (#7895)

  ## Summary
  - update CLI OAuth guidance to reference `features.rmcp_client` instead
  of the deprecated experimental flag
  - keep login/logout help text consistent with the new feature flag
  
  ## Testing
  - `cargo test -p codex-cli`
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_693b3e0bf27c832cb66d585847a552ab)

  Jeremy Rose · 2025-12-11 14:43:55 -08:00
  bacbe871c8
• fix(cli): correct mcp add usage order (#6827)

  ## Summary
  - add an explicit `override_usage` string to `AddArgs` so clap prints
  `<NAME>` before the command/url choice, matching the actual parser and
  docs
  
  ### Before
  
  Usage: codex mcp add [OPTIONS] <COMMAND|--url <URL>> <NAME>
  
  
  ### After
  
  Usage: codex mcp add [OPTIONS] <NAME> [--url <URL> | -- <COMMAND>...]
  
  ---------
  
  Signed-off-by: kyuheon-kr <kyuheon.kr@gmail.com>

  Kyuheon Kim · 2025-11-20 12:32:12 -08:00
  33a6cc66ab
• fix: Update the deprecation message to link to the docs (#6211)

  The deprecation message is currently a bit confusing. Users may not
  understand what is `[features].x`. I updated the docs and the
  deprecation message for more guidance.
  
  ---------
  
  Co-authored-by: Gabriel Peal <gpeal@users.noreply.github.com>

  Ahmed Ibrahim · 2025-11-04 21:02:27 +00:00
  d40a6b7f73
• Fix typo in error message for OAuth login (#6159)

  Error message for attempting to OAuth with a remote RCP is incorrect and
  misleading. The correct config is
  
  ```
  [features]
  rmcp_client = true
  ```
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Mark Hemmings · 2025-11-03 08:59:00 -08:00
  4d8b71d412
• Windows Sandbox - Alpha version (#4905)

  - Added the new codex-windows-sandbox crate that builds both a library
  entry point (run_windows_sandbox_capture) and a CLI executable to launch
  commands inside a Windows restricted-token sandbox, including ACL
  management, capability SID provisioning, network lockdown, and output
  capture
  (windows-sandbox-rs/src/lib.rs:167, windows-sandbox-rs/src/main.rs:54).
  - Introduced the experimental WindowsSandbox feature flag and wiring so
  Windows builds can opt into the sandbox:
  SandboxType::WindowsRestrictedToken, the in-process execution path, and
  platform sandbox selection now honor the flag (core/src/features.rs:47,
  core/src/config.rs:1224, core/src/safety.rs:19,
  core/src/sandboxing/mod.rs:69, core/src/exec.rs:79,
  core/src/exec.rs:172).
  - Updated workspace metadata to include the new crate and its
  Windows-specific dependencies so the core crate can link against it
  (codex-rs/
      Cargo.toml:91, core/Cargo.toml:86).
  - Added a PowerShell bootstrap script that installs the Windows
  toolchain, required CLI utilities, and builds the workspace to ease
  development
      on the platform (scripts/setup-windows.ps1:1).
  - Landed a Python smoke-test suite that exercises
  read-only/workspace-write policies, ACL behavior, and network denial for
  the Windows sandbox
      binary (windows-sandbox-rs/sandbox_smoketests.py:1).

  iceweasel-oai · 2025-10-30 15:51:57 -07:00
  87cce88f48
• nit: log rmcp_client (#5978)
  jif-oai · 2025-10-30 17:40:38 +00:00
  209af68611
• chore: unify config crates (#5958)
  jif-oai · 2025-10-30 10:28:32 +00:00
  aa76003e28
• chore: config editor (#5878)

  The goal is to have a single place where we actually write files
  
  In a follow-up PR, will move everything config related in a dedicated
  module and move the helpers in a dedicated file

  jif-oai · 2025-10-29 20:52:46 +00:00
  db31f6966d
• [MCP] Properly gate login after mcp add with experimental_use_rmcp_client (#5653)

  There was supposed to be a check here like in other places.

  Gabriel Peal · 2025-10-24 18:32:15 -04:00
  e2e1b65da6
• [MCP] Redact environment variable values in /mcp and mcp get (#5648)

  Fixes #5524

  Gabriel Peal · 2025-10-24 18:30:20 -04:00
  817d1508bc
• [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] Dedicated error message for GitHub MCPs missing a personal access token (#5393)

  Because the GitHub MCP is one of the most popular MCPs and it
  confusingly doesn't support OAuth, we should make it more clear how to
  make it work so people don't think Codex is broken.

  Gabriel Peal · 2025-10-20 16:23:26 -07:00
  ef806456e4
• [MCP] Add configuration options to enable or disable specific tools (#5367)

  Some MCP servers expose a lot of tools. In those cases, it is reasonable
  to allow/denylist tools for Codex to use so it doesn't get overwhelmed
  with too many tools.
  
  The new configuration options available in the `mcp_server` toml table
  are:
  * `enabled_tools`
  * `disabled_tools`
  
  Fixes #4796

  Gabriel Peal · 2025-10-20 15:35:36 -07:00
  740b4a95f4
• [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
• feat: feature flag (#4948)

  Add proper feature flag instead of having custom flags for everything.
  This is just for experimental/wip part of the code
  It can be used through CLI:
  ```bash
  codex --enable unified_exec --disable view_image_tool
  ```
  
  Or in the `config.toml`
  ```toml
  # Global toggles applied to every profile unless overridden.
  [features]
  apply_patch_freeform = true
  view_image_tool = false
  ```
  
  Follow-up:
  In a following PR, the goal is to have a default have `bundles` of
  features that we can associate to a model

  jif-oai · 2025-10-14 17:50:00 +00:00
  f7b4e29609
• [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 an enabled config field (#4917)

  This lets users more easily toggle MCP servers.

  Gabriel Peal · 2025-10-08 16:24:51 -04:00
  d3820f4782
• [MCP] Add support for streamable http servers with codex mcp add and replace bearer token handling (#4904)

  1. You can now add streamable http servers via the CLI
  2. As part of this, I'm also changing the existing bearer_token plain
  text config field with ane env var
  
  ```
  mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var=GITHUB_PAT
  ```

  Gabriel Peal · 2025-10-07 23:21:37 -04:00
  a43ae86b6c
• [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
• add(core): managed config (#3868)

  ## Summary
  
  - Factor `load_config_as_toml` into `core::config_loader` so config
  loading is reusable across callers.
  - Layer `~/.codex/config.toml`, optional `~/.codex/managed_config.toml`,
  and macOS managed preferences (base64) with recursive table merging and
  scoped threads per source.
  
  ## Config Flow
  
  ```
  Managed prefs (macOS profile: com.openai.codex/config_toml_base64)
                                 ▲
                                 │
  ~/.codex/managed_config.toml   │  (optional file-based override)
                                 ▲
                                 │
                  ~/.codex/config.toml (user-defined settings)
  ```
  
  - The loader searches under the resolved `CODEX_HOME` directory
  (defaults to `~/.codex`).
  - Managed configs let administrators ship fleet-wide overrides via
  device profiles which is useful for enforcing certain settings like
  sandbox or approval defaults.
  - For nested hash tables: overlays merge recursively. Child tables are
  merged key-by-key, while scalar or array values replace the prior layer
  entirely. This lets admins add or tweak individual fields without
  clobbering unrelated user settings.

  Fouad Matin · 2025-10-03 13:02:26 -07:00
  a5b7675e42
• [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
• fix: separate codex mcp into codex mcp-server and codex app-server (#4471)

  This is a very large PR with some non-backwards-compatible changes.
  
  Historically, `codex mcp` (or `codex mcp serve`) started a JSON-RPC-ish
  server that had two overlapping responsibilities:
  
  - Running an MCP server, providing some basic tool calls.
  - Running the app server used to power experiences such as the VS Code
  extension.
  
  This PR aims to separate these into distinct concepts:
  
  - `codex mcp-server` for the MCP server
  - `codex app-server` for the "application server"
  
  Note `codex mcp` still exists because it already has its own subcommands
  for MCP management (`list`, `add`, etc.)
  
  The MCP logic continues to live in `codex-rs/mcp-server` whereas the
  refactored app server logic is in the new `codex-rs/app-server` folder.
  Note that most of the existing integration tests in
  `codex-rs/mcp-server/tests/suite` were actually for the app server, so
  all the tests have been moved with the exception of
  `codex-rs/mcp-server/tests/suite/mod.rs`.
  
  Because this is already a large diff, I tried not to change more than I
  had to, so `codex-rs/app-server/tests/common/mcp_process.rs` still uses
  the name `McpProcess` for now, but I will do some mechanical renamings
  to things like `AppServer` in subsequent PRs.
  
  While `mcp-server` and `app-server` share some overlapping functionality
  (like reading streams of JSONL and dispatching based on message types)
  and some differences (completely different message types), I ended up
  doing a bit of copypasta between the two crates, as both have somewhat
  similar `message_processor.rs` and `outgoing_message.rs` files for now,
  though I expect them to diverge more in the near future.
  
  One material change is that of the initialize handshake for `codex
  app-server`, as we no longer use the MCP types for that handshake.
  Instead, we update `codex-rs/protocol/src/mcp_protocol.rs` to add an
  `Initialize` variant to `ClientRequest`, which takes the `ClientInfo`
  object we need to update the `USER_AGENT_SUFFIX` in
  `codex-rs/app-server/src/message_processor.rs`.
  
  One other material change is in
  `codex-rs/app-server/src/codex_message_processor.rs` where I eliminated
  a use of the `send_event_as_notification()` method I am generally trying
  to deprecate (because it blindly maps an `EventMsg` into a
  `JSONNotification`) in favor of `send_server_notification()`, which
  takes a `ServerNotification`, as that is intended to be a custom enum of
  all notification types supported by the app server. So to make this
  update, I had to introduce a new variant of `ServerNotification`,
  `SessionConfigured`, which is a non-backwards compatible change with the
  old `codex mcp`, and clients will have to be updated after the next
  release that contains this PR. Note that
  `codex-rs/app-server/tests/suite/list_resume.rs` also had to be update
  to reflect this change.
  
  I introduced `codex-rs/utils/json-to-toml/src/lib.rs` as a small utility
  crate to avoid some of the copying between `mcp-server` and
  `app-server`.

  Michael Bolin · 2025-09-30 07:06:18 +00:00
  d9dbf48828
• [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
• timeouts for mcp tool calls (#3959)

  defaults to 60sec, overridable with MCP_TOOL_TIMEOUT or on a per-server
  basis in the config.

  Jeremy Rose · 2025-09-22 10:30:59 -07:00
  19f46439ae
• initial mcp add interface (#3543)

  Adds `codex mcp add`, `codex mcp list`, `codex mcp remove`. Currently writes to global config.

  easong-openai · 2025-09-15 04:30:56 +00:00
  6a8e743d57