29 Commits

• feat(core): plumb distinct approval ids for command approvals (#12051)

  zsh fork PR stack:
  - https://github.com/openai/codex/pull/12051 👈 
  - https://github.com/openai/codex/pull/12052
  
  With upcoming support for a fork of zsh that allows us to intercept
  `execve` and run execpolicy checks for each subcommand as part of a
  `CommandExecution`, it will be possible for there to be multiple
  approval requests for a shell command like `/path/to/zsh -lc 'git status
  && rg \"TODO\" src && make test'`.
  
  To support that, this PR introduces a new `approval_id` field across
  core, protocol, and app-server so that we can associate approvals
  properly for subcommands.

  Owen Lin · 2026-02-18 01:55:57 +00:00
  db4d2599b5
• feat(core): add structured network approval plumbing and policy decision model (#11672)

  ### Description
  #### Summary
  Introduces the core plumbing required for structured network approvals
  
  #### What changed
  - Added structured network policy decision modeling in core.
  - Added approval payload/context types needed for network approval
  semantics.
  - Wired shell/unified-exec runtime plumbing to consume structured
  decisions.
  - Updated related core error/event surfaces for structured handling.
  - Updated protocol plumbing used by core approval flow.
  - Included small CLI debug sandbox compatibility updates needed by this
  layer.
  
  #### Why
  establishes the minimal backend foundation for network approvals without
  yet changing high-level orchestration or TUI behavior.
  
  #### Notes
  - Behavior remains constrained by existing requirements/config gating.
  - Follow-up PRs in the stack handle orchestration, UX, and app-server
  integration.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-14 04:18:12 +00:00
  b527ee2890
• 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
• 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: update parallel tool call exec approval to approve on request id (#11162)

  ### Summary
  
  In parallel tool call, exec command approvals were not approved at
  request level but at a turn level. i.e. when a single request is
  approved, the system currently treats all requests in turn as approved.
  
  ### Before
  
  https://github.com/user-attachments/assets/d50ed129-b3d2-4b2f-97fa-8601eb11f6a8
  
  ### After
  
  https://github.com/user-attachments/assets/36528a43-a4aa-4775-9e12-f13287ef19fc

  Shijie Rao · 2026-02-10 09:38:00 -08:00
  c4b771a16f
• Added support for live updates to skills (#10478)

  Add a centralized FileWatcher in codex-core (using notify) that watches
  skill roots from the config layer stack (recursive)
  
  Send `SkillsChanged` events when relevant file system changes are
  detected
  
  On `SkillsChanged`:
  * Invalidate the skills cache immediately in ThreadManager
  * Emit EventMsg::SkillsUpdateAvailable to active sessions
  ~~* Broadcast a new app-server notification:
  SkillsListUpdatedNotification~~
  
  This change does not inject new items into the event stream. That means
  the agent will not know about new skills, so it won't be able to
  implicitly invoke new skills. It also won't know about changes to
  existing skills, so if it has already read the contents of a modified
  skill, it will not honor the new behavior.
  
  This change also does not detect modifications to AGENTS.md.
  
  I plan to address these limitations in a follow-on PR modeled after
  #9985. Injection of new skills and AGENTS was deemed to risky, hence the
  need to split the feature into two stages. The changes in this PR were
  designed to easily accommodate the second stage once we have some other
  foundational changes in place.
  
  Testing: In addition to automated tests, I did manual testing to confirm
  that newly-created skills, deleted skills, and renamed skills are
  reflected in the TUI skill picker menu. Also confirmed that
  modifications to behaviors for explicitly-invoked skills are honored.
  
  ---------
  
  Co-authored-by: Xin Lin <xl@openai.com>

  Eric Traut · 2026-02-04 15:25:03 -08:00
  7bcc552325
• fix(app-server): fix approval events in review mode (#10416)

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

  Owen Lin · 2026-02-03 12:08:17 -08:00
  d9ad5c3c49
• 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
• 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
• 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
• feat: add wait tool implementation for collab (#9088)

  Add implementation for the `wait` tool.
  
  For this we consider all status different from `PendingInit` and
  `Running` as terminal. The `wait` tool call will return either after a
  given timeout or when the tool reaches a non-terminal status.
  
  A few points to note:
  * The usage of a channel is preferred to prevent some races (just
  looping on `get_status()` could "miss" a terminal status)
  * The order of operations is very important, we need to first subscribe
  and then check the last known status to prevent race conditions
  * If the channel gets dropped, we return an error on purpose

  jif-oai · 2026-01-12 12:16:24 +00:00
  623707ab58
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• 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: drop agent bus and store the agent status in codex directly (#8788)
  jif-oai · 2026-01-06 19:44:39 +00:00
  188f79afee
• feat: agent controller (#8783)

  Added an agent control plane that lets sessions spawn or message other
  conversations via `AgentControl`.
  
  `AgentBus` (core/src/agent/bus.rs) keeps track of the last known status
  of a conversation.
  
  ConversationManager now holds shared state behind an Arc so AgentControl
  keeps only a weak back-reference, the goal is just to avoid explicit
  cycle reference.
  
  Follow-ups:
  * Build a small tool in the TUI to be able to see every agent and send
  manual message to each of them
  * Handle approval requests in this TUI
  * Add tools to spawn/communicate between agents (see related design)
  * Define agent types

  jif-oai · 2026-01-06 19:08:02 +00:00
  1dd1355df3
• 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
• Account for last token count on resume (#8677)

  last token count in context manager is initialized to 0. Gets populated
  only on events from server.
  
  This PR populates it on resume so we can decide if we need to compact or
  not.

  Ahmed Ibrahim · 2026-01-02 23:20:20 +00:00
  efd2d76484
• Rename OpenAI models to models manager (#8346)

  # 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 · 2025-12-19 16:20:05 -08:00
  f0dc6fd3c7
• chore: migrate from Config::load_from_base_config_with_overrides to ConfigBuilder (#8276)

  https://github.com/openai/codex/pull/8235 introduced `ConfigBuilder` and
  this PR updates all call non-test call sites to use it instead of
  `Config::load_from_base_config_with_overrides()`.
  
  This is important because `load_from_base_config_with_overrides()` uses
  an empty `ConfigRequirements`, which is a reasonable default for testing
  so the tests are not influenced by the settings on the host. This method
  is now guarded by `#[cfg(test)]` so it cannot be used by business logic.
  
  Because `ConfigBuilder::build()` is `async`, many of the test methods
  had to be migrated to be `async`, as well. On the bright side, this made
  it possible to eliminate a bunch of `block_on_future()` stuff.

  Michael Bolin · 2025-12-18 16:12:52 -08:00
  3d4ced3ff5
• Reimplement skills loading using SkillsManager + skills/list op. (#7914)

  refactor the way we load and manage skills:
  1. Move skill discovery/caching into SkillsManager and reuse it across
  sessions.
  2. Add the skills/list API (Op::ListSkills/SkillsListResponse) to fetch
  skills for one or more cwds. Also update app-server for VSCE/App;
  3. Trigger skills/list during session startup so UIs preload skills and
  handle errors immediately.

  xl-openai · 2025-12-14 09:58:17 -08:00
  5d77d4db6b
• Removed experimental "command risk assessment" feature (#7799)

  This experimental feature received lukewarm reception during internal
  testing. Removing from the code base.

  Eric Traut · 2025-12-10 09:48:11 -08:00
  c4af707e09
• Refactor execpolicy fallback evaluation (#7544)

  ## Refactor of the `execpolicy` crate
  
  To illustrate why we need this refactor, consider an agent attempting to
  run `apple | rm -rf ./`. Suppose `apple` is allowed by `execpolicy`.
  Before this PR, `execpolicy` would consider `apple` and `pear` and only
  render one rule match: `Allow`. We would skip any heuristics checks on
  `rm -rf ./` and immediately approve `apple | rm -rf ./` to run.
  
  To fix this, we now thread a `fallback` evaluation function into
  `execpolicy` that runs when no `execpolicy` rules match a given command.
  In our example, we would run `fallback` on `rm -rf ./` and prevent
  `apple | rm -rf ./` from being run without approval.

  zhao-oai · 2025-12-03 23:39:48 -08:00
  3d35cb4619
• whitelist command prefix integration in core and tui (#7033)

  this PR enables TUI to approve commands and add their prefixes to an
  allowlist:
  <img width="708" height="605" alt="Screenshot 2025-11-21 at 4 18 07 PM"
  src="https://github.com/user-attachments/assets/56a19893-4553-4770-a881-becf79eeda32"
  />
  
  note: we only show the option to whitelist the command when 
  1) command is not multi-part (e.g `git add -A && git commit -m 'hello
  world'`)
  2) command is not already matched by an existing rule

  zhao-oai · 2025-12-03 23:17:02 -08:00
  e925a380dc
• 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
• fix: codex delegate cancellation (#7092)
  jif-oai · 2025-11-24 16:59:09 +00:00
  920239f272
• ignore deltas in codex_delegate (#6208)

  ignore legacy deltas in codex-delegate to avoid this
  [issue](https://github.com/openai/codex/pull/6202).

  Ahmed Ibrahim · 2025-11-04 19:21:35 +00:00
  fe54c216a3
• Pass initial history as an optional to codex delegate (#5950)

  This will give us more freedom on controlling the delegation. i.e we can
  fork our history and run `compact`.

  Ahmed Ibrahim · 2025-10-30 07:22:42 -07:00
  5fcc380bd9
• Delegate review to codex instance (#5572)

  In this PR, I am exploring migrating task kind to an invocation of
  Codex. The main reason would be getting rid off multiple
  `ConversationHistory` state and streamlining our context/history
  management.
  
  This approach depends on opening a channel between the sub-codex and
  codex. This channel is responsible for forwarding `interactive`
  (`approvals`) and `non-interactive` events. The `task` is responsible
  for handling those events.
  
  This opens the door for implementing `codex as a tool`, replacing
  `compact` and `review`, and potentially subagents.
  
  One consideration is this code is very similar to `app-server` specially
  in the approval part. If in the future we wanted an interactive
  `sub-codex` we should consider using `codex-mcp`

  Ahmed Ibrahim · 2025-10-29 21:04:25 +00:00
  13e1d0362d