247 Commits

• change collaboration mode to struct (#9793)

  Shouldn't cause behavioral change

  Ahmed Ibrahim · 2026-01-23 17:00:23 -08:00
  69cfc73dc6
• Print warning if we skip config loading (#9611)

  https://github.com/openai/codex/pull/9533 silently ignored config if
  untrusted. Instead, we still load it but disable it. Maybe we shouldn't
  try to parse it either...
  
  <img width="939" height="515" alt="Screenshot 2026-01-21 at 14 56 38"
  src="https://github.com/user-attachments/assets/e753cc22-dd99-4242-8ffe-7589e85bef66"
  />

  gt-oai · 2026-01-23 20:06:37 +00:00
  7938c170d9
• feat(app-server) Expose personality (#9674)

  ### Motivation
  Exposes a per-thread / per-turn `personality` override in the v2
  app-server API so clients can influence model communication style at
  thread/turn start. Ensures the override is passed into the session
  configuration resolution so it becomes effective for subsequent turns
  and headless runners.
  
  ### Testing
  - [x] Add an integration-style test
  `turn_start_accepts_personality_override_v2` in
  `codex-rs/app-server/tests/suite/v2/turn_start.rs` that verifies a
  `/personality` override results in a developer update message containing
  `<personality_spec>` in the outbound model request.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6971d646b1c08322a689a54d2649f3fe)

  Dylan Hurd · 2026-01-22 18:00:20 -08:00
  2b1ee24e11
• [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
• feat(app-server): support archived threads in thread/list (#9571)
  Owen Lin · 2026-01-22 12:22:36 -08:00
  733cb68496
• feat(app-server): thread/read API (#9569)
  Owen Lin · 2026-01-22 12:22:01 -08:00
  80240b3b67
• feat(core) update Personality on turn (#9644)

  ## Summary
  Support updating Personality mid-Thread via UserTurn/OverwriteTurn. This
  is explicitly unused by the clients so far, to simplify PRs - app-server
  and tui implementations will be follow-ups.
  
  ## Testing
  - [x] added integration tests

  Dylan Hurd · 2026-01-22 12:04:23 -08:00
  8b3521ee77
• Support end_turn flag (#9698)

  Experimental flag that signals the end of the turn.

  pakrym-oai · 2026-01-22 17:27:48 +00:00
  b511c38ddb
• Chore: add cmd related info to exec approval request (#9659)

  ### Summary
  We now rely purely on `item/commandExecution/requestApproval` item to
  render pending approval in VSCE and app. With v2 approach, it does not
  include the actual cmd that it is attempting and therefore we can only
  use `proposedExecpolicyAmendment` to render which can be incomplete.
  
  ### Reproduce
  * Add `prefix_rule(pattern=["echo"], decision="prompt")` to your
  `~/.codex/rules.default.rules`.
  * Ask to `Run  echo "approval-test" please` in VSCE or app. 
  * The pending approval protal does show up but with no content
  
  #### Example screenshot
  <img width="3434" height="3648" alt="Screenshot 2026-01-21 at 8 23
  25 PM"
  src="https://github.com/user-attachments/assets/75644837-21f1-40f8-8b02-858d361ff817"
  />
  
  #### Sample output
  ```
    {"method":"item/commandExecution/requestApproval","id":0,"params":{
      "threadId":"019be439-5a90-7600-a7ea-2d2dcc50302a",
      "turnId":"0",
      "itemId":"call_usgnQ4qEX5U9roNdjT7fPzhb",
      "reason":"`/bin/zsh -lc 'echo \"testing\"'` requires approval by policy",
      "proposedExecpolicyAmendment":null
    }}
  
  ```
  
  ### Fix
  Inlude `command` string, `cwd` and `command_actions` in
  `CommandExecutionRequestApprovalParams` so that consumers can display
  the correct command instead of relying on exec policy output.

  Shijie Rao · 2026-01-21 23:58:53 -08:00
  a4cb97ba5a
• feat(core) ModelInfo.model_instructions_template (#9597)

  ## Summary
  #9555 is the start of a rename, so I'm starting to standardize here.
  Sets up `model_instructions` templating with a strongly-typed object for
  injecting a personality block into the model instructions.
  
  ## Testing
  - [x] Added tests
  - [x] Ran locally

  Dylan Hurd · 2026-01-21 18:11:18 -08:00
  96a72828be
• Add layered config.toml support to app server (#9510)

  This PR adds support for chained (layered) config.toml file merging for
  clients that use the app server interface. This feature already exists
  for the TUI, but it does not work for GUI clients.
  
  It does the following:
  * Changes code paths for new thread, resume thread, and fork thread to
  use the effective config based on the cwd.
  * Updates the `config/read` API to accept an optional `cwd` parameter.
  If specified, the API returns the effective config based on that cwd
  path. Also optionally includes all layers including project config
  files. If cwd is not specified, the API falls back on its older behavior
  where it considers only the global (non-project) config files when
  computing the effective config.
  
  The changes in codex_message_processor.rs look deceptively large. They
  mostly just involve moving existing blocks of code to a later point in
  some functions so it can use the cwd to calculate the config.
  
  This PR builds upon #9509 and should be reviewed and merged after that
  PR.
  
  Tested:
  * Verified change with (dependent, as-yet-uncommitted) changes to IDE
  Extension and confirmed correct behavior
  
  The full fix requires additional changes in the IDE Extension code base,
  but they depend on this PR.

  Eric Traut · 2026-01-21 14:21:48 -08:00
  2ca9a56528
• Chore: update plan mode output in prompt (#9592)

  ### Summary
  * Update plan prompt output
  * Update requestUserInput response to be a single key value pair
  `answer: String`.

  Shijie Rao · 2026-01-21 14:12:18 -08:00
  3fcb40245e
• Update skills/list protocol readme (#9623)

  Updates readme example for `skills/list` to reflect latest response
  spec.

  Gav Verma · 2026-01-21 12:51:51 -08:00
  2e06d61339
• Reject ask user question tool in Execute and Custom (#9560)

  ## Summary
  - Keep `request_user_input` in the tool list but reject it at runtime in
  Execute/Custom modes with a clear model-facing error.
  - Add a session accessor for current collaboration mode and enforce the
  gate in the request_user_input handler.
  - Update core/app-server tests to use Plan mode for success and add
  Execute/Custom rejection coverage.

  charley-oai · 2026-01-20 18:32:17 -08:00
  0523a259c8
• Show session header before configuration (#9568)

  We were skipping if we know the model. We shouldn't

  Ahmed Ibrahim · 2026-01-21 02:13:54 +00:00
  3a0eeb8edf
• Add total (non-partial) TextElement placeholder accessors (#9545)

  ## Summary
  - Make `TextElement` placeholders private and add a text-backed accessor
  to avoid assuming `Some`.
  - Since they are optional in the protocol, we want to make sure any
  accessors properly handle the None case (getting the placeholder using
  the byte range in the text)
  - Preserve placeholders during protocol/app-server conversions using the
  accessor fallback.
  - Update TUI composer/remap logic and tests to use the new
  constructor/accessor.

  charley-oai · 2026-01-20 14:04:11 -08:00
  be9e55c5fc
• fix(core) Preserve base_instructions in SessionMeta (#9427)

  ## Summary
  This PR consolidates base_instructions onto SessionMeta /
  SessionConfiguration, so we ensure `base_instructions` is set once per
  session and should be (mostly) immutable, unless:
  - overridden by config on resume / fork
  - sub-agent tasks, like review or collab
  
  
  In a future PR, we should convert all references to `base_instructions`
  to consistently used the typed struct, so it's less likely that we put
  other strings there. See #9423. However, this PR is already quite
  complex, so I'm deferring that to a follow-up.
  
  ## Testing
  - [x] Added a resume test to assert that instructions are preserved. In
  particular, `resume_switches_models_preserves_base_instructions` fails
  against main.
  
  Existing test coverage thats assert base instructions are preserved
  across multiple requests in a session:
  - Manual compact keeps baseline instructions:
  core/tests/suite/compact.rs:199
  - Auto-compact keeps baseline instructions:
  core/tests/suite/compact.rs:1142
  - Prompt caching reuses the same instructions across two requests:
  core/tests/suite/prompt_caching.rs:150 and
  core/tests/suite/prompt_caching.rs:157
  - Prompt caching with explicit expected string across two requests:
  core/tests/suite/prompt_caching.rs:213 and
  core/tests/suite/prompt_caching.rs:222
  - Resume with model switch keeps original instructions:
  core/tests/suite/resume.rs:136
  - Compact/resume/fork uses request 0 instructions for later expected
  payloads: core/tests/suite/compact_resume_fork.rs:215

  Dylan Hurd · 2026-01-19 21:59:36 -08:00
  675f165c56
• Feat: request user input tool (#9472)

  ### Summary
  * Add `requestUserInput` tool that the model can use for gather
  feedback/asking question mid turn.
  
  
  ### Tool input schema
  ```
  {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "requestUserInput input",
    "type": "object",
    "additionalProperties": false,
    "required": ["questions"],
    "properties": {
      "questions": {
        "type": "array",
        "description": "Questions to show the user (1-3). Prefer 1 unless multiple independent decisions block progress.",
        "minItems": 1,
        "maxItems": 3,
        "items": {
          "type": "object",
          "additionalProperties": false,
          "required": ["id", "header", "question"],
          "properties": {
            "id": {
              "type": "string",
              "description": "Stable identifier for mapping answers (snake_case)."
            },
            "header": {
              "type": "string",
              "description": "Short header label shown in the UI (12 or fewer chars)."
            },
            "question": {
              "type": "string",
              "description": "Single-sentence prompt shown to the user."
            },
            "options": {
              "type": "array",
              "description": "Optional 2-3 mutually exclusive choices. Put the recommended option first and suffix its label with \"(Recommended)\". Only include \"Other\" option if we want to include a free form option. If the question is free form in nature, do not include any option.",
              "minItems": 2,
              "maxItems": 3,
              "items": {
                "type": "object",
                "additionalProperties": false,
                "required": ["value", "label", "description"],
                "properties": {
                  "value": {
                    "type": "string",
                    "description": "Machine-readable value (snake_case)."
                  },
                  "label": {
                    "type": "string",
                    "description": "User-facing label (1-5 words)."
                  },
                  "description": {
                    "type": "string",
                    "description": "One short sentence explaining impact/tradeoff if selected."
                  }
                }
              }
            }
          }
        }
      }
    }
  }
  ```
  
  ### Tool output schema
  ```
  {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "requestUserInput output",
    "type": "object",
    "additionalProperties": false,
    "required": ["answers"],
    "properties": {
      "answers": {
        "type": "object",
        "description": "Map of question id to user answer.",
        "additionalProperties": {
          "type": "object",
          "additionalProperties": false,
          "required": ["selected"],
          "properties": {
            "selected": {
              "type": "array",
              "items": { "type": "string" }
            },
            "other": {
              "type": ["string", "null"]
            }
          }
        }
      }
    }
  }
  ```

  Shijie Rao · 2026-01-19 10:17:30 -08:00
  57ec3a8277
• Add collaboration modes test prompts (#9443)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Ahmed Ibrahim · 2026-01-18 11:39:08 -08:00
  f72f87fbee
• chore(instructions) Remove unread SessionMeta.instructions field (#9423)

  ### Description
  - Remove the now-unused `instructions` field from the session metadata
  to simplify SessionMeta and stop propagating transient instruction text
  through the rollout recorder API. This was only saving
  user_instructions, and was never being read.
  - Stop passing user instructions into the rollout writer at session
  creation so the rollout header only contains canonical session metadata.
  
  ### Testing
  
  - Ran `just fmt` which completed successfully.
  - Ran `just fix -p codex-protocol`, `just fix -p codex-core`, `just fix
  -p codex-app-server`, `just fix -p codex-tui`, and `just fix -p
  codex-tui2` which completed (Clippy fixes applied) as part of
  verification.
  - Ran `cargo test -p codex-protocol` which passed (28 tests).
  - Ran `cargo test -p codex-core` which showed failures in a small set of
  tests (not caused by the protocol type change directly):
  `default_client::tests::test_create_client_sets_default_headers`,
  several `models_manager::manager::tests::refresh_available_models_*`,
  and `shell_snapshot::tests::linux_sh_snapshot_includes_sections` (these
  tests failed in this CI run).
  - Ran `cargo test -p codex-app-server` which reported several failing
  integration tests (including
  `suite::codex_message_processor_flow::test_codex_jsonrpc_conversation_flow`,
  `suite::output_schema::send_user_turn_*`, and
  `suite::user_agent::get_user_agent_returns_current_codex_user_agent`).
  - `cargo test -p codex-tui` and `cargo test -p codex-tui2` were
  attempted but aborted due to disk space exhaustion (`No space left on
  device`).
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_696bd8ce632483228d298cf07c7eb41c)

  Dylan Hurd · 2026-01-17 16:02:28 -08:00
  80d7a5d7fe
• Expose collaboration presets (#9421)

  Expose collaboration presets for clients
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  Ahmed Ibrahim · 2026-01-17 12:32:50 -08:00
  8f0e0300d2
• Add collaboration_mode override to turns (#9408)
  Ahmed Ibrahim · 2026-01-16 21:51:25 -08:00
  146d54cede
• Support enable/disable skill via config/api. (#9328)

  In config.toml:
  ```
  [[skills.config]]
  path = "/Users/xl/.codex/skills/my_skill/SKILL.md"
  enabled = false
  ```
  
  API:
  skills/list, skills/config/write

  xl-openai · 2026-01-16 20:22:05 -08:00
  ad8bf59cbf
• feat: show forked from session id in /status (#9330)

  Summary:
  - Add forked_from to SessionMeta/SessionConfiguredEvent and persist it
  for forked sessions.
  - Surface forked_from in /status for tui + tui2 and add snapshots.

  Anton Panasenko · 2026-01-16 13:41:46 -08:00
  c26fe64539
• feat(app-server, core): return threads by created_at or updated_at (#9247)

  Add support for returning threads by either `created_at` OR `updated_at`
  descending. Previously core always returned threads ordered by
  `created_at`.
  
  This PR:
  - updates core to be able to list threads by `updated_at` OR
  `created_at` descending based on what the caller wants
  - also update `thread/list` in app-server to expose this (default to
  `created_at` if not specified)
  
  All existing codepaths (app-server, TUI) still default to `created_at`,
  so no behavior change is expected with this PR.
  
  **Implementation**
  To sort by `updated_at` is a bit nontrivial (whereas `created_at` is
  easy due to the way we structure the folders and filenames on disk,
  which are all based on `created_at`).
  
  The most naive way to do this without introducing a cache file or sqlite
  DB (which we have to implement/maintain) is to scan files in reverse
  `created_at` order on disk, and look at the file's mtime (last modified
  timestamp according to the filesystem) until we reach `MAX_SCAN_FILES`
  (currently set to 10,000). Then, we can return the most recent N
  threads.
  
  Based on some quick and dirty benchmarking on my machine with ~1000
  rollout files, calling `thread/list` with limit 50, the `updated_at`
  path is slower as expected due to all the I/O:
  - updated-at: average 103.10 ms
  - created-at: average 41.10 ms
  
  Those absolute numbers aren't a big deal IMO, but we can certainly
  optimize this in a followup if needed by introducing more state stored
  on disk.
  
  **Caveat**
  There's also a limitation in that any files older than `MAX_SCAN_FILES`
  will be excluded, which means if a user continues a REALLY old thread,
  it's possible to not be included. In practice that should not be too big
  of an issue.
  
  If a user makes...
  - 1000 rollouts/day → threads older than 10 days won't show up
  - 100 rollouts/day → ~100 days
  
  If this becomes a problem for some reason, even more motivation to
  implement an updated_at cache.

  Owen Lin · 2026-01-16 20:58:55 +00:00
  f1653dd4d3
• feat: collab wait multiple IDs (#9294)
  jif-oai · 2026-01-16 12:05:04 +01:00
  c576756c81
• Add text element metadata to protocol, app server, and core (#9331)

  The second part of breaking up PR
  https://github.com/openai/codex/pull/9116
  
  Summary:
  
  - Add `TextElement` / `ByteRange` to protocol user inputs and user
  message events with defaults.
  - Thread `text_elements` through app-server v1/v2 request handling and
  history rebuild.
  - Preserve UI metadata only in user input/events (not `ContentItem`)
  while keeping local image attachments in user events for rehydration.
  
  Details:
  
  - Protocol: `UserInput::Text` carries `text_elements`;
  `UserMessageEvent` carries `text_elements` + `local_images`.
  Serialization includes empty vectors for backward compatibility.
  - app-server-protocol: v1 defines `V1TextElement` / `V1ByteRange` in
  camelCase with conversions; v2 uses its own camelCase wrapper.
  - app-server: v1/v2 input mapping includes `text_elements`; thread
  history rebuilds include them.
  - Core: user event emission preserves UI metadata while model history
  stays clean; history replay round-trips the metadata.

  charley-oai · 2026-01-15 17:26:41 -08:00
  1fa8350ae7
• Support SKILL.toml file. (#9125)

  We’re introducing a new SKILL.toml to hold skill metadata so Codex can
  deliver a richer Skills experience.
  
  Initial focus is the interface block:
  ```
  [interface]
  display_name = "Optional user-facing name"
  short_description = "Optional user-facing description"
  icon_small = "./assets/small-400px.png"
  icon_large = "./assets/large-logo.svg"
  brand_color = "#3B82F6"
  default_prompt = "Optional surrounding prompt to use the skill with"
  ```
  
  All fields are exposed via the app server API.
  display_name and short_description are consumed by the TUI.

  xl-openai · 2026-01-15 11:20:04 -08:00
  42fa4c237f
• feat: collab tools app-server event mapping (#9213)
  jif-oai · 2026-01-15 09:03:26 +00:00
  bad4c12b9d
• Add migration_markdown in model_info (#9219)

  Next step would be to clean Model Upgrade in model presets
  
  ---------
  
  Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
  Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>

  Ahmed Ibrahim · 2026-01-15 01:55:22 +00:00
  a09711332a
• Add text element metadata to types (#9235)

  Initial type tweaking PR to make the diff of
  https://github.com/openai/codex/pull/9116 smaller
  
  This should not change any behavior, just adds some fields to types

  charley-oai · 2026-01-14 16:41:50 -08:00
  4a9c2bcc5a
• s/mcp_server_requirements/mcp_servers (#9212)

  A simple `s/mcp_server_requirements/mcp_servers/g` for an unreleased
  feature. @bolinfest correctly pointed out, it's already in
  `requirements.toml` so the `_requirements` is redundant.

  gt-oai · 2026-01-14 18:41:52 +00:00
  fe1e0da102
• Use current model for review (#9179)

  Instead of having a hard-coded default review model, use the current
  model for running `/review` unless one is specified in the config.
  
  Also inherit current reasoning effort

  pakrym-oai · 2026-01-14 08:59:41 -08:00
  92472e7baa
• feat: add auto refresh on thread listeners (#9105)

  This PR is in the scope of multi-agent work. 
  
  An agent (=thread) can now spawn other agents. Those other agents are
  not attached to any clients. We need a way to make sure that the clients
  are aware of the new threads to look at (for approval for example). This
  PR adds a channel to the `ThreadManager` that pushes the ID of those
  newly created agents such that the client (here the app-server) can also
  subscribe to those ones.

  jif-oai · 2026-01-14 16:26:01 +00:00
  bcd7858ced
• Improve handling of config and rules errors for app server clients (#9182)

  When an invalid config.toml key or value is detected, the CLI currently
  just quits. This leaves the VSCE in a dead state.
  
  This PR changes the behavior to not quit and bubble up the config error
  to users to make it actionable. It also surfaces errors related to
  "rules" parsing.
  
  This allows us to surface these errors to users in the VSCE, like this:
  
  <img width="342" height="129" alt="Screenshot 2026-01-13 at 4 29 22 PM"
  src="https://github.com/user-attachments/assets/a79ffbe7-7604-400c-a304-c5165b6eebc4"
  />
  
  <img width="346" height="244" alt="Screenshot 2026-01-13 at 4 45 06 PM"
  src="https://github.com/user-attachments/assets/de874f7c-16a2-4a95-8c6d-15f10482e67b"
  />

  Eric Traut · 2026-01-13 17:57:09 -08:00
  31d9b6f4d2
• clean models manager (#9168)

  Have only the following Methods:
  - `list_models`: getting current available models
  - `try_list_models`: sync version no refresh for tui use
  - `get_default_model`: get the default model (should be tightened to
  core and received on session configuration)
  - `get_model_info`: get `ModelInfo` for a specific model (should be
  tightened to core but used in tests)
  - `refresh_if_new_etag`: trigger refresh on different etags
  
  Also move the cache to its own struct

  Ahmed Ibrahim · 2026-01-13 16:55:33 -08:00
  7e33ac7eb6
• feat(app-server): add an --analytics-default-enabled flag (#9118)

  Add a new `codex app-server --analytics-default-enabled` CLI flag that
  controls whether analytics are enabled by default.
  
  Analytics are disabled by default for app-server. Users have to
  explicitly opt in
  via the `analytics` section in the config.toml file.
  
  However, for first-party use cases like the VSCode IDE extension, we
  default analytics
  to be enabled by default by setting this flag. Users can still opt out
  by setting this
  in their config.toml:
  
  ```toml
  [analytics]
  enabled = false
  ```
  
  See https://developers.openai.com/codex/config-advanced/#metrics for
  more details.

  Owen Lin · 2026-01-13 11:59:39 -08:00
  bde734fd1e
• 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
• Assemble sandbox/approval/network prompts dynamically (#8961)

  - Add a single builder for developer permissions messaging that accepts
  SandboxPolicy and approval policy. This builder now drives the developer
  “permissions” message that’s injected at session start and any time
  sandbox/approval settings change.
  - Trim EnvironmentContext to only include cwd, writable roots, and
  shell; removed sandbox/approval/network duplication and adjusted XML
  serialization and tests accordingly.
  
  Follow-up: adding a config value to replace the developer permissions
  message for custom sandboxes.

  Ahmed Ibrahim · 2026-01-12 23:12:59 +00:00
  87f7226cca
• feat: hot reload mcp servers (#8957)

  ### Summary
  * Added `mcpServer/refresh` command to inform app servers and active
  threads to refresh mcpServer on next turn event.
  * Added `pending_mcp_server_refresh_config` to codex core so that if the
  value is populated, we reinitialize the mcp server manager on the thread
  level.
  * The config is updated on `mcpServer/refresh` command which we iterate
  through threads and provide with the latest config value after last
  write.

  Shijie Rao · 2026-01-12 11:17:50 -08:00
  3e91a95ce1
• 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
• fix(app-server): set originator header from initialize (re-revert) (#8988)

  Reapplies https://github.com/openai/codex/pull/8873 which was reverted
  due to merge conflicts

  Owen Lin · 2026-01-09 12:09:30 -08:00
  fbe883318d
• 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
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• nit: rename to analytics_enabled (#8978)
  jif-oai · 2026-01-09 17:18:42 +00:00
  ed64804cb5
• Revert "fix(app-server): set originator header from initialize JSON-RPC request" (#8986)

  Reverts openai/codex#8873

  jif-oai · 2026-01-09 17:00:53 +00:00
  5c380d5b1e
• Add config to disable /feedback (#8909)

  Some enterprises do not want their users to be able to `/feedback`.
  
  <img width="395" height="325" alt="image"
  src="https://github.com/user-attachments/assets/2dae9c0b-20c3-4a15-bcd3-0187857ebbd8"
  />
  
  Adds to `config.toml`:
  
  ```toml
  [feedback]
  enabled = false
  ```
  
  I've deliberately decided to:
  1. leave other references to `/feedback` (e.g. in the interrupt message,
  tips of the day) unchanged. I think we should continue to promote the
  feature even if it is not usable currently.
  2. leave the `/feedback` menu item selectable and display an error
  saying it's disabled, rather than remove the menu item (which I believe
  would raise more questions).
  
  but happy to discuss these.
  
  This will be followed by a change to requirements.toml that admins can
  use to force the value of feedback.enabled.

  gt-oai · 2026-01-09 16:33:48 +00:00
  5b5a5b92b5
• fix(app-server): set originator header from initialize JSON-RPC request (#8873)

  **Motivation**
  The `originator` header is important for codex-backend’s Responses API
  proxy because it identifies the real end client (codex cli, codex vscode
  extension, codex exec, future IDEs) and is used to categorize requests
  by client for our enterprise compliance API.
  
  Today the `originator` header is set by either:
  - the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var (our VSCode extension
  does this)
  - calling `set_default_originator()` which sets a global immutable
  singleton (`codex exec` does this)
  
  For `codex app-server`, we want the `initialize` JSON-RPC request to set
  that header because it is a natural place to do so. Example:
  ```json
  {
    "method": "initialize",
    "id": 0,
    "params": {
      "clientInfo": {
        "name": "codex_vscode",
        "title": "Codex VS Code Extension",
        "version": "0.1.0"
      }
    }
  }
  ```
  and when app-server receives that request, it can call
  `set_default_originator()`. This is a much more natural interface than
  asking third party developers to set an env var.
  
  One hiccup is that `originator()` reads the global singleton and locks
  in the value, preventing a later `set_default_originator()` call from
  setting it. This would be fine but is brittle, since any codepath that
  calls `originator()` before app-server can process an `initialize`
  JSON-RPC call would prevent app-server from setting it. This was
  actually the case with OTEL initialization which runs on boot, but I
  also saw this behavior in certain tests.
  
  Instead, what we now do is:
  - [unchanged] If `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var is set,
  `originator()` would return that value and `set_default_originator()`
  with some other value does NOT override it.
  - [new] If no env var is set, `originator()` would return the default
  value which is `codex_cli_rs` UNTIL `set_default_originator()` is called
  once, in which case it is set to the new value and becomes immutable.
  Later calls to `set_default_originator()` returns
  `SetOriginatorError::AlreadyInitialized`.
  
  **Other notes**
  - I updated `codex_core::otel_init::build_provider` to accepts a service
  name override, and app-server sends a hardcoded `codex_app_server`
  service name to distinguish it from `codex_cli_rs` used by default (e.g.
  TUI).
  
  **Next steps**
  - Update VSCE to set the proper value for `clientInfo.name` on
  `initialize` and drop the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var.
  - Delete support for `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` in codex-rs.

  Owen Lin · 2026-01-09 08:17:13 -08:00
  ea56186c2b
• [chore] move app server tests from chat completion to responses (#8939)

  We are deprecating chat completions. Move all app server tests from chat
  completion to responses.

  Celia Chen · 2026-01-08 22:27:55 +00:00
  be4364bb80
• feat: fork conversation/thread (#8866)

  ## Summary
  - add thread/conversation fork endpoints to the protocol (v1 + v2)
  - implement fork handling in app-server using thread manager and config
  overrides
  - add fork coverage in app-server tests and document `thread/fork` usage

  Anton Panasenko · 2026-01-08 12:54:20 -08:00
  41a317321d