87 Commits

• config: enforce enterprise feature requirements (#13388)

  ## Why
  
  Enterprises can already constrain approvals, sandboxing, and web search
  through `requirements.toml` and MDM, but feature flags were still only
  configurable as managed defaults. That meant an enterprise could suggest
  feature values, but it could not actually pin them.
  
  This change closes that gap and makes enterprise feature requirements
  behave like the other constrained settings. The effective feature set
  now stays consistent with enterprise requirements during config load,
  when config writes are validated, and when runtime code mutates feature
  flags later in the session.
  
  It also tightens the runtime API for managed features. `ManagedFeatures`
  now follows the same constraint-oriented shape as `Constrained<T>`
  instead of exposing panic-prone mutation helpers, and production code
  can no longer construct it through an unconstrained `From<Features>`
  path.
  
  The PR also hardens the `compact_resume_fork` integration coverage on
  Windows. After the feature-management changes,
  `compact_resume_after_second_compaction_preserves_history` was
  overflowing the libtest/Tokio thread stacks on Windows, so the test now
  uses an explicit larger-stack harness as a pragmatic mitigation. That
  may not be the ideal root-cause fix, and it merits a parallel
  investigation into whether part of the async future chain should be
  boxed to reduce stack pressure instead.
  
  ## What Changed
  
  Enterprises can now pin feature values in `requirements.toml` with the
  requirements-side `features` table:
  
  ```toml
  [features]
  personality = true
  unified_exec = false
  ```
  
  Only canonical feature keys are allowed in the requirements `features`
  table; omitted keys remain unconstrained.
  
  - Added a requirements-side pinned feature map to
  `ConfigRequirementsToml`, threaded it through source-preserving
  requirements merge and normalization in `codex-config`, and made the
  TOML surface use `[features]` (while still accepting legacy
  `[feature_requirements]` for compatibility).
  - Exposed `featureRequirements` from `configRequirements/read`,
  regenerated the JSON/TypeScript schema artifacts, and updated the
  app-server README.
  - Wrapped the effective feature set in `ManagedFeatures`, backed by
  `ConstrainedWithSource<Features>`, and changed its API to mirror
  `Constrained<T>`: `can_set(...)`, `set(...) -> ConstraintResult<()>`,
  and result-returning `enable` / `disable` / `set_enabled` helpers.
  - Removed the legacy-usage and bulk-map passthroughs from
  `ManagedFeatures`; callers that need those behaviors now mutate a plain
  `Features` value and reapply it through `set(...)`, so the constrained
  wrapper remains the enforcement boundary.
  - Removed the production loophole for constructing unconstrained
  `ManagedFeatures`. Non-test code now creates it through the configured
  feature-loading path, and `impl From<Features> for ManagedFeatures` is
  restricted to `#[cfg(test)]`.
  - Rejected legacy feature aliases in enterprise feature requirements,
  and return a load error when a pinned combination cannot survive
  dependency normalization.
  - Validated config writes against enterprise feature requirements before
  persisting changes, including explicit conflicting writes and
  profile-specific feature states that normalize into invalid
  combinations.
  - Updated runtime and TUI feature-toggle paths to use the constrained
  setter API and to persist or apply the effective post-constraint value
  rather than the requested value.
  - Updated the `core_test_support` Bazel target to include the bundled
  core model-catalog fixtures in its runtime data, so helper code that
  resolves `core/models.json` through runfiles works in remote Bazel test
  environments.
  - Renamed the core config test coverage to emphasize that effective
  feature values are normalized at runtime, while conflicting persisted
  config writes are rejected.
  - Ran `compact_resume_after_second_compaction_preserves_history` inside
  an explicit 8 MiB test thread and Tokio runtime worker stack, following
  the existing larger-stack integration-test pattern, to keep the Windows
  `compact_resume_fork` test slice from aborting while a parallel
  investigation continues into whether some of the underlying async
  futures should be boxed.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core feature_requirements_ -- --nocapture`
  - `cargo test -p codex-core
  load_requirements_toml_produces_expected_constraints -- --nocapture`
  - `cargo test -p codex-core
  compact_resume_after_second_compaction_preserves_history -- --nocapture`
  - `cargo test -p codex-core compact_resume_fork -- --nocapture`
  - Re-ran the built `codex-core` `tests/all` binary with
  `RUST_MIN_STACK=262144` for
  `compact_resume_after_second_compaction_preserves_history` to confirm
  the explicit-stack harness fixes the deterministic low-stack repro.
  - `cargo test -p codex-core`
  - This still fails locally in unrelated integration areas that expect
  the `codex` / `test_stdio_server` binaries or hit existing `search_tool`
  wiremock mismatches.
  
  ## Docs
  
  `developers.openai.com/codex` should document the requirements-side
  `[features]` table for enterprise and MDM-managed configuration,
  including that it only accepts canonical feature keys and that
  conflicting config writes are rejected.

  Michael Bolin · 2026-03-04 04:40:22 +00:00
  bfff0c729f
• add fast mode toggle (#13212)

  - add a local Fast mode setting in codex-core (similar to how model id
  is currently stored on disk locally)
  - send `service_tier=priority` on requests when Fast is enabled
  - add `/fast` in the TUI and persist it locally
  - feature flag

  pash-openai · 2026-03-02 20:29:33 -08:00
  2f5b01abd6
• feat: add local date/timezone to turn environment context (#12947)

  ## Summary
  
  This PR includes the session's local date and timezone in the
  model-visible environment context and persists that data in
  `TurnContextItem`.
  
    ## What changed
  - captures the current local date and IANA timezone when building a turn
  context, with a UTC fallback if the timezone lookup fails
  - includes current_date and timezone in the serialized
  <environment_context> payload
  - stores those fields on TurnContextItem so they survive rollout/history
  handling, subagent review threads, and resume flows
  - treats date/timezone changes as environment updates, so prompt caching
  and context refresh logic do not silently reuse stale time context
  - updates tests to validate the new environment fields without depending
  on a single hardcoded environment-context string
  
  ## test
  
  built a local build and saw it in the rollout file:
  ```
  {"timestamp":"2026-02-26T21:39:50.737Z","type":"response_item","payload":{"type":"message","role":"user","content":[{"type":"input_text","text":"<environment_context>\n  <shell>zsh</shell>\n  <current_date>2026-02-26</current_date>\n  <timezone>America/Los_Angeles</timezone>\n</environment_context>"}]}}
  ```

  Celia Chen · 2026-02-26 23:17:35 +00:00
  90cc4e79a2
• Allow clients not to send summary as an option (#12950)

  Summary is a required parameter on UserTurn. Ideally we'd like the core
  to decide the appropriate summary level.
  
  Make the summary optional and don't send it when not needed.

  pakrym-oai · 2026-02-26 14:37:38 -08:00
  951a389654
• Use model catalog default for reasoning summary fallback (#12873)

  ## Summary
  - make `Config.model_reasoning_summary` optional so unset means use
  model default
  - resolve the optional config value to a concrete summary when building
  `TurnContext`
  - add protocol support for `default_reasoning_summary` in model metadata
  
  ## Validation
  - `cargo test -p codex-core --lib client::tests -- --nocapture`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pakrym-oai · 2026-02-26 09:31:13 -08:00
  ba41e84a50
• core: bundle settings diff updates into one dev/user envelope (#12417)

  ## Summary
  - bundle contextual prompt injection into at most one developer message
  plus one contextual user message in both:
    - per-turn settings updates
    - initial context insertion
  - preserve `<model_switch>` across compaction by rebuilding it through
  canonical initial-context injection, instead of relying on
  strip/reattach hacks
  - centralize contextual user fragment detection in one shared definition
  table and reuse it for parsing/compaction logic
  - keep `AGENTS.md` in its natural serialized format:
    - `# AGENTS.md instructions for {dirname}`
    - `<INSTRUCTIONS>...</INSTRUCTIONS>`
  - simplify related tests/helpers and accept the expected snapshot/layout
  updates from bundled multi-part messages
  
  ## Why
  The goal is to converge toward a simpler, more intentional prompt shape
  where contextual updates are consistently represented as one developer
  envelope plus one contextual user envelope, while keeping parsing and
  compaction behavior aligned with that representation.
  
  ## Notable details
  - the temporary `SettingsUpdateEnvelope` wrapper was removed; these
  paths now return `Vec<ResponseItem>` directly
  - local/remote compaction no longer rely on model-switch strip/restore
  helpers
  - contextual user detection is now driven by shared fragment definitions
  instead of ad hoc matcher assembly
  - AGENTS/user instructions are still the same logical context; only the
  synthetic `<user_instructions>` wrapper was replaced by the natural
  AGENTS text format
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-app-server
  codex_message_processor::tests::extract_conversation_summary_prefers_plain_user_messages
  -- --exact`
  - `cargo test -p codex-core
  compact::tests::collect_user_messages_filters_session_prefix_entries
  --lib -- --exact`
  - `cargo test -p codex-core --test all
  'suite::compact::snapshot_request_shape_pre_turn_compaction_strips_incoming_model_switch'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::compact_remote::snapshot_request_shape_remote_pre_turn_compaction_strips_incoming_model_switch'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_apps_guidance_as_developer_message_when_enabled'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_developer_instructions_message_in_request' --
  --exact`
  - `cargo test -p codex-core --test all
  'suite::client::includes_user_instructions_message_in_request' --
  --exact`
  - `cargo test -p codex-core --test all
  'suite::client::resume_includes_initial_messages_and_sends_prior_items'
  -- --exact`
  - `cargo test -p codex-core --test all
  'suite::review::review_input_isolated_from_parent_history' -- --exact`
  - `cargo test -p codex-exec --test all
  'suite::resume::exec_resume_last_respects_cwd_filter_and_all_flag' --
  --exact`
  - `cargo test -p core_test_support
  context_snapshot::tests::full_text_mode_preserves_unredacted_text --
  --exact`
  
  ## Notes
  - I also ran several targeted `compact`, `compact_remote`,
  `prompt_caching`, `model_visible_layout`, and `event_mapping` tests
  while iterating on prompt-shape changes.
  - I have not claimed a clean full-workspace `cargo test` from this
  environment because local sandbox/resource conditions have previously
  produced unrelated failures in large workspace runs.

  Charley Cunningham · 2026-02-26 00:12:08 -08:00
  07aefffb1f
• 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
• Fix compaction context reinjection and model baselines (#12252)

  ## Summary
  - move regular-turn context diff/full-context persistence into
  `run_turn` so pre-turn compaction runs before incoming context updates
  are recorded
  - after successful pre-turn compaction, rely on a cleared
  `reference_context_item` to trigger full context reinjection on the
  follow-up regular turn (manual `/compact` keeps replacement history
  summary-only and also clears the baseline)
  - preserve `<model_switch>` when full context is reinjected, and inject
  it *before* the rest of the full-context items
  - scope `reference_context_item` and `previous_model` to regular user
  turns only so standalone tasks (`/compact`, shell, review, undo) cannot
  suppress future reinjection or `<model_switch>` behavior
  - make context-diff persistence + `reference_context_item` updates
  explicit in the regular-turn path, with clearer docs/comments around the
  invariant
  - stop persisting local `/compact` `RolloutItem::TurnContext` snapshots
  (only regular turns persist `TurnContextItem` now)
  - simplify resume/fork previous-model/reference-baseline hydration by
  looking up the last surviving turn context from rollout lifecycle
  events, including rollback and compaction-crossing handling
  - remove the legacy fallback that guessed from bare `TurnContext`
  rollouts without lifecycle events
  - update compaction/remote-compaction/model-visible snapshots and
  compact test assertions (including remote compaction mock response
  shape)
  
  ## Why
  We were persisting incoming context items before spawning the regular
  turn task, which let pre-turn compaction requests accidentally include
  incoming context diffs without the new user message. Fixing that exposed
  follow-on baseline issues around `/compact`, resume/fork, and standalone
  tasks that could cause duplicate context injection or suppress
  `<model_switch>` instructions.
  
  This PR re-centers the invariants around regular turns:
  - regular turns persist model-visible context diffs/full reinjection and
  update the `reference_context_item`
  - standalone tasks do not advance those regular-turn baselines
  - compaction clears the baseline when replacement history may have
  stripped the referenced context diffs
  
  ## Follow-ups (TODOs left in code)
  - `TODO(ccunningham)`: fix rollback/backtracking baseline handling more
  comprehensively
  - `TODO(ccunningham)`: include pending incoming context items in
  pre-turn compaction threshold estimation
  - `TODO(ccunningham)`: inject updated personality spec alongside
  `<model_switch>` so some model-switch paths can avoid forced full
  reinjection
  - `TODO(ccunningham)`: review task turn lifecycle
  (`TurnStarted`/`TurnComplete`) behavior and emit task-start context
  diffs for task types that should have them (excluding `/compact`)
  
  ## Validation
  - `just fmt`
  - CI should cover the updated compaction/resume/model-visible snapshot
  expectations and rollout-hydration behavior
  - I did **not** rerun the full local test suite after the latest
  resume-lookup / rollout-persistence simplifications

  Charley Cunningham · 2026-02-20 23:13:08 -08:00
  bb0ac5be70
• chore: rm remote models fflag (#11699)

  rm `remote_models` feature flag.
  
  We see issues like #11527 when a user has `remote_models` disabled, as
  we always use the default fallback `ModelInfo`. This causes issues with
  model performance.
  
  Builds on #11690, which helps by warning the user when they are using
  the default fallback. This PR will make that happen much less frequently
  as an accidental consequence of disabling `remote_models`.

  sayan-oai · 2026-02-17 11:43:16 -08:00
  41800fc876
• feat: drop MCP managing tools if no MCP servers (#11900)

  Drop MCP tools if no MCP servers to save context
  
  For this https://github.com/openai/codex/issues/11049

  jif-oai · 2026-02-16 18:40:45 +00:00
  af434b4f71
• feat: introduce Permissions (#11633)

  ## Why
  We currently carry multiple permission-related concepts directly on
  `Config` for shell/unified-exec behavior (`approval_policy`,
  `sandbox_policy`, `network`, `shell_environment_policy`,
  `windows_sandbox_mode`).
  
  Consolidating these into one in-memory struct makes permission handling
  easier to reason about and sets up the next step: supporting named
  permission profiles (`[permissions.PROFILE_NAME]`) without changing
  behavior now.
  
  This change is mostly mechanical: it updates existing callsites to go
  through `config.permissions`, but it does not yet refactor those
  callsites to take a single `Permissions` value in places where multiple
  permission fields are still threaded separately.
  
  This PR intentionally **does not** change the on-disk `config.toml`
  format yet and keeps compatibility with legacy config keys.
  
  ## What Changed
  - Introduced `Permissions` in `core/src/config/mod.rs`.
  - Added `Config::permissions` and moved effective runtime permission
  fields under it:
    - `approval_policy`
    - `sandbox_policy`
    - `network`
    - `shell_environment_policy`
    - `windows_sandbox_mode`
  - Updated config loading/building so these effective values are still
  derived from the same existing config inputs and constraints.
  - Updated Windows sandbox helpers/resolution to read/write via
  `permissions`.
  - Threaded the new field through all permission consumers across core
  runtime, app-server, CLI/exec, TUI, and sandbox summary code.
  - Updated affected tests to reference `config.permissions.*`.
  - Renamed the struct/field from
  `EffectivePermissions`/`effective_permissions` to
  `Permissions`/`permissions` and aligned variable naming accordingly.
  
  ## Verification
  - `just fix -p codex-core -p codex-tui -p codex-cli -p codex-app-server
  -p codex-exec -p codex-utils-sandbox-summary`
  - `cargo build -p codex-core -p codex-tui -p codex-cli -p
  codex-app-server -p codex-exec -p codex-utils-sandbox-summary`

  Michael Bolin · 2026-02-12 14:42:54 -08:00
  a4cc1a4a85
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• fix(protocol): approval policy never prompt (#11288)

  This removes overly directed language about how the model should behave
  when it's in `approval_policy=never` mode.
  
  ---------
  
  Co-authored-by: Dylan Hurd <dylan.hurd@openai.com>

  Fouad Matin · 2026-02-10 09:27:46 -08:00
  693bac1851
• Remove offline fallback for models (#11238)

  # 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-02-09 16:58:54 -08:00
  a1abd53b6a
• Revert "chore: enable sub agents" (#11230)

  Reverts openai/codex#11173

  jif-oai · 2026-02-09 20:22:38 +00:00
  c2bfd1e473
• chore: enable sub agents (#11173)
  jif-oai · 2026-02-09 11:25:37 +00:00
  284c03ceab
• 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
• fix(core) switching model appends model instructions (#10651)

  ## Summary
  When switching models, we should append the instructions of the new
  model to the conversation as a developer message.
  
  ## Test
  - [x] Adds a unit test

  Dylan Hurd · 2026-02-05 05:50:38 +00:00
  e482978261
• feat: land unified_exec (#10641)

  Land `unified_exec` for all non-windows OS

  jif-oai · 2026-02-04 16:39:41 +00:00
  49dd67a260
• Update tests to stop using sse_completed fixture (#10638)

  Summary:
  - replace the `sse_completed` fixture and related JSON template with
  direct `responses::ev_completed` payload builders
  - cascade the new SSE helpers through all affected core tests for
  consistency and clarity
  - remove legacy fixtures that were no longer needed once the helpers are
  in place
  
  Testing:
  - Not run (not requested)

  pakrym-oai · 2026-02-04 08:38:06 -08:00
  0efd33f7f4
• 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
• Do not append items on override turn context (#10354)
  pakrym-oai · 2026-02-01 18:51:26 -08:00
  03fcd12e77
• fix: enable per-turn updates to web search mode (#10040)

  web_search can now be updated per-turn, for things like changes to
  sandbox policy.
  
  `SandboxPolicy::DangerFullAccess` now sets web_search to `live`, and the
  default is still `cached`.
  
  Added integration tests.

  sayan-oai · 2026-01-27 18:09:29 -08:00
  a90ab789c2
• remove sandbox globals. (#9797)

  Threads sandbox updates through OverrideTurnContext for active turn
  Passes computed sandbox type into safety/exec

  iceweasel-oai · 2026-01-27 11:04:23 -08:00
  c40ad65bd8
• make cached web_search client-side default (#9974)

  [Experiment](https://console.statsig.com/50aWbk2p4R76rNX9lN5VUw/experiments/codex_web_search_rollout/summary)
  for default cached `web_search` completed; cached chosen as default.
  
  Update client to reflect that.

  sayan-oai · 2026-01-26 21:25:40 -08:00
  0adcd8aa86
• change collaboration mode to struct (#9793)

  Shouldn't cause behavioral change

  Ahmed Ibrahim · 2026-01-23 17:00:23 -08:00
  69cfc73dc6
• 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
• 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 developer instructions (#9424)

  - Add additional instructions when they are available
  - Make sure to update them on change either UserInput or UserTurn

  Ahmed Ibrahim · 2026-01-18 01:31:14 +00:00
  1478a88eb0
• Add collaboration_mode override to turns (#9408)
  Ahmed Ibrahim · 2026-01-16 21:51:25 -08:00
  146d54cede
• [search] allow explicitly disabling web search (#9249)

  moving `web_search` rollout serverside, so need a way to explicitly
  disable search + signal eligibility from the client.
  
  - Add `x‑oai‑web‑search‑eligible` header that signifies whether the
  request can have web search.
  - Only attach the `web_search` tool when the resolved `WebSearchMode` is
  `Live` or `Cached`.

  sayan-oai · 2026-01-15 11:28:57 -08:00
  169201b1b5
• 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
• add WebSearchMode enum (#9216)

  ### What
  Add `WebSearchMode` enum (disabled, cached live, defaults to cached) to
  config + V2 protocol. This enum takes precedence over legacy flags:
  `web_search_cached`, `web_search_request`, and `tools.web_search`.
  
  Keep `--search` as live.
  
  ### Tests
  Added tests

  sayan-oai · 2026-01-14 12:51:42 -08:00
  5e426ac270
• 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
• 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
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• fix: reduce duplicate include_str!() calls (#8914)
  Michael Bolin · 2026-01-08 17:20:41 +00:00
  59d6937550
• fix: leverage find_resource! macro in load_sse_fixture_with_id (#8888)

  This helps prepare us for Bazel builds:
  https://github.com/openai/codex/pull/8875.

  Michael Bolin · 2026-01-08 09:34:05 -05:00
  7520d8ba58
• Merge Modelfamily into modelinfo (#8763)

  - Merge ModelFamily into ModelInfo
  - Remove logic for adding instructions to apply patch
  - Add compaction limit and visible context window to `ModelInfo`

  Ahmed Ibrahim · 2026-01-07 10:35:09 -08:00
  9179c9deac
• chore: unify conversation with thread name (#8830)

  Done and verified by Codex + refactor feature of RustRover

  jif-oai · 2026-01-07 17:04:53 +00:00
  116059c3a0
• feat: expose outputSchema to user_turn/turn_start app_server API (#8377)

  What changed
  - Added `outputSchema` support to the app-server APIs, mirroring `codex
  exec --output-schema` behavior.
  - V1 `sendUserTurn` now accepts `outputSchema` and constrains the final
  assistant message for that turn.
  - V2 `turn/start` now accepts `outputSchema` and constrains the final
  assistant message for that turn (explicitly per-turn only).
  
  Core behavior
  - `Op::UserTurn` already supported `final_output_json_schema`; now V1
  `sendUserTurn` forwards `outputSchema` into that field.
  - `Op::UserInput` now carries `final_output_json_schema` for per-turn
  settings updates; core maps it into
  `SessionSettingsUpdate.final_output_json_schema` so it applies to the
  created turn context.
  - V2 `turn/start` does NOT persist the schema via `OverrideTurnContext`
  (it’s applied only for the current turn). Other overrides
  (cwd/model/etc) keep their existing persistent behavior.
  
  API / docs
  - `codex-rs/app-server-protocol/src/protocol/v1.rs`: add `output_schema:
  Option<serde_json::Value>` to `SendUserTurnParams` (serialized as
  `outputSchema`).
  - `codex-rs/app-server-protocol/src/protocol/v2.rs`: add `output_schema:
  Option<JsonValue>` to `TurnStartParams` (serialized as `outputSchema`).
  - `codex-rs/app-server/README.md`: document `outputSchema` for
  `turn/start` and clarify it applies only to the current turn.
  - `codex-rs/docs/codex_mcp_interface.md`: document `outputSchema` for v1
  `sendUserTurn` and v2 `turn/start`.
  
  Tests added/updated
  - New app-server integration tests asserting `outputSchema` is forwarded
  into outbound `/responses` requests as `text.format`:
    - `codex-rs/app-server/tests/suite/output_schema.rs`
    - `codex-rs/app-server/tests/suite/v2/output_schema.rs`
  - Added per-turn semantics tests (schema does not leak to the next
  turn):
    - `send_user_turn_output_schema_is_per_turn_v1`
    - `turn_start_output_schema_is_per_turn_v2`
  - Added protocol wire-compat tests for the merged op:
    - serialize omits `final_output_json_schema` when `None`
    - deserialize works when field is missing
    - serialize includes `final_output_json_schema` when `Some(schema)`
  
  Call site updates (high level)
  - Updated all `Op::UserInput { .. }` constructions to include
  `final_output_json_schema`:
    - `codex-rs/app-server/src/codex_message_processor.rs`
    - `codex-rs/core/src/codex_delegate.rs`
    - `codex-rs/mcp-server/src/codex_tool_runner.rs`
    - `codex-rs/tui/src/chatwidget.rs`
    - `codex-rs/tui2/src/chatwidget.rs`
    - plus impacted core tests.
  
  Validation
  - `just fmt`
  - `cargo test -p codex-core`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-mcp-server`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-tui2`
  - `cargo test -p codex-protocol`
  - `cargo clippy --all-features --tests --profile dev --fix -- -D
  warnings`

  Anton Panasenko · 2026-01-05 10:27:00 -08:00
  807f8a43c2
• feat: support allowed_sandbox_modes in requirements.toml (#8298)

  This adds support for `allowed_sandbox_modes` in `requirements.toml` and
  provides legacy support for constraining sandbox modes in
  `managed_config.toml`. This is converted to `Constrained<SandboxPolicy>`
  in `ConfigRequirements` and applied to `Config` such that constraints
  are enforced throughout the harness.
  
  Note that, because `managed_config.toml` is deprecated, we do not add
  support for the new `external-sandbox` variant recently introduced in
  https://github.com/openai/codex/pull/8290. As noted, that variant is not
  supported in `config.toml` today, but can be configured programmatically
  via app server.

  Michael Bolin · 2025-12-19 21:09:20 +00:00
  dc61fc5f50
• Support SYSTEM skills. (#8220)

  1. Remove PUBLIC skills and introduce SYSTEM skills embedded in the
  binary and installed into $CODEX_HOME/skills/.system at startup.
  2. Skills are now always enabled (feature flag removed).
  3. Update skills/list to accept forceReload and plumb it through (not
  used by clients yet).

  xl-openai · 2025-12-17 18:48:28 -08:00
  da3869eeb6
• Load models from static file (#8153)

  - Load models from static file as a fallback
  - Make API users use this file directly
  - Add tests to make sure updates to the file always serialize

  Ahmed Ibrahim · 2025-12-17 14:34:13 -08:00
  927a6acbea
• feat: Constrain values for approval_policy (#7778)

  Constrain `approval_policy` through new `admin_policy` config.
  
  This PR will:
  1. Add a `admin_policy` section to config, with a single field (for now)
  `allowed_approval_policies`. This list constrains the set of
  user-settable `approval_policy`s.
  2. Introduce a new `Constrained<T>` type, which combines a current value
  and a validator function. The validator function ensures disallowed
  values are not set.
  3. Change the type of `approval_policy` on `Config` and
  `SessionConfiguration` from `AskForApproval` to
  `Constrained<AskForApproval>`. The validator function is set by the
  values passed into `allowed_approval_policies`.
  4. `GenericDisplayRow`: add a `disabled_reason: Option<String>`. When
  set, it disables selection of the value and indicates as such in the
  menu. This also makes it unselectable with arrow keys or numbers. This
  is used in the `/approvals` menu.
  
  Follow ups are:
  1. Do the same thing to `sandbox_policy`.
  2. Propagate the allowed set of values through app-server for the
  extension (though already this should prevent app-server from setting
  this values, it's just that we want to disable UI elements that are
  unsettable).
  
  Happy to split this PR up if you prefer, into the logical numbered areas
  above. Especially if there are parts we want to gavel on separately
  (e.g. admin_policy).
  
  Disabled full access:
  <img width="1680" height="380" alt="image"
  src="https://github.com/user-attachments/assets/1fb61c8c-1fcb-4dc4-8355-2293edb52ba0"
  />
  
  Disabled `--yolo` on startup:
  <img width="749" height="76" alt="image"
  src="https://github.com/user-attachments/assets/0a1211a0-6eb1-40d6-a1d7-439c41e94ddb"
  />
  
  CODEX-4087

  gt-oai · 2025-12-17 16:19:27 +00:00
  9352c6b235
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

  Changes the `writable_roots` field of the `WorkspaceWrite` variant of
  the `SandboxPolicy` enum from `Vec<PathBuf>` to `Vec<AbsolutePathBuf>`.
  This is helpful because now callers can be sure the value is an absolute
  path rather than a relative one. (Though when using an absolute path in
  a Seatbelt config policy, we still have to _canonicalize_ it first.)
  
  Because `writable_roots` can be read from a config file, it is important
  that we are able to resolve relative paths properly using the parent
  folder of the config file as the base path.

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• make model optional in config (#7769)

  - Make Config.model optional and centralize default-selection logic in
  ModelsManager, including a default_model helper (with
  codex-auto-balanced when available) so sessions now carry an explicit
  chosen model separate from the base config.
  - Resolve `model` once in `core` and `tui` from config. Then store the
  state of it on other structs.
  - Move refreshing models to be before resolving the default model

  Ahmed Ibrahim · 2025-12-10 11:19:00 -08:00
  cb9a189857
• Wire with_remote_overrides to construct model families (#7621)

  - This PR wires `with_remote_overrides` and make the
  `construct_model_families` an async function
  - Moves getting model family a level above to keep the function `sync`
  - Updates the tests to local, offline, and `sync` helper for model
  families

  Ahmed Ibrahim · 2025-12-05 10:40:15 -08:00
  d08efb1743
• remove model_family from `config (#7571)

  - Remove `model_family` from `config`
  - Make sure to still override config elements related to `model_family`
  like supporting reasoning

  Ahmed Ibrahim · 2025-12-04 11:57:58 -08:00
  9b2055586d
• Migrate model family to models manager (#7565)

  This PR moves `ModelsFamily` to `openai_models`. It also propagates
  `ModelsManager` to session services and use it to drive model family. We
  also make `derive_default_model_family` private because it's a step
  towards what we want: one place that gives model configuration.
  
  This is a second step at having one source of truth for models
  information and config: `ModelsManager`.
  
  Next steps would be to remove `ModelsFamily` from config. That's massive
  because it's being used in 41 occasions mostly pre launching `codex`.
  Also, we need to make `find_family_for_model` private. It's also big
  because it's being used in 21 occasions ~ all tests.

  Ahmed Ibrahim · 2025-12-03 18:49:47 -08:00
  cee37a32b2