299 Commits

• fix: codex-arg0 no longer depends on codex-core (#12434)

  ## Why
  
  `codex-rs/arg0` only needed two things from `codex-core`:
  
  - the `find_codex_home()` wrapper
  - the special argv flag used for the internal `apply_patch`
  self-invocation path
  
  That made `codex-arg0` depend on `codex-core` for a very small surface
  area. This change removes that dependency edge and moves the shared
  `apply_patch` invocation flag to a more natural boundary
  (`codex-apply-patch`) while keeping the contract explicitly documented.
  
  ## What Changed
  
  - Moved the internal `apply_patch` argv[1] flag constant out of
  `codex-core` and into `codex-apply-patch`.
  - Renamed the constant to `CODEX_CORE_APPLY_PATCH_ARG1` and documented
  that it is part of the Codex core process-invocation contract (even
  though it now lives in `codex-apply-patch`).
  - Updated `arg0`, the core apply-patch runtime, and the `codex-exec`
  apply-patch test to import the constant from `codex-apply-patch`.
  - Updated `codex-rs/arg0` to call
  `codex_utils_home_dir::find_codex_home()` directly instead of
  `codex_core::config::find_codex_home()`.
  - Removed the `codex-core` dependency from `codex-rs/arg0` and added the
  needed direct dependency on `codex-utils-home-dir`.
  - Added `codex-apply-patch` as a dev-dependency for `codex-rs/exec`
  tests (the apply-patch test now imports the moved constant directly).
  
  ## Verification
  
  - `cargo test -p codex-apply-patch`
  - `cargo test -p codex-arg0`
  - `cargo test -p codex-core --lib apply_patch`
  - `cargo test -p codex-exec
  test_standalone_exec_cli_can_use_apply_patch`
  - `cargo shear`

  Michael Bolin · 2026-02-21 00:20:42 -08:00
  2fe4be1aa9
• 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
• Wire realtime api to core (#12268)

  - Introduce `RealtimeConversationManager` for realtime API management 
  - Add `op::conversation` to start conversation, insert audio, insert
  text, and close conversation.
  - emit conversation lifecycle and realtime events.
  - Move shared realtime payload types into codex-protocol and add core
  e2e websocket tests for start/replace/transport-close paths.
  
  Things to consider:
  - Should we use the same `op::` and `Events` channel to carry audio? I
  think we should try this simple approach and later we can create
  separate one if the channels got congested.
  - Sending text updates to the client: we can start simple and later
  restrict that.
  - Provider auth isn't wired for now intentionally

  Ahmed Ibrahim · 2026-02-20 19:06:35 -08:00
  6817f0be8a
• feat: cleaner TUI for sub-agents (#12327)

  <img width="760" height="496" alt="Screenshot 2026-02-20 at 14 31 25"
  src="https://github.com/user-attachments/assets/1983b825-bb47-417e-9925-6f727af56765"
  />

  jif-oai · 2026-02-20 15:26:33 +00:00
  4d60c803ba
• client side modelinfo overrides (#12101)

  TL;DR
  Add top-level `model_catalog_json` config support so users can supply a
  local model catalog override from a JSON file path (including adding new
  models) without backend changes.
  
  ### Problem
  Codex previously had no clean client-side way to replace/overlay model
  catalog data for local testing of model metadata and new model entries.
  
  ### Fix
  - Add top-level `model_catalog_json` config field (JSON file path).
  - Apply catalog entries when resolving `ModelInfo`:
    1. Base resolved model metadata (remote/fallback)
    2. Catalog overlay from `model_catalog_json`
  3. Existing global top-level overrides (`model_context_window`,
  `model_supports_reasoning_summaries`, etc.)
  
  ### Note
  Will revisit per-field overrides in a follow-up
  
  ### Tests
  Added tests

  sayan-oai · 2026-02-19 10:38:57 -08:00
  d54999d006
• Restore phase when loading from history (#12244)
  Jack Mousseau · 2026-02-19 09:56:56 -08:00
  3a951f8096
• [js_repl] paths for node module resolution can be specified for js_repl (#11944)

  # External (non-OpenAI) Pull Request Requirements
  
  In `js_repl` mode, module resolution currently starts from
  `js_repl_kernel.js`, which is written to a per-kernel temp dir. This
  effectively means that bare imports will not resolve.
  
  This PR adds a new config option, `js_repl_node_module_dirs`, which is a
  list of dirs that are used (in order) to resolve a bare import. If none
  of those work, the current working directory of the thread is used.
  
  For example:
  ```toml
  js_repl_node_module_dirs = [
      "/path/to/node_modules/",
      "/other/path/to/node_modules/",
  ]
  ```

  aaronl-openai · 2026-02-17 23:29:49 -08:00
  f600453699
• feat(core): zsh exec bridge (#12052)

  zsh fork PR stack:
  - https://github.com/openai/codex/pull/12051 
  - https://github.com/openai/codex/pull/12052 👈 
  
  ### Summary
  This PR introduces a feature-gated native shell runtime path that routes
  shell execution through a patched zsh exec bridge, removing MCP-specific
  behavior from the shell hot path while preserving existing
  CommandExecution lifecycle semantics.
  
  When shell_zsh_fork is enabled, shell commands run via patched zsh with
  per-`execve` interception through EXEC_WRAPPER. Core receives wrapper
  IPC requests over a Unix socket, applies existing approval policy, and
  returns allow/deny before the subcommand executes.
  
  ### What’s included
  **1) New zsh exec bridge runtime in core**
  - Wrapper-mode entrypoint (maybe_run_zsh_exec_wrapper_mode) for
  EXEC_WRAPPER invocations.
  - Per-execution Unix-socket IPC handling for wrapper requests/responses.
  - Approval callback integration using existing core approval
  orchestration.
  - Streaming stdout/stderr deltas to existing command output event
  pipeline.
  - Error handling for malformed IPC, denial/abort, and execution
  failures.
  
  **2) Session lifecycle integration**
  SessionServices now owns a `ZshExecBridge`.
  Session startup initializes bridge state; shutdown tears it down
  cleanly.
  
  **3) Shell runtime routing (feature-gated)**
  When `shell_zsh_fork` is enabled:
  - Build execution env/spec as usual.
  - Add wrapper socket env wiring.
  - Execute via `zsh_exec_bridge.execute_shell_request(...)` instead of
  the regular shell path.
  - Non-zsh-fork behavior remains unchanged.
  
  **4) Config + feature wiring**
  - Added `Feature::ShellZshFork` (under development).
  - Added config support for `zsh_path` (optional absolute path to patched
  zsh):
  - `Config`, `ConfigToml`, `ConfigProfile`, overrides, and schema.
  - Session startup validates that `zsh_path` exists/usable when zsh-fork
  is enabled.
  - Added startup test for missing `zsh_path` failure mode.
  
  **5) Seatbelt/sandbox updates for wrapper IPC**
  - Extended seatbelt policy generation to optionally allow outbound
  connection to explicitly permitted Unix sockets.
  - Wired sandboxing path to pass wrapper socket path through to seatbelt
  policy generation.
  - Added/updated seatbelt tests for explicit socket allow rule and
  argument emission.
  
  **6) Runtime entrypoint hooks**
  - This allows the same binary to act as the zsh wrapper subprocess when
  invoked via `EXEC_WRAPPER`.
  
  **7) Tool selection behavior**
  - ToolsConfig now prefers ShellCommand type when shell_zsh_fork is
  enabled.
  - Added test coverage for precedence with unified-exec enabled.

  Owen Lin · 2026-02-17 20:19:53 -08:00
  edacbf7b6e
• 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: add model reroute notification (#12001)

  ### Summary
  Builiding off
  https://github.com/openai/codex/pull/11964/files/5c75aa7b89a70bc2cc410a6fd238749306ec4c5e#diff-058ae8f109a8b84b4b79bbfa45f522c2233b9d9e139696044ae374d50b6196e0,
  we have created a `model/rerouted` notification that captures the event
  so that consumers can render as expected. Keep the `EventMsg::Warning`
  path in core so that this does not affect TUI rendering.
  
  `model/rerouted` is meant to be generic to account for future usage
  including capacity planning etc.

  Shijie Rao · 2026-02-17 11:02:23 -08:00
  48018e9eac
• Report syntax errors in rules file (#11686)

  Currently, if there are syntax errors detected in the starlark rules
  file, the entire policy is silently ignored by the CLI. The app server
  correctly emits a message that can be displayed in a GUI.
  
  This PR changes the CLI (both the TUI and non-interactive exec) to fail
  when the rules file can't be parsed. It then prints out an error message
  and exits with a non-zero exit code. This is consistent with the
  handling of errors in the config file.
  
  This addresses #11603

  Eric Traut · 2026-02-13 10:33:40 -08:00
  b98c810328
• 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(app-server): experimental flag to persist extended history (#11227)

  This PR adds an experimental `persist_extended_history` bool flag to
  app-server thread APIs so rollout logs can retain a richer set of
  EventMsgs for non-lossy Thread > Turn > ThreadItems reconstruction (i.e.
  on `thread/resume`).
  
  ### Motivation
  Today, our rollout recorder only persists a small subset (e.g. user
  message, reasoning, assistant message) of `EventMsg` types, dropping a
  good number (like command exec, file change, etc.) that are important
  for reconstructing full item history for `thread/resume`, `thread/read`,
  and `thread/fork`.
  
  Some clients want to be able to resume a thread without lossiness. This
  lossiness is primarily a UI thing, since what the model sees are
  `ResponseItem` and not `EventMsg`.
  
  ### Approach
  This change introduces an opt-in `persist_full_history` flag to preserve
  those events when you start/resume/fork a thread (defaults to `false`).
  
  This is done by adding an `EventPersistenceMode` to the rollout
  recorder:
  - `Limited` (existing behavior, default)
  - `Extended` (new opt-in behavior)
  
  In `Extended` mode, persist additional `EventMsg` variants needed for
  non-lossy app-server `ThreadItem` reconstruction. We now store the
  following ThreadItems that we didn't before:
  - web search
  - command execution
  - patch/file changes
  - MCP tool calls
  - image view calls
  - collab tool outcomes
  - context compaction
  - review mode enter/exit
  
  For **command executions** in particular, we truncate the output using
  the existing `truncate_text` from core to store an upper bound of 10,000
  bytes, which is also the default value for truncating tool outputs shown
  to the model. This keeps the size of the rollout file and command
  execution items returned over the wire reasonable.
  
  And we also persist `EventMsg::Error` which we can now map back to the
  Turn's status and populates the Turn's error metadata.
  
  #### Updates to EventMsgs
  To truly make `thread/resume` non-lossy, we also needed to persist the
  `status` on `EventMsg::CommandExecutionEndEvent` and
  `EventMsg::PatchApplyEndEvent`. Previously it was not obvious whether a
  command failed or was declined (similar for apply_patch). These
  EventMsgs were never persisted before so I made it a required field.

  Owen Lin · 2026-02-12 19:34:22 +00:00
  efc8d45750
• 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
• Add feature-gated freeform js_repl core runtime (#10674)

  ## Summary
  
  This PR adds an **experimental, feature-gated `js_repl` core runtime**
  so models can execute JavaScript in a persistent REPL context across
  tool calls.
  
  The implementation integrates with existing feature gating, tool
  registration, prompt composition, config/schema docs, and tests.
  
  ## What changed
  
  - Added new experimental feature flag: `features.js_repl`.
  - Added freeform `js_repl` tool and companion `js_repl_reset` tool.
  - Gated tool availability behind `Feature::JsRepl`.
  - Added conditional prompt-section injection for JS REPL instructions
  via marker-based prompt processing.
  - Implemented JS REPL handlers, including freeform parsing and pragma
  support (timeout/reset controls).
  - Added runtime resolution order for Node:
    1. `CODEX_JS_REPL_NODE_PATH`
    2. `js_repl_node_path` in config
    3. `PATH`
  - Added JS runtime assets/version files and updated docs/schema.
  
  ## Why
  
  This enables richer agent workflows that require incremental JavaScript
  execution with preserved state, while keeping rollout safe behind an
  explicit feature flag.
  
  ## Testing
  
  Coverage includes:
  
  - Feature-flag gating behavior for tool exposure.
  - Freeform parser/pragma handling edge cases.
  - Runtime behavior (state persistence across calls and top-level `await`
  support).
  
  ## Usage
  
  ```toml
  [features]
  js_repl = true
  ```
  
  Optional runtime override:
  
  - `CODEX_JS_REPL_NODE_PATH`, or
  - `js_repl_node_path` in config.
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/10674
  - ⏳ `2` https://github.com/openai/codex/pull/10672
  - ⏳ `3` https://github.com/openai/codex/pull/10671
  - ⏳ `4` https://github.com/openai/codex/pull/10673
  - ⏳ `5` https://github.com/openai/codex/pull/10670

  Curtis 'Fjord' Hawthorne · 2026-02-11 12:05:02 -08:00
  42e22f3bde
• Cache cloud requirements (#11305)

  We're loading these from the web on every startup. This puts them in a
  local file with a 1hr TTL.
  
  We sign the downloaded requirements with a key compiled into the Codex
  CLI to prevent unsophisticated tampering (determined circumvention is
  outside of our threat model: after all, one could just compile Codex
  without any of these checks).
  
  If any of the following are true, we ignore the local cache and re-fetch
  from Cloud:
  * The signature is invalid for the payload (== requirements, sign time,
  ttl, user identity)
  * The identity does not match the auth'd user's identity
  * The TTL has expired
  * We cannot parse requirements.toml from the payload

  gt-oai · 2026-02-11 14:06:41 +00:00
  886d9377d3
• feat: split codex-common into smaller utils crates (#11422)

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

  Michael Bolin · 2026-02-11 12:59:24 +00:00
  8b7f8af343
• chore: persist turn_id in rollout session and make turn_id uuid based (#11246)

  Problem:
  1. turn id is constructed in-memory;
  2. on resuming threads, turn_id might not be unique;
  3. client cannot no the boundary of a turn from rollout files easily.
  
  This PR does three things:
  1. persist `task_started` and `task_complete` events;
  1. persist `turn_id` in rollout turn events;
  5. generate turn_id as unique uuids instead of incrementing it in
  memory.
  
  This helps us resolve the issue of clients wanting to have unique turn
  ids for resuming a thread, and knowing the boundry of each turn in
  rollout files.
  
  example debug logs
  ```
  2026-02-11T00:32:10.746876Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=8 turn=Turn { id: "019c4a07-d809-74c3-bc4b-fd9618487b4b", items: [UserMessage { id: "item-24", content: [Text { text: "hi", text_elements: [] }] }, AgentMessage { id: "item-25", text: "Hi. I’m in the workspace with your current changes loaded and ready. Send the next task and I’ll execute it end-to-end." }], status: Completed, error: None }
  2026-02-11T00:32:10.746888Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=9 turn=Turn { id: "019c4a18-1004-76c0-a0fb-a77610f6a9b8", items: [UserMessage { id: "item-26", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-27", text: "Hello. Ready for the next change in `codex-rs`; I can continue from the current in-progress diff or start a new task." }], status: Completed, error: None }
  2026-02-11T00:32:10.746899Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=10 turn=Turn { id: "019c4a19-41f0-7db0-ad78-74f1503baeb8", items: [UserMessage { id: "item-28", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-29", text: "Hello. Send the specific change you want in `codex-rs`, and I’ll implement it and run the required checks." }], status: Completed, error: None }
  ```
  
  backward compatibility:
  if you try to resume an old session without task_started and
  task_complete event populated, the following happens:
  - If you resume and do nothing: those reconstructed historical IDs can
  differ next time you resume.
  - If you resume and send a new turn: the new turn gets a fresh UUID from
  live submission flow and is persisted, so that new turn’s ID is stable
  on later resumes.
  I think this behavior is fine, because we only care about deterministic
  turn id once a turn is triggered.

  Celia Chen · 2026-02-11 03:56:01 +00:00
  641d5268fa
• fix: reduce usage of open_if_present (#11344)
  jif-oai · 2026-02-10 19:25:07 +00:00
  847a6092e6
• feat: retain NetworkProxy, when appropriate (#11207)

  As of this PR, `SessionServices` retains a
  `Option<StartedNetworkProxy>`, if appropriate.
  
  Now the `network` field on `Config` is `Option<NetworkProxySpec>`
  instead of `Option<NetworkProxy>`.
  
  Over in `Session::new()`, we invoke `NetworkProxySpec::start_proxy()` to
  create the `StartedNetworkProxy`, which is a new struct that retains the
  `NetworkProxy` as well as the `NetworkProxyHandle`. (Note that `Drop` is
  implemented for `NetworkProxyHandle` to ensure the proxies are shutdown
  when it is dropped.)
  
  The `NetworkProxy` from the `StartedNetworkProxy` is threaded through to
  the appropriate places.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/11207).
  * #11285
  * __->__ #11207

  Michael Bolin · 2026-02-10 02:09:23 -08:00
  44ebf4588f
• feat(sandbox): enforce proxy-aware network routing in sandbox (#11113)

  ## Summary
  - expand proxy env injection to cover common tool env vars
  (`HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY`/`NO_PROXY` families +
  tool-specific variants)
  - harden macOS Seatbelt network policy generation to route through
  inferred loopback proxy endpoints and fail closed when proxy env is
  malformed
  - thread proxy-aware Linux sandbox flags and add minimal bwrap netns
  isolation hook for restricted non-proxy runs
  - add/refresh tests for proxy env wiring, Seatbelt policy generation,
  and Linux sandbox argument wiring

  viyatb-oai · 2026-02-10 07:44:21 +00:00
  3391e5ea86
• 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
• 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
• 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
• feat: wire ephemeral in codex exec (#10758)
  jif-oai · 2026-02-05 15:49:57 +00:00
  d337b51741
• fix: flaky landlock (#10689)

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

  jif-oai · 2026-02-05 10:30:18 +00:00
  c67120f4a0
• 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
• Handle exec shutdown on Interrupt (fixes immortal codex exec with websockets) (#10519)

  ### Motivation
  - Ensure `codex exec` exits when a running turn is interrupted (e.g.,
  Ctrl-C) so the CLI is not "immortal" when websockets/streaming are used.
  
  ### Description
  - Return `CodexStatus::InitiateShutdown` when handling
  `EventMsg::TurnAborted` in
  `exec/src/event_processor_with_human_output.rs` so human-output exec
  mode shuts down after an interrupt.
  - Treat `protocol::EventMsg::TurnAborted` as
  `CodexStatus::InitiateShutdown` in
  `exec/src/event_processor_with_jsonl_output.rs` so JSONL output mode
  behaves the same.
  - Applied formatting with `just fmt`.
  
  ### Testing
  - Ran `just fmt` successfully.
  - Ran `cargo test -p codex-exec`; many unit tests ran and the test
  command completed, but the full test run in this environment produced
  `35 passed, 11 failed` where the failures are due to Landlock sandbox
  panics and 403 responses in the test harness (environmental/integration
  issues) and are not caused by the interrupt/shutdown changes.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_698165cec4e083258d17702bd29014c1)

  Rasmus Rygaard · 2026-02-03 14:38:21 -08:00
  e3d39013d3
• 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
• 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
• chore: nuke chat/completions API (#10157)
  jif-oai · 2026-02-03 11:31:57 +00:00
  d2394a2494
• 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
• 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
• add missing fields to WebSearchAction and update app-server types (#10276)

  - add `WebSearchAction` to app-server v2 types
  - add `queries` to `WebSearchAction::Search` type
  
  Updated tests.

  sayan-oai · 2026-01-30 16:37:56 -08:00
  eb86663dcb
• Add enforce_residency to requirements (#10263)

  Add `enforce_residency` to requirements.toml and thread it through to a
  header on `default_client`.

  gt-oai · 2026-01-31 00:26:25 +00:00
  149f3aa27a
• Wire up cloud reqs in exec, app-server (#10241)

  We're fetching cloud requirements in TUI in
  https://github.com/openai/codex/pull/10167.
  
  This adds the same fetching in exec and app-server binaries also.

  gt-oai · 2026-01-30 23:53:41 +00:00
  a046481ad9
• Plan mode: stream proposed plans, emit plan items, and render in TUI (#9786)

  ## Summary
  - Stream proposed plans in Plan Mode using `<proposed_plan>` tags parsed
  in core, emitting plan deltas plus a plan `ThreadItem`, while stripping
  tags from normal assistant output.
  - Persist plan items and rebuild them on resume so proposed plans show
  in thread history.
  - Wire plan items/deltas through app-server protocol v2 and render a
  dedicated proposed-plan view in the TUI, including the “Implement this
  plan?” prompt only when a plan item is present.
  
  ## Changes
  
  ### Core (`codex-rs/core`)
  - Added a generic, line-based tag parser that buffers each line until it
  can disprove a tag prefix; implements auto-close on `finish()` for
  unterminated tags. `codex-rs/core/src/tagged_block_parser.rs`
  - Refactored proposed plan parsing to wrap the generic parser.
  `codex-rs/core/src/proposed_plan_parser.rs`
  - In plan mode, stream assistant deltas as:
    - **Normal text** → `AgentMessageContentDelta`
    - **Plan text** → `PlanDelta` + `TurnItem::Plan` start/completion  
    (`codex-rs/core/src/codex.rs`)
  - Final plan item content is derived from the completed assistant
  message (authoritative), not necessarily the concatenated deltas.
  - Strips `<proposed_plan>` blocks from assistant text in plan mode so
  tags don’t appear in normal messages.
  (`codex-rs/core/src/stream_events_utils.rs`)
  - Persist `ItemCompleted` events only for plan items for rollout replay.
  (`codex-rs/core/src/rollout/policy.rs`)
  - Guard `update_plan` tool in Plan Mode with a clear error message.
  (`codex-rs/core/src/tools/handlers/plan.rs`)
  - Updated Plan Mode prompt to:  
    - keep `<proposed_plan>` out of non-final reasoning/preambles  
    - require exact tag formatting  
    - allow only one `<proposed_plan>` block per turn  
    (`codex-rs/core/templates/collaboration_mode/plan.md`)
  
  ### Protocol / App-server protocol
  - Added `TurnItem::Plan` and `PlanDeltaEvent` to core protocol items.
  (`codex-rs/protocol/src/items.rs`, `codex-rs/protocol/src/protocol.rs`)
  - Added v2 `ThreadItem::Plan` and `PlanDeltaNotification` with
  EXPERIMENTAL markers and note that deltas may not match the final plan
  item. (`codex-rs/app-server-protocol/src/protocol/v2.rs`)
  - Added plan delta route in app-server protocol common mapping.
  (`codex-rs/app-server-protocol/src/protocol/common.rs`)
  - Rebuild plan items from persisted `ItemCompleted` events on resume.
  (`codex-rs/app-server-protocol/src/protocol/thread_history.rs`)
  
  ### App-server
  - Forward plan deltas to v2 clients and map core plan items to v2 plan
  items. (`codex-rs/app-server/src/bespoke_event_handling.rs`,
  `codex-rs/app-server/src/codex_message_processor.rs`)
  - Added v2 plan item tests.
  (`codex-rs/app-server/tests/suite/v2/plan_item.rs`)
  
  ### TUI
  - Added a dedicated proposed plan history cell with special background
  and padding, and moved “• Proposed Plan” outside the highlighted block.
  (`codex-rs/tui/src/history_cell.rs`, `codex-rs/tui/src/style.rs`)
  - Only show “Implement this plan?” when a plan item exists.
  (`codex-rs/tui/src/chatwidget.rs`,
  `codex-rs/tui/src/chatwidget/tests.rs`)
  
  <img width="831" height="847" alt="Screenshot 2026-01-29 at 7 06 24 PM"
  src="https://github.com/user-attachments/assets/69794c8c-f96b-4d36-92ef-c1f5c3a8f286"
  />
  
  ### Docs / Misc
  - Updated protocol docs to mention plan deltas.
  (`codex-rs/docs/protocol_v1.md`)
  - Minor plumbing updates in exec/debug clients to tolerate plan deltas.
  (`codex-rs/debug-client/src/reader.rs`, `codex-rs/exec/...`)
  
  ## Tests
  - Added core integration tests:
    - Plan mode strips plan from agent messages.
    - Missing `</proposed_plan>` closes at end-of-message.  
    (`codex-rs/core/tests/suite/items.rs`)
  - Added unit tests for generic tag parser (prefix buffering, non-tag
  lines, auto-close). (`codex-rs/core/src/tagged_block_parser.rs`)
  - Existing app-server plan item tests in v2.
  (`codex-rs/app-server/tests/suite/v2/plan_item.rs`)
  
  ## Notes / Behavior
  - Plan output no longer appears in standard assistant text in Plan Mode;
  it streams via `PlanDelta` and completes as a `TurnItem::Plan`.
  - The final plan item content is authoritative and may diverge from
  streamed deltas (documented as experimental).
  - Reasoning summaries are not filtered; prompt instructs the model not
  to include `<proposed_plan>` outside the final plan message.
  
  ## Codex Author
  `codex fork 019bec2d-b09d-7450-b292-d7bcdddcdbfb`

  Charley Cunningham · 2026-01-30 18:59:30 +00:00
  ec4a2d07e4
• Conversation naming (#8991)

  Session renaming:
  - `/rename my_session`
  - `/rename` without arg and passing an argument in `customViewPrompt`
  - AppExitInfo shows resume hint using the session name if set instead of
  uuid, defaults to uuid if not set
  - Names are stored in `CODEX_HOME/sessions.jsonl`
  
  Session resuming:
  - codex resume <name> lookup for `CODEX_HOME/sessions.jsonl` first entry
  matching the name and resumes the session
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  pap-openai · 2026-01-30 10:40:09 +00:00
  1ef5455eb6
• [bazel] Improve runfiles handling (#10098)

  we can't use runfiles directory on Windows due to path lengths, so swap
  to manifest strategy. Parsing the manifest is a bit complex and the
  format is changing in Bazel upstream, so pull in the official Rust
  library (via a small hack to make it importable...) and cleanup all the
  associated logic to work cleanly in both bazel and cargo without extra
  confusion

  zbarsky-openai · 2026-01-29 00:15:44 +00:00
  8497163363
• feat: codex exec auto-subscribe to new threads (#9821)
  jif-oai · 2026-01-28 14:03:20 +01:00
  dabafe204a
• Fix resume --last with --json option (#9475)

  Fix resume --last prompt parsing by dropping the clap conflict on the
  codex resume subcommand so a positional prompt is accepted when --last
  is set. This aligns interactive resume behavior with exec-mode logic and
  avoids the “--last cannot be used with SESSION_ID” error.
  
  This addresses #6717

  Eric Traut · 2026-01-26 20:20:57 -08:00
  7c96f2e84c
• fix: handle all web_search actions and in progress invocations (#9960)

  ### Summary
  - Parse all `web_search` tool actions (`search`, `find_in_page`,
  `open_page`).
  - Previously we only parsed + displayed `search`, which made the TUI
  appear to pause when the other actions were being used.
  - Show in progress `web_search` calls as `Searching the web`
    - Previously we only showed completed tool calls
  
  <img width="308" height="149" alt="image"
  src="https://github.com/user-attachments/assets/90a4e8ff-b06a-48ff-a282-b57b31121845"
  />
  
  ### Tests
  Added + updated tests, tested locally
  
  ### Follow ups
  Update VSCode extension to display these as well

  sayan-oai · 2026-01-27 03:33:48 +00:00
  86adf53235
• feat: codex exec mapping of collab tools (#9817)

  THIS IS NOT THE FINAL UX

  jif-oai · 2026-01-26 18:01:35 +00:00
  01d7f8095b
• Fix flakey resume test (#9789)

  Sessions' `updated_at` times are truncated to seconds, with the UUID
  session ID used to break ties. If the two test sessions are created in
  the same second, AND the session B UUID < session A UUID, the test
  fails.
  
  Fix this by mutating the session mtimes, from which we derive the
  updated_at time, to ensure session B is updated_at later than session A.

  gt-oai · 2026-01-26 14:44:37 +00:00
  65c7119fb7
• feat: dynamic tools injection (#9539)

  ## Summary
  Add dynamic tool injection to thread startup in API v2, wire dynamic
  tool calls through the app server to clients, and plumb responses back
  into the model tool pipeline.
  
  ### Flow (high level)
  - Thread start injects `dynamic_tools` into the model tool list for that
  thread (validation is done here).
  - When the model emits a tool call for one of those names, core raises a
  `DynamicToolCallRequest` event.
  - The app server forwards it to the client as `item/tool/call`, waits
  for the client’s response, then submits a `DynamicToolResponse` back to
  core.
  - Core turns that into a `function_call_output` in the next model
  request so the model can continue.
  
  ### What changed
  - Added dynamic tool specs to v2 thread start params and protocol types;
  introduced `item/tool/call` (request/response) for dynamic tool
  execution.
  - Core now registers dynamic tool specs at request time and routes those
  calls via a new dynamic tool handler.
  - App server validates tool names/schemas, forwards dynamic tool call
  requests to clients, and publishes tool outputs back into the session.
  - Integration tests

  jif-oai · 2026-01-26 10:06:44 +00:00
  d594693d1a
• feat: ephemeral threads (#9765)

  Add ephemeral threads capabilities. Only exposed through the
  `app-server` v2
  
  The idea is to disable the rollout recorder for those threads.

  jif-oai · 2026-01-24 14:57:40 +00:00
  83775f4df1
• Another round of improvements for config error messages (#9746)

  In a [recent PR](https://github.com/openai/codex/pull/9182), I made some
  improvements to config error messages so errors didn't leave app server
  clients in a dead state. This is a follow-on PR to make these error
  messages more readable and actionable for both TUI and GUI users. For
  example, see #9668 where the user was understandably confused about the
  source of the problem and how to fix it.
  
  The improved error message:
  1. Clearly identifies the config file where the error was found (which
  is more important now that we support layered configs)
  2. Provides a line and column number of the error
  3. Displays the line where the error occurred and underlines it
  
  For example, if my `config.toml` includes the following:
  ```toml
  [features]
  collaboration_modes = "true"
  ```
  
  Here's the current CLI error message:
  ```
  Error loading config.toml: invalid type: string "true", expected a boolean in `features`
  ```
  
  And here's the improved message:
  ```
  Error loading config.toml:
  /Users/etraut/.codex/config.toml:43:23: invalid type: string "true", expected a boolean
     |
  43 | collaboration_modes = "true"
     |                       ^^^^^^
  ```
  
  The bulk of the new logic is contained within a new module
  `config_loader/diagnostics.rs` that is responsible for calculating the
  text range for a given toml path (which is more involved than I would
  have expected).
  
  In addition, this PR adds the file name and text range to the
  `ConfigWarningNotification` app server struct. This allows GUI clients
  to present the user with a better error message and an optional link to
  open the errant config file. This was a suggestion from @.bolinfest when
  he reviewed my previous PR.

  Eric Traut · 2026-01-23 20:11:09 -08:00
  713ae22c04
• fix(exec): skip git repo check when --yolo flag is used (#9590)

  ## Summary
  
  Fixes #7522
  
  The `--yolo` (`--dangerously-bypass-approvals-and-sandbox`) flag is
  documented to skip all confirmation prompts and execute commands without
  sandboxing, intended solely for running in environments that are
  externally sandboxed. However, it was not bypassing the trusted
  directory (git repo) check, requiring users to also specify
  `--skip-git-repo-check`.
  
  This change makes `--yolo` also skip the git repo check, matching the
  documented behavior and user expectations.
  
  ## Changes
  
  - Modified `codex-rs/exec/src/lib.rs` to check for
  `dangerously_bypass_approvals_and_sandbox` flag in addition to
  `skip_git_repo_check` when determining whether to skip the git repo
  check
  
  ## Testing
  
  - Verified the code compiles with `cargo check -p codex-exec`
  - Ran existing tests with `cargo test -p codex-exec` (34 passed, 8
  integration tests failed due to unrelated API connectivity issues)
  
  ---
  🤖 Generated with [Claude Code](https://claude.ai/code)
  
  Co-authored-by: Claude <noreply@anthropic.com>

  zerone0x · 2026-01-23 12:05:20 -08:00
  ae7d3e1b49
• 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
• 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