334 Commits

• feat: do not close unified exec processes across turns (#10799)

  With this PR we do not close the unified exec processes (i.e. background
  terminals) at the end of a turn unless:
  * The user interrupt the turn
  * The user decide to clean the processes through `app-server` or
  `/clean`
  
  I made sure that `codex exec` correctly kill all the processes

  jif-oai · 2026-02-09 10:27:46 +00:00
  6cf61725d0
• feat: include NetworkConfig through ExecParams (#11105)

  This PR adds the following field to `Config`:
  
  ```rust
  pub network: Option<NetworkProxy>,
  ```
  
  Though for the moment, it will always be initialized as `None` (this
  will be addressed in a subsequent PR).
  
  This PR does the work to thread `network` through to `execute_exec_env()`, `process_exec_tool_call()`, and `UnifiedExecRuntime.run()` to ensure it is available whenever we span a process.

  Michael Bolin · 2026-02-09 03:32:17 +00:00
  383b45279e
• [apps] Improve app loading. (#10994)

  There are two concepts of apps that we load in the harness:
  
  - Directory apps, which is all the apps that the user can install.
  - Accessible apps, which is what the user actually installed and can be
  $ inserted and be used by the model. These are extracted from the tools
  that are loaded through the gateway MCP.
  
  Previously we wait for both sets of apps before returning the full apps
  list. Which causes many issues because accessible apps won't be
  available to the UI or the model if directory apps aren't loaded or
  failed to load.
  
  In this PR we are separating them so that accessible apps can be loaded
  separately and are instantly available to be shown in the UI and to be
  provided in model context. We also added an app-server event so that
  clients can subscribe to also get accessible apps without being blocked
  on the full app list.
  
  - [x] Separate accessible apps and directory apps loading.
  - [x] `app/list` request will also emit `app/list/updated` notifications
  that app-server clients can subscribe. Which allows clients to get
  accessible apps list to render in the $ menu without being blocked by
  directory apps.
  - [x] Cache both accessible and directory apps with 1 hour TTL to avoid
  reloading them when creating new threads.
  - [x] TUI improvements to redraw $ menu and /apps menu when app list is
  updated.

  Matthew Zeng · 2026-02-08 15:24:56 -08:00
  45b7763c3f
• Upgrade rmcp to 0.14 (#10718)

  - [x] Upgrade rmcp to 0.14

  Matthew Zeng · 2026-02-08 15:07:53 -08:00
  9f1009540b
• Defer persistence of rollout file (#11028)

  - Defer rollout persistence for fresh threads (`InitialHistory::New`):
  keep rollout events in memory and only materialize rollout file + state
  DB row on first `EventMsg::UserMessage`.
  - Keep precomputed rollout path available before materialization.
  - Change `thread/start` to build thread response from live config
  snapshot and optional precomputed path.
  - Improve pre-materialization behavior in app-server/TUI: clearer
  invalid-request errors for file-backed ops and a friendlier `/fork` “not
  ready yet” UX.
  - Update tests to match deferred semantics across
  start/read/archive/unarchive/fork/resume/review flows.
  - Improved resilience of user_shell test, which should be unrelated to
  this change but must be affected by timing changes
  
  For Reviewers:
  * The primary change is in recorder.rs
  * Most of the other changes were to fix up broken assumptions in
  existing tests
  
  Testing:
  * Manually tested CLI
  * Exercised app server paths by manually running IDE Extension with
  rebuilt CLI binary
  * Only user-visible change is that `/fork` in TUI generates visible
  error if used prior to first turn

  Eric Traut · 2026-02-07 23:05:03 -08:00
  b3de6c7f2b
• app-server: treat null mode developer instructions as built-in defaults (#10983)

  ## Summary
  - make `turn/start` normalize
  `collaborationMode.settings.developer_instructions: null` to the
  built-in instructions for the selected mode
  - prevent app-server clients from accidentally clearing mode-switch
  developer instructions by sending `null`
  - document this behavior in the v2 protocol and app-server docs
  
  ## What changed
  - `codex-rs/app-server/src/codex_message_processor.rs`
    - added a small `normalize_turn_start_collaboration_mode` helper
    - in `turn_start`, apply normalization before `OverrideTurnContext`
  - `codex-rs/app-server/tests/suite/v2/turn_start.rs`
  - extended `turn_start_accepts_collaboration_mode_override_v2` to assert
  the outgoing request includes default-mode instruction text when the
  client sends `developer_instructions: null`
  - `codex-rs/app-server-protocol/src/protocol/v2.rs`
  - clarified `TurnStartParams.collaboration_mode` docs:
  `settings.developer_instructions: null` means use built-in mode
  instructions
  - regenerated schema fixture:
  - `codex-rs/app-server-protocol/schema/typescript/v2/TurnStartParams.ts`
  - docs:
    - `codex-rs/app-server/README.md`
    - `codex-rs/docs/codex_mcp_interface.md`

  Charley Cunningham · 2026-02-07 12:59:41 -08:00
  e6662d6387
• feat(core): add network constraints schema to requirements.toml (#10958)

  ## Summary
  
  Add `requirements.toml` schema support for admin-defined network
  constraints in the requirements layer
  
  example config:
  
  ```
  [experimental_network]
  enabled = true
  allowed_domains = ["api.openai.com"]
  denied_domains = ["example.com"]
  ```

  viyatb-oai · 2026-02-07 19:48:24 +00:00
  739908a12c
• Add resume_agent collab tool (#10903)

  Summary
  - add the new resume_agent collab tool path through core, protocol, and
  the app server API, including the resume events
  - update the schema/TypeScript definitions plus docs so resume_agent
  appears in generated artifacts and README
  - note that resumed agents rehydrate rollout history without overwriting
  their base instructions
  
  Testing
  - Not run (not requested)

  jif-oai · 2026-02-07 17:31:45 +01:00
  62605fa471
• feat: add support for allowed_web_search_modes in requirements.toml (#10964)

  This PR makes it possible to disable live web search via an enterprise
  config even if the user is running in `--yolo` mode (though cached web
  search will still be available). To do this, create
  `/etc/codex/requirements.toml` as follows:
  
  ```toml
  # "live" is not allowed; "disabled" is allowed even though not listed explicitly.
  allowed_web_search_modes = ["cached"]
  ```
  
  Or set `requirements_toml_base64` MDM as explained on
  https://developers.openai.com/codex/security/#locations.
  
  ### Why
  - Enforce admin/MDM/`requirements.toml` constraints on web-search
  behavior, independent of user config and per-turn sandbox defaults.
  - Ensure per-turn config resolution and review-mode overrides never
  crash when constraints are present.
  
  ### What
  - Add `allowed_web_search_modes` to requirements parsing and surface it
  in app-server v2 `ConfigRequirements` (`allowedWebSearchModes`), with
  fixtures updated.
  - Define a requirements allowlist type (`WebSearchModeRequirement`) and
  normalize semantics:
    - `disabled` is always implicitly allowed (even if not listed).
    - An empty list is treated as `["disabled"]`.
  - Make `Config.web_search_mode` a `Constrained<WebSearchMode>` and apply
  requirements via `ConstrainedWithSource<WebSearchMode>`.
  - Update per-turn resolution (`resolve_web_search_mode_for_turn`) to:
  - Prefer `Live → Cached → Disabled` when
  `SandboxPolicy::DangerFullAccess` is active (subject to requirements),
  unless the user preference is explicitly `Disabled`.
  - Otherwise, honor the user’s preferred mode, falling back to an allowed
  mode when necessary.
  - Update TUI `/debug-config` and app-server mapping to display
  normalized `allowed_web_search_modes` (including implicit `disabled`).
  - Fix web-search integration tests to assert cached behavior under
  `SandboxPolicy::ReadOnly` (since `DangerFullAccess` legitimately prefers
  `live` when allowed).

  Michael Bolin · 2026-02-07 05:55:15 +00:00
  a118494323
• Fixed a flaky test (#10970)

  ## Summary
  
  Stabilize v2 review integration tests by making them hermetic with
  respect to model discovery.
  
  `app-server` review tests were intermittently timing out in CI
  (especially on Windows runners) because their test config allowed remote
  model refresh. During `thread/start`, the test process could issue live
  `/v1/models` requests, introducing external network latency and
  nondeterministic timing before review flow assertions.
  
  This change disables remote model fetching in the review test config
  helper used by these tests.

  Eric Traut · 2026-02-06 21:26:26 -08:00
  4d52428fa2
• app-server: print help message to console when starting websockets server (#10943)

  Follow-up to https://github.com/openai/codex/pull/10693
  
  <img width="596" height="77" alt="image"
  src="https://github.com/user-attachments/assets/9140df70-01d1-4c5a-85ee-ca15a09a0e77"
  />

  Javi · 2026-02-07 00:18:42 +00:00
  87ce50f118
• Treat compaction failure as failure state (#10927)

  - Return compaction errors from local and remote compaction flows.\n-
  Stop turns/tasks when auto-compaction fails instead of continuing
  execution.

  Ahmed Ibrahim · 2026-02-06 13:51:46 -08:00
  ba8b5d9018
• Add app configs to config.toml (#10822)

  Adds app configs to config.toml + tests

  canvrno-oai · 2026-02-06 10:29:08 -08:00
  36c16e0c58
• Removed "exec_policy" feature flag (#10851)

  This is no longer needed because it's on by default

  Eric Traut · 2026-02-06 08:59:47 -08:00
  4521a6e852
• 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
• Removed the "remote_compaction" feature flag (#10840)

  This feature is always on now

  Eric Traut · 2026-02-05 23:54:57 -08:00
  dd80e332c4
• feat(app-server): turn/steer API (#10821)

  This PR adds a dedicated `turn/steer` API for appending user input to an
  in-flight turn.
  
  ## Motivation
  Currently, steering in the app is implemented by just calling
  `turn/start` while a turn is running. This has some really weird quirks:
  - Client gets back a new `turn.id`, even though streamed
  events/approvals remained tied to the original active turn ID.
  - All the various turn-level override params on `turn/start` do not
  apply to the "steer", and would only apply to the next real turn.
  - There can also be a race condition where the client thinks the turn is
  active but the server has already completed it, so there might be bugs
  if the client has baked in some client-specific behavior thinking it's a
  steer when in fact the server kicked off a new turn. This is
  particularly possible when running a client against a remote app-server.
  
  Having a dedicated `turn/steer` API eliminates all those quirks.
  
  `turn/steer` behavior:
  - Requires an active turn on threadId. Returns a JSON-RPC error if there
  is no active turn.
  - If expectedTurnId is provided, it must match the active turn (more
  useful when connecting to a remote app-server).
  - Does not emit `turn/started`.
  - Does not accept turn overrides (`cwd`, `model`, `sandbox`, etc.) or
  `outputSchema` to accurately reflect that these are not applied when
  steering.

  Owen Lin · 2026-02-06 00:35:04 +00:00
  0d8b2b74c4
• Add stage field for experimental flags. (#10793)

  - [x] Add stage field for experimental flags.

  Matthew Zeng · 2026-02-05 23:31:04 +00:00
  729b016515
• Sync app-server requirements API with refreshed cloud loader (#10815)

  configRequirements/read now returns updated cloud requirements after
  login.

  xl-openai · 2026-02-05 14:43:31 -08:00
  43a7290f11
• Add app-server transport layer with websocket support (#10693)

  - Adds --listen <URL> to codex app-server with two listen modes:
        - stdio:// (default, existing behavior)
        - ws://IP:PORT (new websocket transport)
    - Refactors message routing to be connection-aware:
  - Tracks per-connection session state (initialize/experimental
  capability)
        - Routes responses/errors to the originating connection
  - Broadcasts server notifications/requests to initialized connections
  - Updates initialization semantics to be per connection (not
  process-global), and updates app-server docs accordingly.
  - Adds websocket accept/read/write handling (JSON-RPC per text frame,
  ping/pong handling, connection lifecycle events).
  
  Testing
  
  - Unit tests for transport URL parsing and targeted response/error
  routing.
    - New websocket integration test validating:
        - per-connection initialization requirements
        - no cross-connection response leakage
        - same request IDs on different connections route independently.

  Max Johnson · 2026-02-05 20:56:34 +00:00
  8473096efb
• [app-server] Add a method to list experimental features. (#10721)

  - [x] Add a method to list experimental features.

  Matthew Zeng · 2026-02-05 20:04:01 +00:00
  7e81f63698
• fix(auth): isolate chatgptAuthTokens concept to auth manager and app-server (#10423)

  So that the rest of the codebase (like TUI) don't need to be concerned
  whether ChatGPT auth was handled by Codex itself or passed in via
  app-server's external auth mode.

  Owen Lin · 2026-02-05 10:46:06 -08:00
  3582b74d01
• Leverage state DB metadata for thread summaries (#10621)

  Summary:
  - read conversation summaries and cwd info from the state DB when
  possible so we no longer rely on rollout files for metadata and avoid
  extra I/O
  - persist CLI version in thread metadata, surface it through summary
  builders, and add the necessary DB migration hooks
  - simplify thread listing by using enriched state DB data directly
  rather than reading rollout heads
  
  Testing:
  - Not run (not requested)

  jif-oai · 2026-02-05 16:39:11 +00:00
  9ee746afd6
• fix: flaky landlock (#10689)

  https://openai.slack.com/archives/C095U48JNL9/p1770243347893959

  jif-oai · 2026-02-05 10:30:18 +00:00
  c67120f4a0
• fix(core,app-server) resume with different model (#10719)

  ## Summary
  When resuming with a different model, we should also append a developer
  message with the model instructions
  
  ## Testing
  - [x] Added unit tests

  Dylan Hurd · 2026-02-05 00:40:05 -08:00
  fe8b474acd
• Reload cloud requirements after user login (#10725)

  Reload cloud requirements after user login so it could take effect
  immediately.

  xl-openai · 2026-02-05 00:27:16 -08:00
  1e1146cd29
• chore(config) Default Personality Pragmatic (#10705)

  ## Summary
  Switch back to Pragmatic personality
  
  ## Testing
  - [x] Updated unit tests

  Dylan Hurd · 2026-02-04 21:22:47 -08:00
  a05aadfa1b
• chore(core) personality migration tests (#10650)

  ## Summary
  Adds additional tests for personality edge cases
  
  ## Testing
  - [x] These are tests

  Dylan Hurd · 2026-02-04 19:03:14 -08:00
  73f32840c6
• chore(app-server): document experimental API opt-in (#10667)

  Add a section on how to opt in to the experimental API.

  Owen Lin · 2026-02-04 16:19:13 -08:00
  224c9f768d
• feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567)

  Took over the work that @aaronl-openai started here:
  https://github.com/openai/codex/pull/10397
  
  Now that app-server clients are able to set up custom tools (called
  `dynamic_tools` in app-server), we should expose a way for clients to
  pass in not just text, but also image outputs. This is something the
  Responses API already supports for function call outputs, where you can
  pass in either a string or an array of content outputs (text, image,
  file):
  https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image
  
  So let's just plumb it through in Codex (with the caveat that we only
  support text and image for now). This is implemented end-to-end across
  app-server v2 protocol types and core tool handling.
  
  ## Breaking API change
  NOTE: This introduces a breaking change with dynamic tools, but I think
  it's ok since this concept was only recently introduced
  (https://github.com/openai/codex/pull/9539) and it's better to get the
  API contract correct. I don't think there are any real consumers of this
  yet (not even the Codex App).
  
  Old shape:
  `{ "output": "dynamic-ok", "success": true }`
  
  New shape:
  ```
  {
      "contentItems": [
        { "type": "inputText", "text": "dynamic-ok" },
        { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" }
      ]
    "success": true
  }
  ```

  Owen Lin · 2026-02-04 16:12:47 -08:00
  5ea107a088
• add none personality option (#10688)

  - add none personality enum value and empty placeholder behavior\n- add
  docs/schema updates and e2e coverage

  Ahmed Ibrahim · 2026-02-04 15:40:33 -08:00
  f9c38f531c
• Fix test_shell_command_interruption flake (#10649)

  ## Human summary
  Sandboxing (specifically `LandlockRestrict`) is means that e.g. `sleep
  10` fails immediately. Therefore it cannot be interrupted.
  
  In suite::interrupt::test_shell_command_interruption, sleep 10 is issued
  at 17:28:16.554 (ToolCall: shell_command {"command":"sleep 10"...}),
  then fails at 17:28:16.589 with duration_ms=34, success=false,
  exit_code=101, and
      Sandbox(LandlockRestrict).
  
  ## Codex summary
  - set `sandbox_mode = "danger-full-access"` in `interrupt` and
  `v2/turn_interrupt` integration tests
  - set `sandbox: Some(SandboxMode::DangerFullAccess)` in
  `test_codex_jsonrpc_conversation_flow`
  - set `sandbox_policy: Some(SandboxPolicy::DangerFullAccess)` in
  `command_execution_notifications_include_process_id`
  
  ## Why
  On some Linux CI environments, command execution fails immediately with
  `LandlockRestrict` when sandboxed. These tests are intended to validate
  JSON-RPC/task lifecycle behavior (interrupt semantics, command
  notification shape/process id, request flow), but early sandbox startup
  failure changes turn flow and can trigger extra follow-up requests,
  causing flakes.
  
  This change removes environment-specific sandbox startup dependency from
  these tests while preserving their primary intent.
  
  ## Testing
  - not run in this environment (per request)

  gt-oai · 2026-02-04 22:19:06 +00:00
  7c6d21a414
• feat(linux-sandbox): add bwrap support (#9938)

  ## Summary
  This PR introduces a gated Bubblewrap (bwrap) Linux sandbox path. The
  curent Linux sandbox path relies on in-process restrictions (including
  Landlock). Bubblewrap gives us a more uniform filesystem isolation
  model, especially explicit writable roots with the option to make some
  directories read-only and granular network controls.
  
  This is behind a feature flag so we can validate behavior safely before
  making it the default.
  
  - Added temporary rollout flag:
    - `features.use_linux_sandbox_bwrap`
  - Preserved existing default path when the flag is off.
  - In Bubblewrap mode:
  - Added internal retry without /proc when /proc mount is not permitted
  by the host/container.

  viyatb-oai · 2026-02-04 11:13:17 -08:00
  ae4de43ccc
• Add thread/compact v2 (#10445)

  - add `thread/compact` as a trigger-only v2 RPC that submits
  `Op::Compact` and returns `{}` immediately.
  - add v2 compaction e2e coverage for success and invalid/unknown thread
  ids, and update protocol schemas/docs.

  Ahmed Ibrahim · 2026-02-03 18:15:55 -08:00
  38a47700b5
• Feat: add upgrade to app server modelList (#10556)

  ### Summary
  * Add model upgrade to listModel app server endpoint to support
  dynamically show model upgrade banner.

  Shijie Rao · 2026-02-03 14:53:36 -08:00
  750ebe154d
• feat: add APIs to list and download public remote skills (#10448)

  Add API to list / download from remote public skills

  xl-openai · 2026-02-03 14:09:37 -08:00
  f38d181795
• fix(app-server): fix approval events in review mode (#10416)

  One of our partners flagged that they were seeing the wrong order of
  events when running `review/start` with command exec approvals:
  ```
  {"method":"item/commandExecution/requestApproval","id":0,"params":{"threadId":"019c0b6b-6a42-7c02-99c4-98c80e88ac27","turnId":"0","itemId":"0","reason":"`/bin/zsh -lc 'git show b7a92b4eacf262c575f26b1e1ed621a357642e55 --stat'` requires approval: Xcode-required approval: Require explicit user confirmation for all commands.","proposedExecpolicyAmendment":null}}
  
  {"method":"item/started","params":{"item":{"type":"commandExecution","id":"call_AEjlbHqLYNM7kbU3N6uw1CNi","command":"/bin/zsh -lc 'git show b7a92b4eacf262c575f26b1e1ed621a357642e55 --stat'","cwd":"/Users/devingreen/Desktop/SampleProject","processId":null,"status":"inProgress","commandActions":[{"type":"unknown","command":"git show b7a92b4eacf262c575f26b1e1ed621a357642e55 --stat"}],"aggregatedOutput":null,"exitCode":null,"durationMs":null},"threadId":"019c0b6b-6a42-7c02-99c4-98c80e88ac27","turnId":"0"}}
  ```
  
  **Key fix**: In the review sub‑agent delegate we were forwarding exec
  (and patch) approvals using the parent turn id (`parent_ctx.sub_id`) as
  the approval call_id. That made
  `item/commandExecution/requestApproval.itemId` differ from the actual
  `item/started` id. We now forward the sub‑agent’s `call_id` from the
  approval event instead, so the approval item id matches the
  commandExecution item id in review flows.
  
  Here’s the expected event order for an inline `review/start` that
  triggers an exec approval after this fix:
  1. Response to review/start (JSON‑RPC response)
  - Includes `turn` (status inProgress) and `review_thread_id` (same as
  parent thread for inline).
  2. `turn/started` notification
    - turnId is the review turn id (e.g., "0").
  3. `item/started` → EnteredReviewMode
    - item.id == turnId, marks entry into review mode.
  4. `item/started` → commandExecution
    - item.id == <call_id> (e.g., "review-call-1"), status: inProgress.
  5. `item/commandExecution/requestApproval` request
    - JSON‑RPC request (not a notification).
    - params.itemId == <call_id> and params.turnId == turnId.
  6. Client replies to approval request (Approved / Declined / etc).
  7. If approved:
    - Optional `item/commandExecution/outputDelta` notifications.
    - `item/completed` → commandExecution with status and exitCode.
  8. Review finishes:
    - `item/started` → ExitedReviewMode
    - `item/completed` → ExitedReviewMode
    - (Agent message items may also appear, depending on review output.)
  9. `turn/completed` notification
  
  The key being #4 and #5 are now in the proper order with the correct
  item id.

  Owen Lin · 2026-02-03 12:08:17 -08:00
  d9ad5c3c49
• Inject CODEX_THREAD_ID into the terminal environment (#10096)

  Inject CODEX_THREAD_ID (when applicable) into the terminal environment
  so that the agent (and skills) can refer to the current thread / session
  ID.
  
  Discussion:
  https://openai.slack.com/archives/C095U48JNL9/p1769542492067109

  Max Johnson · 2026-02-03 11:31:12 -08:00
  66b196a725
• Cleanup collaboration mode variants (#10404)

  ## Summary
  
  This PR simplifies collaboration modes to the visible set `default |
  plan`, while preserving backward compatibility for older partners that
  may still send legacy mode
  names.
  
  Specifically:
  - Renames the old Code behavior to **Default**.
  - Keeps **Plan** as-is.
  - Removes **Custom** mode behavior (fallbacks now resolve to Default).
  - Keeps `PairProgramming` and `Execute` internally for compatibility
  plumbing, while removing them from schema/API and UI visibility.
  - Adds legacy input aliasing so older clients can still send old mode
  names.
  
  ## What Changed
  
  1. Mode enum and compatibility
  - `ModeKind` now uses `Plan` + `Default` as active/public modes.
  - `ModeKind::Default` deserialization accepts legacy values:
    - `code`
    - `pair_programming`
    - `execute`
    - `custom`
  - `PairProgramming` and `Execute` variants remain in code but are hidden
  from protocol/schema generation.
  - `Custom` variant is removed; previous custom fallbacks now map to
  `Default`.
  
  2. Collaboration presets and templates
  - Built-in presets now return only:
    - `Plan`
    - `Default`
  - Template rename:
    - `core/templates/collaboration_mode/code.md` -> `default.md`
  - `execute.md` and `pair_programming.md` remain on disk but are not
  surfaced in visible preset lists.
  
  3. TUI updates
  - Updated user-facing naming and prompts from “Code” to “Default”.
  - Updated mode-cycle and indicator behavior to reflect only visible
  `Plan` and `Default`.
  - Updated corresponding tests and snapshots.
  
  4. request_user_input behavior
  - `request_user_input` remains allowed only in `Plan` mode.
  - Rejection messaging now consistently treats non-plan modes as
  `Default`.
  
  5. Schemas
  - Regenerated config and app-server schemas.
  - Public schema types now advertise mode values as:
    - `plan`
    - `default`
  
  ## Backward Compatibility Notes
  
  - Incoming legacy mode names (`code`, `pair_programming`, `execute`,
  `custom`) are accepted and coerced to `default`.
  - Outgoing/public schema surfaces intentionally expose only `plan |
  default`.
  - This allows tolerant ingestion of older partner payloads while
  standardizing new integrations on the reduced mode set.
  
  ## Codex author
  `codex fork 019c1fae-693b-7840-b16e-9ad38ea0bd00`

  Charley Cunningham · 2026-02-03 09:23:53 -08:00
  d509df676b
• [Codex][CLI] Gate image inputs by model modalities (#10271)

  ###### Summary
  
  - Add input_modalities to model metadata so clients can determine
  supported input types.
  - Gate image paste/attach in TUI when the selected model does not
  support images.
  - Block submits that include images for unsupported models and show a
  clear warning.
  - Propagate modality metadata through app-server protocol/model-list
  responses.
    - Update related tests/fixtures.
  
    ###### Rationale
  
    - Models support different input modalities.
  - Clients need an explicit capability signal to prevent unsupported
  requests.
  - Backward-compatible defaults preserve existing behavior when modality
  metadata is absent.
  
    ###### Scope
  
    - codex-rs/protocol, codex-rs/core, codex-rs/tui
    - codex-rs/app-server-protocol, codex-rs/app-server
    - Generated app-server types / schema fixtures
  
    ###### Trade-offs
  
  - Default behavior assumes text + image when field is absent for
  compatibility.
    - Server-side validation remains the source of truth.
  
    ###### Follow-up
  
  - Non-TUI clients should consume input_modalities to disable unsupported
  attachments.
  - Model catalogs should explicitly set input_modalities for text-only
  models.
  
    ###### Testing
  
    - cargo fmt --all
    - cargo test -p codex-tui
    - env -u GITHUB_APP_KEY cargo test -p codex-core --lib
    - just write-app-server-schema
  - cargo run -p codex-cli --bin codex -- app-server generate-ts --out
  app-server-types
    - test against local backend
    
  <img width="695" height="199" alt="image"
  src="https://github.com/user-attachments/assets/d22dd04f-5eba-4db9-a7c5-a2506f60ec44"
  />
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  Colin Young · 2026-02-02 18:56:39 -08:00
  7e07ec8f73
• Require models refresh on cli version mismatch (#10414)
  Ahmed Ibrahim · 2026-02-02 18:55:25 -08:00
  b8addcddb9
• chore: add phase to message responseitem (#10455)

  ### What
  
  add wiring for `phase` field on `ResponseItem::Message` to lay
  groundwork for differentiating model preambles and final messages.
  currently optional.
  
  follows pattern in #9698.
  
  updated schemas with `just write-app-server-schema` so we can see type
  changes.
  
  ### Tests
  Updated existing tests for SSE parsing and hydrating from history

  sayan-oai · 2026-02-03 02:52:26 +00:00
  fc05374344
• 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
• feat: add --experimental to generate-ts (#10402)

  Adding a `--experimental` flag to the `generate-ts` fct in the
  app-sever.
  
  It can be called through one of those 2 command
  ```
  just write-app-server-schema --experimental
  codex app-server generate-ts --experimental
  ```

  jif-oai · 2026-02-02 20:30:01 +00:00
  059d386f03
• feat: experimental flags (#10231)

  ## Problem being solved
  - We need a single, reliable way to mark app-server API surface as
  experimental so that:
    1. the runtime can reject experimental usage unless the client opts in
  2. generated TS/JSON schemas can exclude experimental methods/fields for
  stable clients.
  
  Right now that’s easy to drift or miss when done ad-hoc.
  
  ## How to declare experimental methods and fields
  - **Experimental method**: add `#[experimental("method/name")]` to the
  `ClientRequest` variant in `client_request_definitions!`.
  - **Experimental field**: on the params struct, derive `ExperimentalApi`
  and annotate the field with `#[experimental("method/name.field")]` + set
  `inspect_params: true` for the method variant so
  `ClientRequest::experimental_reason()` inspects params for experimental
  fields.
  
  ## How the macro solves it
  - The new derive macro lives in
  `codex-rs/codex-experimental-api-macros/src/lib.rs` and is used via
  `#[derive(ExperimentalApi)]` plus `#[experimental("reason")]`
  attributes.
  - **Structs**:
  - Generates `ExperimentalApi::experimental_reason(&self)` that checks
  only annotated fields.
    - The “presence” check is type-aware:
      - `Option<T>`: `is_some_and(...)` recursively checks inner.
      - `Vec`/`HashMap`/`BTreeMap`: must be non-empty.
      - `bool`: must be `true`.
      - Other types: considered present (returns `true`).
  - Registers each experimental field in an `inventory` with `(type_name,
  serialized field name, reason)` and exposes `EXPERIMENTAL_FIELDS` for
  that type. Field names are converted from `snake_case` to `camelCase`
  for schema/TS filtering.
  - **Enums**:
  - Generates an exhaustive `match` returning `Some(reason)` for annotated
  variants and `None` otherwise (no wildcard arm).
  - **Wiring**:
  - Runtime gating uses `ExperimentalApi::experimental_reason()` in
  `codex-rs/app-server/src/message_processor.rs` to reject requests unless
  `InitializeParams.capabilities.experimental_api == true`.
  - Schema/TS export filters use the inventory list and
  `EXPERIMENTAL_CLIENT_METHODS` from `client_request_definitions!` to
  strip experimental methods/fields when `experimental_api` is false.

  jif-oai · 2026-02-02 11:06:50 +00:00
  3cc9122ee2
• Bump thread updated_at on unarchive to refresh sidebar ordering (#10280)

  ## Summary
  - Touch restored rollout files on `thread/unarchive` so `updatedAt`
  reflects the unarchive time.
  - Add a regression test to ensure unarchiving bumps `updated_at` from an
  old mtime.
  
  ## Notes
  This fixes the UX issue where unarchived old threads don’t reappear near
  the top of recent threads.

  Charley Cunningham · 2026-02-01 12:53:47 -08:00
  d3514bbdd2
• chore(config) Rename config setting to personality (#10314)

  ## Summary
  Let's make the setting name consistent with the SlashCommand!
  
  ## Testing
  - [x] Updated tests

  Dylan Hurd · 2026-01-31 19:38:06 -08:00
  a33fa4bfe5
• feat(core,tui,app-server) personality migration (#10307)

  ## Summary
  Keep existing users on Pragmatic, to preserve behavior while new users
  default to Friendly
  
  ## Testing
  - [x] Tested locally
  - [x] add integration tests

  Dylan Hurd · 2026-01-31 17:25:14 -07:00
  0f9858394b
• chore(core) Default to friendly personality (#10305)

  ## Summary
  Update default personality to friendly
  
  ## Testing
  - [x] Unit tests pass

  Dylan Hurd · 2026-01-31 17:11:32 -07:00
  8a461765f3
• chore(app-server) add personality update test (#10306)

  ## Summary
  Add some additional validation to ensure app-server handles Personality
  changes
  
  ## Testing
  - [x] These are tests

  Dylan Hurd · 2026-01-31 14:49:55 -07:00
  ed9e02c9dc