342 Commits

• chore: rework unified exec events (#7775)
  jif-oai · 2025-12-10 10:30:38 +00:00
  0ad54982ae
• 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
• Introduce ModelsManager and migrate app-server to use it. (#7552)
  Ahmed Ibrahim · 2025-12-03 17:17:56 -08:00
  00cc00ead8
• Migrate model preset (#7542)

  - Introduce `openai_models` in `/core`
  - Move `PRESETS` under it
  - Move `ModelPreset`, `ModelUpgrade`, `ReasoningEffortPreset`,
  `ReasoningEffortPreset`, and `ReasoningEffortPreset` to `protocol`
  - Introduce `Op::ListModels` and `EventMsg::AvailableModels`
  
  Next steps:
  - migrate `app-server` and `tui` to use the introduced Operation

  Ahmed Ibrahim · 2025-12-03 20:30:43 +00:00
  71504325d3
• feat: add compaction event (#7289)
  jif-oai · 2025-11-25 16:12:14 +00:00
  9ba27cfa0a
• chore: add cargo-deny configuration (#7119)

  - add GitHub workflow running cargo-deny on push/PR
  - document cargo-deny allowlist with workspace-dep notes and advisory
  ignores
  - align workspace crates to inherit version/edition/license for
  consistent checks

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874
• support MCP elicitations (#6947)

  No support for request schema yet, but we'll at least show the message
  and allow accept/decline.
  
  <img width="823" height="551" alt="Screenshot 2025-11-21 at 2 44 05 PM"
  src="https://github.com/user-attachments/assets/6fbb892d-ca12-4765-921e-9ac4b217534d"
  />

  Jeremy Rose · 2025-11-21 14:44:53 -08:00
  7561a6aaf0
• Migrate coverage to shell_command (#7042)
  pakrym-oai · 2025-11-21 03:44:00 +00:00
  767b66f407
• [app-server] feat: v2 apply_patch approval flow (#6760)

  This PR adds the API V2 version of the apply_patch approval flow, which
  centers around `ThreadItem::FileChange`.
  
  This PR wires the new RPC (`item/fileChange/requestApproval`, V2 only)
  and related events (`item/started`, `item/completed` for
  `ThreadItem::FileChange`, which are emitted in both V1 and V2) through
  the app-server
  protocol. The new approval RPC is only sent when the user initiates a
  turn with the new `turn/start` API so we don't break backwards
  compatibility with VSCE.
  
  Similar to https://github.com/openai/codex/pull/6758, the approach I
  took was to make as few changes to the Codex core as possible,
  leveraging existing `EventMsg` core events, and translating those in
  app-server. I did have to add a few additional fields to
  `EventMsg::PatchApplyBegin` and `EventMsg::PatchApplyEnd`, but those
  were fairly lightweight.
  
  However, the `EventMsg`s emitted by core are the following:
  ```
  1) Auto-approved (no request for approval)

  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  2) Approved by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  3) Declined by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  ```
  
  For a request triggering an approval, this would result in:
  ```
  item/fileChange/requestApproval
  item/started
  item/completed
  ```
  
  which is different from the `ThreadItem::CommandExecution` flow
  introduced in https://github.com/openai/codex/pull/6758, which does the
  below and is preferable:
  ```
  item/started
  item/commandExecution/requestApproval
  item/completed
  ```
  
  To fix this, we leverage `TurnSummaryStore` on codex_message_processor
  to store a little bit of state, allowing us to fire `item/started` and
  `item/fileChange/requestApproval` whenever we receive the underlying
  `EventMsg::ApplyPatchApprovalRequest`, and no-oping when we receive the
  `EventMsg::PatchApplyBegin` later.
  
  This is much less invasive than modifying the order of EventMsg within
  core (I tried).
  
  The resulting payloads:
  ```
  {
    "method": "item/started",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "inProgress",
        "type": "fileChange"
      }
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "method": "item/fileChange/requestApproval",
    "params": {
      "grantRoot": null,
      "itemId": "call_Nxnwj7B3YXigfV6Mwh03d686",
      "reason": null,
      "threadId": "019a9e11-8295-7883-a283-779e06502c6f",
      "turnId": "1"
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "result": {
      "decision": "accept"
    }
  }
  ```
  
  ```
  {
    "method": "item/completed",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "completed",
        "type": "fileChange"
      }
    }
  }
  ```

  Owen Lin · 2025-11-19 20:13:31 -08:00
  d6c30ed25e
• fix: add more fields to ThreadStartResponse and ThreadResumeResponse (#6847)

  This adds the following fields to `ThreadStartResponse` and
  `ThreadResumeResponse`:
  
  ```rust
      pub model: String,
      pub model_provider: String,
      pub cwd: PathBuf,
      pub approval_policy: AskForApproval,
      pub sandbox: SandboxPolicy,
      pub reasoning_effort: Option<ReasoningEffort>,
  ```
  
  This is important because these fields are optional in
  `ThreadStartParams` and `ThreadResumeParams`, so the caller needs to be
  able to determine what values were ultimately used to start/resume the
  conversation. (Though note that any of these could be changed later
  between turns in the conversation.)
  
  Though to get this information reliably, it must be read from the
  internal `SessionConfiguredEvent` that is created in response to the
  start of a conversation. Because `SessionConfiguredEvent` (as defined in
  `codex-rs/protocol/src/protocol.rs`) did not have all of these fields, a
  number of them had to be added as part of this PR.
  
  Because `SessionConfiguredEvent` is referenced in many tests, test
  instances of `SessionConfiguredEvent` had to be updated, as well, which
  is why this PR touches so many files.

  Michael Bolin · 2025-11-18 21:18:43 -08:00
  a75321a64c
• [app-server] feat: add v2 command execution approval flow (#6758)

  This PR adds the API V2 version of the command‑execution approval flow
  for the shell tool.
  
  This PR wires the new RPC (`item/commandExecution/requestApproval`, V2
  only) and related events (`item/started`, `item/completed`, and
  `item/commandExecution/delta`, which are emitted in both V1 and V2)
  through the app-server
  protocol. The new approval RPC is only sent when the user initiates a
  turn with the new `turn/start` API so we don't break backwards
  compatibility with VSCE.
  
  The approach I took was to make as few changes to the Codex core as
  possible, leveraging existing `EventMsg` core events, and translating
  those in app-server. I did have to add additional fields to
  `EventMsg::ExecCommandEndEvent` to capture the command's input so that
  app-server can statelessly transform these events to a
  `ThreadItem::CommandExecution` item for the `item/completed` event.
  
  Once we stabilize the API and it's complete enough for our partners, we
  can work on migrating the core to be aware of command execution items as
  a first-class concept.
  
  **Note**: We'll need followup work to make sure these APIs work for the
  unified exec tool, but will wait til that's stable and landed before
  doing a pass on app-server.
  
  Example payloads below:
  ```
  {
    "method": "item/started",
    "params": {
      "item": {
        "aggregatedOutput": null,
        "command": "/bin/zsh -lc 'touch /tmp/should-trigger-approval'",
        "cwd": "/Users/owen/repos/codex/codex-rs",
        "durationMs": null,
        "exitCode": null,
        "id": "call_lNWWsbXl1e47qNaYjFRs0dyU",
        "parsedCmd": [
          {
            "cmd": "touch /tmp/should-trigger-approval",
            "type": "unknown"
          }
        ],
        "status": "inProgress",
        "type": "commandExecution"
      }
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "method": "item/commandExecution/requestApproval",
    "params": {
      "itemId": "call_lNWWsbXl1e47qNaYjFRs0dyU",
      "parsedCmd": [
        {
          "cmd": "touch /tmp/should-trigger-approval",
          "type": "unknown"
        }
      ],
      "reason": "Need to create file in /tmp which is outside workspace sandbox",
      "risk": null,
      "threadId": "019a93e8-0a52-7fe3-9808-b6bc40c0989a",
      "turnId": "1"
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "result": {
      "acceptSettings": {
        "forSession": false
      },
      "decision": "accept"
    }
  }
  ```
  
  ```
  {
    "params": {
      "item": {
        "aggregatedOutput": null,
        "command": "/bin/zsh -lc 'touch /tmp/should-trigger-approval'",
        "cwd": "/Users/owen/repos/codex/codex-rs",
        "durationMs": 224,
        "exitCode": 0,
        "id": "call_lNWWsbXl1e47qNaYjFRs0dyU",
        "parsedCmd": [
          {
            "cmd": "touch /tmp/should-trigger-approval",
            "type": "unknown"
          }
        ],
        "status": "completed",
        "type": "commandExecution"
      }
    }
  }
  ```

  Owen Lin · 2025-11-18 00:23:54 +00:00
  cecbd5b021
• core/tui: non-blocking MCP startup (#6334)

  This makes MCP startup not block TUI startup. Messages sent while MCPs
  are booting will be queued.
  
  
  https://github.com/user-attachments/assets/96e1d234-5d8f-4932-a935-a675d35c05e0
  
  
  Fixes #6317
  
  ---------
  
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  Jeremy Rose · 2025-11-17 11:26:11 -08:00
  03ffe4d595
• Add warning on compact (#6052)

  This PR introduces the ability for `core` to send `warnings` as it can
  send `errors. It also sends a warning on compaction.
  
  <img width="811" height="187" alt="image"
  src="https://github.com/user-attachments/assets/0947a42d-b720-420d-b7fd-115f8a65a46a"
  />

  Ahmed Ibrahim · 2025-10-31 13:27:33 -07:00
  c8ebb2a0dc
• [Hygiene] Remove include_view_image_tool config (#5976)

  There's still some debate about whether we want to expose
  `tools.view_image` or `feature.view_image` so those are left unchanged
  for now, but this old `include_view_image_tool` config is good-to-go.
  Also updated the doc to reflect that `view_image` tool is now by default
  true.

  Celia Chen · 2025-10-30 13:23:24 -07:00
  6ef658a9f9
• [codex] add developer instructions (#5897)

  we are using developer instructions for code reviews, we need to pass
  them in cli as well.

  Anton Panasenko · 2025-10-30 11:18:31 -07:00
  9572cfc782
• feat: compaction prompt configurable (#5959)

  ```
   codex -c compact_prompt="Summarize in bullet points"
   ```

  jif-oai · 2025-10-30 14:24:24 +00:00
  f4f9695978
• Add item streaming events (#5546)

  Adds AgentMessageContentDelta, ReasoningContentDelta,
  ReasoningRawContentDelta item streaming events while maintaining
  compatibility for old events.
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  pakrym-oai · 2025-10-29 22:33:57 +00:00
  3429e82e45
• feat: deprecation warning (#5825)

  <img width="955" height="311" alt="Screenshot 2025-10-28 at 14 26 25"
  src="https://github.com/user-attachments/assets/99729b3d-3bc9-4503-aab3-8dc919220ab4"
  />

  jif-oai · 2025-10-29 12:29:28 +00:00
  060637b4d4
• [Auth] Choose which auth storage to use based on config (#5792)

  This PR is a follow-up to #5591. It allows users to choose which auth
  storage mode they want by using the new
  `cli_auth_credentials_store_mode` config.

  Celia Chen · 2025-10-27 19:41:49 -07:00
  4a42c4e142
• feat: TUI undo op (#5629)
  jif-oai · 2025-10-27 10:55:29 +00:00
  afc4eaab8b
• Add feedback upload request handling (#5682)
  Ahmed Ibrahim · 2025-10-27 05:53:39 +00:00
  f178805252
• [codex][app-server] introduce codex/event/raw_item events (#5578)
  Anton Panasenko · 2025-10-24 22:41:52 +00:00
  6af83d86ff
• Added model summary and risk assessment for commands that violate sandbox policy (#5536)

  This PR adds support for a model-based summary and risk assessment for
  commands that violate the sandbox policy and require user approval. This
  aids the user in evaluating whether the command should be approved.
  
  The feature works by taking a failed command and passing it back to the
  model and asking it to summarize the command, give it a risk level (low,
  medium, high) and a risk category (e.g. "data deletion" or "data
  exfiltration"). It uses a new conversation thread so the context in the
  existing thread doesn't influence the answer. If the call to the model
  fails or takes longer than 5 seconds, it falls back to the current
  behavior.
  
  For now, this is an experimental feature and is gated by a config key
  `experimental_sandbox_command_assessment`.
  
  Here is a screen shot of the approval prompt showing the risk assessment
  and summary.
  
  <img width="723" height="282" alt="image"
  src="https://github.com/user-attachments/assets/4597dd7c-d5a0-4e9f-9d13-414bd082fd6b"
  />

  Eric Traut · 2025-10-24 15:23:44 -07:00
  f8af4f5c8d
• Enable plan tool by default (#5384)

  ## Summary
  - make the plan tool available by default by removing the feature flag
  and always registering the handler
  - drop plan-tool CLI and API toggles across the exec, TUI, MCP server,
  and app server code paths
  - update tests and configs to reflect the always-on plan tool and guard
  workspace restriction tests against env leakage
  
  ## Testing
  Manually tested the extension. 
  ------
  https://chatgpt.com/codex/tasks/task_i_68f67a3ff2d083209562a773f814c1f9

  pakrym-oai · 2025-10-21 16:25:05 +00:00
  1b10a3a1b2
• Add ItemStarted/ItemCompleted events for UserInputItem (#5306)

  Adds a new ItemStarted event and delivers UserMessage as the first item
  type (more to come).
  
  
  Renames `InputItem` to `UserInput` considering we're using the `Item`
  suffix for actual items.

  pakrym-oai · 2025-10-20 13:34:44 -07:00
  9c903c4716
• chore: rework tools execution workflow (#5278)

  Re-work the tool execution flow. Read `orchestrator.rs` to understand
  the structure

  jif-oai · 2025-10-20 20:57:37 +01:00
  5e4f3bbb0b
• feat: add --add-dir flag for extra writable roots (#5335)

  Add a `--add-dir` CLI flag so sessions can use extra writable roots in
  addition to the ones specified in the config file. These are ephemerally
  added during the session only.
  
  Fixes #3303
  Fixes #2797

  Thibault Sottiaux · 2025-10-18 22:13:53 -07:00
  4f46360aa4
• feat: add Vec<ParsedCommand> to ExecApprovalRequestEvent (#5222)

  This adds `parsed_cmd: Vec<ParsedCommand>` to `ExecApprovalRequestEvent`
  in the core protocol (`protocol/src/protocol.rs`), which is also what
  this field is named on `ExecCommandBeginEvent`. Honestly, I don't love
  the name (it sounds like a single command, but it is actually a list of
  them), but I don't want to get distracted by a naming discussion right
  now.
  
  This also adds `parsed_cmd` to `ExecCommandApprovalParams` in
  `codex-rs/app-server-protocol/src/protocol.rs`, so it will be available
  via `codex app-server`, as well.
  
  For consistency, I also updated `ExecApprovalElicitRequestParams` in
  `codex-rs/mcp-server/src/exec_approval.rs` to include this field under
  the name `codex_parsed_cmd`, as that struct already has a number of
  special `codex_*` fields. Note this is the code for when Codex is used
  as an MCP _server_ and therefore has to conform to the official spec for
  an MCP elicitation type.

  Michael Bolin · 2025-10-15 13:58:40 -07:00
  995f5c3614
• revert /name for now (#4978)

  There was a regression where we'd read entire rollout contents if there
  was no /name present.

  dedrisian-oai · 2025-10-08 17:13:49 -07:00
  4300236681
• feat: Set chat name (#4974)

  Set chat name with `/name` so they appear in the codex resume page:
  
  
  https://github.com/user-attachments/assets/c0252bba-3a53-44c7-a740-f4690a3ad405

  dedrisian-oai · 2025-10-08 16:35:35 -07:00
  ec238a2c39
• add(core): managed config (#3868)

  ## Summary
  
  - Factor `load_config_as_toml` into `core::config_loader` so config
  loading is reusable across callers.
  - Layer `~/.codex/config.toml`, optional `~/.codex/managed_config.toml`,
  and macOS managed preferences (base64) with recursive table merging and
  scoped threads per source.
  
  ## Config Flow
  
  ```
  Managed prefs (macOS profile: com.openai.codex/config_toml_base64)
                                 ▲
                                 │
  ~/.codex/managed_config.toml   │  (optional file-based override)
                                 ▲
                                 │
                  ~/.codex/config.toml (user-defined settings)
  ```
  
  - The loader searches under the resolved `CODEX_HOME` directory
  (defaults to `~/.codex`).
  - Managed configs let administrators ship fleet-wide overrides via
  device profiles which is useful for enforcing certain settings like
  sandbox or approval defaults.
  - For nested hash tables: overlays merge recursively. Child tables are
  merged key-by-key, while scalar or array values replace the prior layer
  entirely. This lets admins add or tweak individual fields without
  clobbering unrelated user settings.

  Fouad Matin · 2025-10-03 13:02:26 -07:00
  a5b7675e42
• Separate interactive and non-interactive sessions (#4612)

  Do not show exec session in VSCode/TUI selector.

  pakrym-oai · 2025-10-02 13:06:21 -07:00
  4c566d484a
• show "Viewed Image" when the model views an image (#4475)

  <img width="1022" height="339" alt="Screenshot 2025-09-29 at 4 22 00 PM"
  src="https://github.com/user-attachments/assets/12da7358-19be-4010-a71b-496ede6dfbbf"
  />

  Jeremy Rose · 2025-10-02 18:36:03 +00:00
  45936f8fbd
• Support CODEX_API_KEY for codex exec (#4615)

  Allows to set API key per invocation of `codex exec`

  pakrym-oai · 2025-10-02 09:59:45 -07:00
  2f6fb37d72
• fix: remove mcp-types from app server protocol (#4537)

  We continue the separation between `codex app-server` and `codex
  mcp-server`.
  
  In particular, we introduce a new crate, `codex-app-server-protocol`,
  and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it
  `codex-rs/app-server-protocol/src/protocol.rs`.
  
  Because `ConversationId` was defined in `mcp_protocol.rs`, we move it
  into its own file, `codex-rs/protocol/src/conversation_id.rs`, and
  because it is referenced in a ton of places, we have to touch a lot of
  files as part of this PR.
  
  We also decide to get away from proper JSON-RPC 2.0 semantics, so we
  also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which
  is basically the same `JSONRPCMessage` type defined in `mcp-types`
  except with all of the `"jsonrpc": "2.0"` removed.
  
  Getting rid of `"jsonrpc": "2.0"` makes our serialization logic
  considerably simpler, as we can lean heavier on serde to serialize
  directly into the wire format that we use now.

  Michael Bolin · 2025-10-01 02:16:26 +00:00
  5881c0d6d4
• fix: separate codex mcp into codex mcp-server and codex app-server (#4471)

  This is a very large PR with some non-backwards-compatible changes.
  
  Historically, `codex mcp` (or `codex mcp serve`) started a JSON-RPC-ish
  server that had two overlapping responsibilities:
  
  - Running an MCP server, providing some basic tool calls.
  - Running the app server used to power experiences such as the VS Code
  extension.
  
  This PR aims to separate these into distinct concepts:
  
  - `codex mcp-server` for the MCP server
  - `codex app-server` for the "application server"
  
  Note `codex mcp` still exists because it already has its own subcommands
  for MCP management (`list`, `add`, etc.)
  
  The MCP logic continues to live in `codex-rs/mcp-server` whereas the
  refactored app server logic is in the new `codex-rs/app-server` folder.
  Note that most of the existing integration tests in
  `codex-rs/mcp-server/tests/suite` were actually for the app server, so
  all the tests have been moved with the exception of
  `codex-rs/mcp-server/tests/suite/mod.rs`.
  
  Because this is already a large diff, I tried not to change more than I
  had to, so `codex-rs/app-server/tests/common/mcp_process.rs` still uses
  the name `McpProcess` for now, but I will do some mechanical renamings
  to things like `AppServer` in subsequent PRs.
  
  While `mcp-server` and `app-server` share some overlapping functionality
  (like reading streams of JSONL and dispatching based on message types)
  and some differences (completely different message types), I ended up
  doing a bit of copypasta between the two crates, as both have somewhat
  similar `message_processor.rs` and `outgoing_message.rs` files for now,
  though I expect them to diverge more in the near future.
  
  One material change is that of the initialize handshake for `codex
  app-server`, as we no longer use the MCP types for that handshake.
  Instead, we update `codex-rs/protocol/src/mcp_protocol.rs` to add an
  `Initialize` variant to `ClientRequest`, which takes the `ClientInfo`
  object we need to update the `USER_AGENT_SUFFIX` in
  `codex-rs/app-server/src/message_processor.rs`.
  
  One other material change is in
  `codex-rs/app-server/src/codex_message_processor.rs` where I eliminated
  a use of the `send_event_as_notification()` method I am generally trying
  to deprecate (because it blindly maps an `EventMsg` into a
  `JSONNotification`) in favor of `send_server_notification()`, which
  takes a `ServerNotification`, as that is intended to be a custom enum of
  all notification types supported by the app server. So to make this
  update, I had to introduce a new variant of `ServerNotification`,
  `SessionConfigured`, which is a non-backwards compatible change with the
  old `codex mcp`, and clients will have to be updated after the next
  release that contains this PR. Note that
  `codex-rs/app-server/tests/suite/list_resume.rs` also had to be update
  to reflect this change.
  
  I introduced `codex-rs/utils/json-to-toml/src/lib.rs` as a small utility
  crate to avoid some of the copying between `mcp-server` and
  `app-server`.

  Michael Bolin · 2025-09-30 07:06:18 +00:00
  d9dbf48828
• [mcp-server] Expose fuzzy file search in MCP (#2677)

  ## Summary
  Expose a simple fuzzy file search implementation for mcp clients to work
  with
  
  ## Testing
  - [x] Tested locally

  Dylan · 2025-09-29 12:19:09 -07:00
  197f45a3be
• make tests pass cleanly in sandbox (#4067)

  This changes the reqwest client used in tests to be sandbox-friendly,
  and skips a bunch of other tests that don't work inside the
  sandbox/without network.

  Jeremy Rose · 2025-09-25 13:11:14 -07:00
  4a5f05c136
• Add exec output-schema parameter (#4079)

  Adds structured output to `exec` via the `--structured-output`
  parameter.

  pakrym-oai · 2025-09-23 13:59:16 -07:00
  fdb8dadcae
• Use anyhow::Result in tests for error propagation (#4105)
  pakrym-oai · 2025-09-23 13:31:36 -07:00
  0f9a796617
• feat: update default (#4076)

  Changes:
  - Default model and docs now use gpt-5-codex. 
  - Disables the GPT-5 Codex NUX by default.
  - Keeps presets available for API key users.

  Thibault Sottiaux · 2025-09-22 20:10:52 -07:00
  c93e77b68b
• chore: clippy on redundant closure (#4058)

  Add redundant closure clippy rules and let Codex fix it by minimising
  FQP

  jif-oai · 2025-09-22 19:30:16 +00:00
  be366a31ab
• chore: unify cargo versions (#4044)

  Unify cargo versions at root

  jif-oai · 2025-09-22 16:47:01 +00:00
  e5fe50d3ce
• Add non_sandbox_test helper (#3880)

  Makes tests shorter

  pakrym-oai · 2025-09-22 14:50:41 +00:00
  14a115d488
• fix: ensure cwd for conversation and sandbox are separate concerns (#3874)

  Previous to this PR, both of these functions take a single `cwd`:
  
  
  https://github.com/openai/codex/blob/71038381aa0f51aa62e1a2bcc7cbf26a05b141f3/codex-rs/core/src/seatbelt.rs#L19-L25
  
  
  https://github.com/openai/codex/blob/71038381aa0f51aa62e1a2bcc7cbf26a05b141f3/codex-rs/core/src/landlock.rs#L16-L23
  
  whereas `cwd` and `sandbox_cwd` should be set independently (fixed in
  this PR).
  
  Added `sandbox_distinguishes_command_and_policy_cwds()` to
  `codex-rs/exec/tests/suite/sandbox.rs` to verify this.

  Michael Bolin · 2025-09-18 14:37:06 -07:00
  8595237505
• Switch to uuid_v7 and tighten ConversationId usage (#3819)

  Make sure conversations have a timestamp.

  pakrym-oai · 2025-09-18 14:37:03 +00:00
  d4aba772cb
• Fix get_auth_status response when using custom provider (#3581)

  This PR addresses an edge-case bug that appears in the VS Code extension
  in the following situation:
  1. Log in using ChatGPT (using either the CLI or extension). This will
  create an `auth.json` file.
  2. Manually modify `config.toml` to specify a custom provider.
  3. Start a fresh copy of the VS Code extension.
  
  The profile menu in the VS Code extension will indicate that you are
  logged in using ChatGPT even though you're not.
  
  This is caused by the `get_auth_status` method returning an
  `auth_method: 'chatgpt'` when a custom provider is configured and it
  doesn't use OpenAI auth (i.e. `requires_openai_auth` is false). The
  method should always return `auth_method: None` if
  `requires_openai_auth` is false.
  
  The same bug also causes the NUX (new user experience) screen to be
  displayed in the VSCE in this situation.

  Eric Traut · 2025-09-14 18:27:02 -07:00
  e5dd7f0934
• Review Mode (Core) (#3401)

  ## 📝 Review Mode -- Core
  
  This PR introduces the Core implementation for Review mode:
  
  - New op `Op::Review { prompt: String }:` spawns a child review task
  with isolated context, a review‑specific system prompt, and a
  `Config.review_model`.
  - `EnteredReviewMode`: emitted when the child review session starts.
  Every event from this point onwards reflects the review session.
  - `ExitedReviewMode(Option<ReviewOutputEvent>)`: emitted when the review
  finishes or is interrupted, with optional structured findings:
  
  ```json
  {
    "findings": [
      {
        "title": "<≤ 80 chars, imperative>",
        "body": "<valid Markdown explaining *why* this is a problem; cite files/lines/functions>",
        "confidence_score": <float 0.0-1.0>,
        "priority": <int 0-3>,
        "code_location": {
          "absolute_file_path": "<file path>",
          "line_range": {"start": <int>, "end": <int>}
        }
      }
    ],
    "overall_correctness": "patch is correct" | "patch is incorrect",
    "overall_explanation": "<1-3 sentence explanation justifying the overall_correctness verdict>",
    "overall_confidence_score": <float 0.0-1.0>
  }
  ```
  
  ## Questions
  
  ### Why separate out its own message history?
  
  We want the review thread to match the training of our review models as
  much as possible -- that means using a custom prompt, removing user
  instructions, and starting a clean chat history.
  
  We also want to make sure the review thread doesn't leak into the parent
  thread.
  
  ### Why do this as a mode, vs. sub-agents?
  
  1. We want review to be a synchronous task, so it's fine for now to do a
  bespoke implementation.
  2. We're still unclear about the final structure for sub-agents. We'd
  prefer to land this quickly and then refactor into sub-agents without
  rushing that implementation.

  dedrisian-oai · 2025-09-12 23:25:10 +00:00
  90a0fd342f
• feat: reasoning effort as optional (#3527)

  Allow the reasoning effort to be optional

  jif-oai · 2025-09-12 12:06:33 -07:00
  c6fd056aa6