474 Commits

• feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496)

  This PR introduces a `codex-utils-cargo-bin` utility crate that
  wraps/replaces our use of `assert_cmd::Command` and
  `escargot::CargoBuild`.
  
  As you can infer from the introduction of `buck_project_root()` in this
  PR, I am attempting to make it possible to build Codex under
  [Buck2](https://buck2.build) as well as `cargo`. With Buck2, I hope to
  achieve faster incremental local builds (largely due to Buck2's
  [dice](https://buck2.build/docs/insights_and_knowledge/modern_dice/)
  build strategy, as well as benefits from its local build daemon) as well
  as faster CI builds if we invest in remote execution and caching.
  
  See
  https://buck2.build/docs/getting_started/what_is_buck2/#why-use-buck2-key-advantages
  for more details about the performance advantages of Buck2.
  
  Buck2 enforces stronger requirements in terms of build and test
  isolation. It discourages assumptions about absolute paths (which is key
  to enabling remote execution). Because the `CARGO_BIN_EXE_*` environment
  variables that Cargo provides are absolute paths (which
  `assert_cmd::Command` reads), this is a problem for Buck2, which is why
  we need this `codex-utils-cargo-bin` utility.
  
  My WIP-Buck2 setup sets the `CARGO_BIN_EXE_*` environment variables
  passed to a `rust_test()` build rule as relative paths.
  `codex-utils-cargo-bin` will resolve these values to absolute paths,
  when necessary.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8496).
  * #8498
  * __->__ #8496

  Michael Bolin · 2025-12-23 19:29:32 -08:00
  e61bae12e3
• chore: enusre the logic that creates ConfigLayerStack has access to cwd (#8353)

  `load_config_layers_state()` should load config from a
  `.codex/config.toml` in any folder between the `cwd` for a thread and
  the project root. Though in order to do that,
  `load_config_layers_state()` needs to know what the `cwd` is, so this PR
  does the work to thread the `cwd` through for existing callsites.
  
  A notable exception is the `/config` endpoint in app server for which a
  `cwd` is not guaranteed to be associated with the query, so the `cwd`
  param is `Option<AbsolutePathBuf>` to account for this case.
  
  The logic to make use of the `cwd` will be done in a follow-up PR.

  Michael Bolin · 2025-12-19 20:11:27 -08:00
  a6974087e5
• feat: support allowed_sandbox_modes in requirements.toml (#8298)

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

  Michael Bolin · 2025-12-19 21:09:20 +00:00
  dc61fc5f50
• chore: cleanup Config instantiation codepaths (#8226)

  This PR does various types of cleanup before I can proceed with more
  ambitious changes to config loading.
  
  First, I noticed duplicated code across these two methods:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L314-L324
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L334-L344
  
  This has now been consolidated in
  `load_config_as_toml_with_cli_overrides()`.
  
  Further, I noticed that `Config::load_with_cli_overrides()` took two
  similar arguments:
  
  
  https://github.com/openai/codex/blob/774bd9e432fa2e0f4e059e97648cf92216912e19/codex-rs/core/src/config/mod.rs#L308-L311
  
  The difference between `cli_overrides` and `overrides` was not
  immediately obvious to me. At first glance, it appears that one should
  be able to be expressed in terms of the other, but it turns out that
  some fields of `ConfigOverrides` (such as `cwd` and
  `codex_linux_sandbox_exe`) are, by design, not configurable via a
  `.toml` file or a command-line `--config` flag.
  
  That said, I discovered that many callers of
  `Config::load_with_cli_overrides()` were passing
  `ConfigOverrides::default()` for `overrides`, so I created two separate
  methods:
  
  - `Config::load_with_cli_overrides(cli_overrides: Vec<(String,
  TomlValue)>)`
  - `Config::load_with_cli_overrides_and_harness_overrides(cli_overrides:
  Vec<(String, TomlValue)>, harness_overrides: ConfigOverrides)`
  
  The latter has a long name, as it is _not_ what should be used in the
  common case, so the extra typing is designed to draw attention to this
  fact. I tried to update the existing callsites to use the shorter name,
  where possible.
  
  Further, in the cases where `ConfigOverrides` is used, usually only a
  limited subset of fields are actually set, so I updated the declarations
  to leverage `..Default::default()` where possible.

  Michael Bolin · 2025-12-17 18:01:17 -08:00
  a8797019a1
• feat: Constrain values for approval_policy (#7778)

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

  gt-oai · 2025-12-17 16:19:27 +00:00
  9352c6b235
• feat: change ConfigLayerName into a disjoint union rather than a simple enum (#8095)

  This attempts to tighten up the types related to "config layers."
  Currently, `ConfigLayerEntry` is defined as follows:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/state.rs#L19-L25
  
  but the `source` field is a bit of a lie, as:
  
  - for `ConfigLayerName::Mdm`, it is
  `"com.openai.codex/config_toml_base64"`
  - for `ConfigLayerName::SessionFlags`, it is `"--config"`
  - for `ConfigLayerName::User`, it is `"config.toml"` (just the file
  name, not the path to the `config.toml` on disk that was read)
  - for `ConfigLayerName::System`, it seems like it is usually
  `/etc/codex/managed_config.toml` in practice, though on Windows, it is
  `%CODEX_HOME%/managed_config.toml`:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/layer_io.rs#L84-L101
  
  All that is to say, in three out of the four `ConfigLayerName`, `source`
  is a `PathBuf` that is not an absolute path (or even a true path).
  
  This PR tries to uplevel things by eliminating `source` from
  `ConfigLayerEntry` and turning `ConfigLayerName` into a disjoint union
  named `ConfigLayerSource` that has the appropriate metadata for each
  variant, favoring the use of `AbsolutePathBuf` where appropriate:
  
  ```rust
  pub enum ConfigLayerSource {
      /// Managed preferences layer delivered by MDM (macOS only).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      Mdm { domain: String, key: String },
      /// Managed config layer from a file (usually `managed_config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      System { file: AbsolutePathBuf },
      /// Session-layer overrides supplied via `-c`/`--config`.
      SessionFlags,
      /// User config layer from a file (usually `config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      User { file: AbsolutePathBuf },
  }
  ```

  Michael Bolin · 2025-12-17 08:13:59 -08:00
  de3fa03e1c
• Add public skills + improve repo skill discovery and error UX (#8098)

  1. Adds SkillScope::Public end-to-end (core + protocol) and loads skills
  from the public cache directory
  2. Improves repo skill discovery by searching upward for the nearest
  .codex/skills within a git repo
  3. Deduplicates skills by name with deterministic ordering to avoid
  duplicates across sources
  4. Fixes garbled “Skill errors” overlay rendering by preventing pending
  history lines from being injected during the modal
  5. Updates the project docs “Skills” intro wording to avoid hardcoded
  paths

  xl-openai · 2025-12-17 01:35:49 -08:00
  4897efcced
• 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
• [codex] add otel tracing (#7844)
  Anton Panasenko · 2025-12-12 17:07:17 -08:00
  ad7b9d63c3
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

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

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• Inject SKILL.md when it's explicitly mentioned. (#7763)

  1. Skills load once in core at session start; the cached outcome is
  reused across core and surfaced to TUI via SessionConfigured.
  2. TUI detects explicit skill selections, and core injects the matching
  SKILL.md content into the turn when a selected skill is present.

  xl-openai · 2025-12-10 13:59:17 -08:00
  b36ecb6c32
• make model optional in config (#7769)

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

  Ahmed Ibrahim · 2025-12-10 11:19:00 -08:00
  cb9a189857
• 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
• chore: rework unified exec events (#7775)
  jif-oai · 2025-12-10 10:30:38 +00:00
  0ad54982ae
• 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
• seatbelt: allow openpty() (#7507)

  This allows `openpty(3)` to run in the default sandbox. Also permit
  reading `kern.argmax`, which is the maximum number of arguments to
  exec().

  Jeremy Rose · 2025-12-03 09:15:38 -08:00
  9b3251f28f
• chore: review everywhere (#7444)
  jif-oai · 2025-12-02 11:26:27 +00:00
  4b78e2ab09
• feat: update process ID for event handling (#7261)
  jif-oai · 2025-11-25 14:21:05 -08:00
  28ff364c3a
• 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
• [app-server] feat: add Declined status for command exec (#7101)

  Add a `Declined` status for when we request an approval from the user
  and the user declines. This allows us to distinguish from commands that
  actually ran, but failed.
  
  This behaves similarly to apply_patch / FileChange, which does the same
  thing.

  Owen Lin · 2025-11-21 09:19:39 -08:00
  2ae1f81d84
• [app-server] update doc with codex error info (#6941)

  Document new codex error info. Also fixed the name from
  `codex_error_code` to `codex_error_info`.

  Celia Chen · 2025-11-21 01:02:37 +00:00
  7e2165f394
• [app-server & core] introduce new codex error code and v2 app-server error events (#6938)

  This PR does two things:
  1. populate a new `codex_error_code` protocol in error events sent from
  core to client;
  2. old v1 core events `codex/event/stream_error` and `codex/event/error`
  will now both become `error`. We also show codex error code for
  turncompleted -> error status.
  
  new events in app server test:
  ```
  < {
  <   "method": "codex/event/stream_error",
  <   "params": {
  <     "conversationId": "019aa34c-0c14-70e0-9706-98520a760d67",
  <     "id": "0",
  <     "msg": {
  <       "codex_error_code": {
  <         "response_stream_disconnected": {
  <           "http_status_code": 401
  <         }
  <       },
  <       "message": "Reconnecting... 2/5",
  <       "type": "stream_error"
  <     }
  <   }
  < }
  
   {
  <   "method": "error",
  <   "params": {
  <     "error": {
  <       "codexErrorCode": {
  <         "responseStreamDisconnected": {
  <           "httpStatusCode": 401
  <         }
  <       },
  <       "message": "Reconnecting... 2/5"
  <     }
  <   }
  < }
  
  < {
  <   "method": "turn/completed",
  <   "params": {
  <     "turn": {
  <       "error": {
  <         "codexErrorCode": {
  <           "responseTooManyFailedAttempts": {
  <             "httpStatusCode": 401
  <           }
  <         },
  <         "message": "exceeded retry limit, last status: 401 Unauthorized, request id: 9a1b495a1a97ed3e-SJC"
  <       },
  <       "id": "0",
  <       "items": [],
  <       "status": "failed"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-20 23:06:55 +00:00
  9bce050385
• codex-exec: allow resume --last to read prompt #6717 (#6719)

  ### Description
  
  - codex exec --json resume --last "<prompt>" bailed out because clap
  treated the prompt as SESSION_ID. I removed the conflicts_with flag and
  reinterpret that positional as a prompt when
  --last is set, so the flow now keeps working in JSON mode.
  (codex-rs/exec/src/cli.rs:84-104, codex-rs/exec/src/lib.rs:75-130)
  - Added a regression test that exercises resume --last in JSON mode to
  ensure the prompt is accepted and the rollout file is updated.
  (codex-rs/exec/tests/suite/resume.rs:126-178)
  
  ### Testing
  
    - just fmt
    - cargo test -p codex-exec
    - just fix -p codex-exec
    - cargo test -p codex-exec
  
  #6717
  
  Signed-off-by: Dmitri Khokhlov <dkhokhlov@cribl.io>

  Dmitri Khokhlov · 2025-11-20 13:10:49 -08:00
  e4257f432e
• [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
• Revert "[core] add optional status_code to error events (#6865)" (#6955)

  This reverts commit c2ec477d93.
  
  # 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.

  Celia Chen · 2025-11-20 01:26:14 +00:00
  72a1453ac5
• [core] add optional status_code to error events (#6865)

  We want to better uncover error status code for clients. Add an optional
  status_code to error events (thread error, error, stream error) so app
  server could uncover the status code from the client side later.
  
  in event log:
  ```
  < {
  <   "method": "codex/event/stream_error",
  <   "params": {
  <     "conversationId": "019a9a32-f576-7292-9711-8e57e8063536",
  <     "id": "0",
  <     "msg": {
  <       "message": "Reconnecting... 5/5",
  <       "status_code": 401,
  <       "type": "stream_error"
  <     }
  <   }
  < }
  < {
  <   "method": "codex/event/error",
  <   "params": {
  <     "conversationId": "019a9a32-f576-7292-9711-8e57e8063536",
  <     "id": "0",
  <     "msg": {
  <       "message": "exceeded retry limit, last status: 401 Unauthorized, request id: 9a0cb03a485067f7-SJC",
  <       "status_code": 401,
  <       "type": "error"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-19 19:51:21 +00:00
  c2ec477d93
• 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
• Update defaults to gpt-5.1 (#6652)

  ## Summary
  - update documentation, example configs, and automation defaults to
  reference gpt-5.1 / gpt-5.1-codex
  - bump the CLI and core configuration defaults, model presets, and error
  messaging to the new models while keeping the model-family/tool coverage
  for legacy slugs
  - refresh tests, fixtures, and TUI snapshots so they expect the upgraded
  defaults
  
  ## Testing
  - `cargo test -p codex-core
  config::tests::test_precedence_fixture_with_gpt5_profile`
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6916c5b3c2b08321ace04ee38604fc6b)

  Ahmed Ibrahim · 2025-11-17 17:40:11 -08:00
  ddcc60a085
• [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
• LM Studio OSS Support (#2312)

  ## Overview
  
  Adds LM Studio OSS support. Closes #1883
  
  
  ### Changes
  This PR enhances the behavior of `--oss` flag to support LM Studio as a
  provider. Additionally, it introduces a new flag`--local-provider` which
  can take in `lmstudio` or `ollama` as values if the user wants to
  explicitly choose which one to use.
  
  If no provider is specified `codex --oss` will auto-select the provider
  based on whichever is running.
  
  #### Additional enhancements 
  The default can be set using `oss-provider` in config like:
  
  ```
  oss_provider = "lmstudio"
  ```
  
  For non-interactive users, they will need to either provide the provider
  as an arg or have it in their `config.toml`
  
  ### Notes
  For best performance, [set the default context
  length](https://lmstudio.ai/docs/app/advanced/per-model) for gpt-oss to
  the maximum your machine can support
  
  ---------
  
  Co-authored-by: Matt Clayton <matt@lmstudio.ai>
  Co-authored-by: Eric Traut <etraut@openai.com>

  rugvedS07 · 2025-11-17 11:49:09 -08:00
  837bc98a1d
• 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
• feat: better UI for unified_exec (#6515)

  <img width="376" height="132" alt="Screenshot 2025-11-12 at 17 36 22"
  src="https://github.com/user-attachments/assets/ce693f0d-5ca0-462e-b170-c20811dcc8d5"
  />

  jif-oai · 2025-11-14 16:31:12 +01:00
  63c8c01f40
• tests: replace mount_sse_once_match with mount_sse_once for SSE mocking (#6640)
  pakrym-oai · 2025-11-13 18:04:05 -08:00
  6c384eb9c6
• feat: Add support for --add-dir to exec and TypeScript SDK (#6565)

  ## Summary
  
  Adds support for specifying additional directories in the TypeScript SDK
  through a new `additionalDirectories` option in `ThreadOptions`.
  
  ## Changes
  
  - Added `additionalDirectories` parameter to `ThreadOptions` interface
  - Updated `CodexExec` to accept and pass through additional directories
  via the `--config` flag for `sandbox_workspace_write.writable_roots`
  - Added comprehensive test coverage for the new functionality
  
  ## Test plan
  
  - Added test case that verifies `additionalDirectories` is correctly
  passed as repeated flags
  - Existing tests continue to pass
  
  ---------
  
  Co-authored-by: Claude <noreply@anthropic.com>

  Dan Hernandez · 2025-11-13 13:47:10 -08:00
  b4a53aef47
• Update full-auto description with on-request (#6523)

  This PR fixes #6522 by correcting the comment for `full-auto` in both
  `codex-rs/exec/src/cli.rs` and `codex-rs/tui/src/cli.rs` from `-a
  on-failure` to `-a on-request` to make it coherent with
  `codex-rs/tui/src/lib.rs:97-105`:
  
  ```rust
  pub async fn run_main(
      mut cli: Cli,
      codex_linux_sandbox_exe: Option<PathBuf>,
  ) -> std::io::Result<AppExitInfo> {
      let (sandbox_mode, approval_policy) = if cli.full_auto {
          (
              Some(SandboxMode::WorkspaceWrite),
              Some(AskForApproval::OnRequest),
          )
  ```
  
  Running `just codex --help` or `just codex exec --help` should now yield
  the correct description of `full-auto` CLI argument.
  
  Signed-off-by: lionelchg <lionel.cheng@hotmail.fr>

  Lionel Cheng · 2025-11-11 15:59:20 -08:00
  eb1c651c00
• Fix warning message phrasing (#6446)

  Small fix for sentence phrasing in the warning message
  
  Co-authored-by: AndrewNikolin <877163+AndrewNikolin@users.noreply.github.com>

  Andrew Nikolin · 2025-11-09 22:12:28 -08:00
  131c384361
• 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
• [exec] Add MCP tool arguments and results (#5899)

  Extends mcp_tool_call item to include arguments and results.

  pakrym-oai · 2025-10-29 14:23:57 -07:00
  815ae4164a
• 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
• feature: Add "!cmd" user shell execution (#2471)

  feature: Add "!cmd" user shell execution
  
  This change lets users run local shell commands directly from the TUI by
  prefixing their input with ! (e.g. !ls). Output is truncated to keep the
  exec cell usable, and Ctrl-C cleanly
    interrupts long-running commands (e.g. !sleep 10000).
  
  **Summary of changes**
  
  - Route Op::RunUserShellCommand through a dedicated UserShellCommandTask
  (core/src/tasks/user_shell.rs), keeping the task logic out of codex.rs.
  - Reuse the existing tool router: the task constructs a ToolCall for the
  local_shell tool and relies on ShellHandler, so no manual MCP tool
  lookup is required.
  - Emit exec lifecycle events (ExecCommandBegin/ExecCommandEnd) so the
  TUI can show command metadata, live output, and exit status.
  
  **End-to-end flow**
  
    **TUI handling**
  
  1. ChatWidget::submit_user_message (TUI) intercepts messages starting
  with !.
  2. Non-empty commands dispatch Op::RunUserShellCommand { command };
  empty commands surface a help hint.
  3. No UserInput items are created, so nothing is enqueued for the model.
  
    **Core submission loop**
  4. The submission loop routes the op to handlers::run_user_shell_command
  (core/src/codex.rs).
  5. A fresh TurnContext is created and Session::spawn_user_shell_command
  enqueues UserShellCommandTask.
  
    **Task execution**
  6. UserShellCommandTask::run emits TaskStartedEvent, formats the
  command, and prepares a ToolCall targeting local_shell.
    7. ToolCallRuntime::handle_tool_call dispatches to ShellHandler.
  
    **Shell tool runtime**
  8. ShellHandler::run_exec_like launches the process via the unified exec
  runtime, honoring sandbox and shell policies, and emits
  ExecCommandBegin/End.
  9. Stdout/stderr are captured for the UI, but the task does not turn the
  resulting ToolOutput into a model response.
  
    **Completion**
  10. After ExecCommandEnd, the task finishes without an assistant
  message; the session marks it complete and the exec cell displays the
  final output.
  
    **Conversation context**
  
  - The command and its output never enter the conversation history or the
  model prompt; the flow is local-only.
    - Only exec/task events are emitted for UI rendering.
  
  **Demo video**
  
  
  https://github.com/user-attachments/assets/fcd114b0-4304-4448-a367-a04c43e0b996

  Abhishek Bhardwaj · 2025-10-29 00:31:20 -07:00
  89591e4246
• Fixed bug that results in a sporadic hang when attaching images (#5891)

  Addresses https://github.com/openai/codex/issues/5773
  
  Testing: I tested that images work (regardless of order that they are
  associated with the task prompt) in both the CLI and Extension. Also
  verified that conversations in CLI and extension with images can be
  resumed.

  Eric Traut · 2025-10-28 14:42:46 -07:00
  ba95d9862c
• [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): clarify Windows auto mode requirements (#5568)

  ## Summary
  - Coerce Windows `workspace-write` configs back to read-only, surface
  the forced downgrade in the approvals popup,
    and funnel users toward WSL or Full Access.
  - Add WSL installation instructions to the Auto preset on Windows while
  keeping the preset available for other
    platforms.
  - Skip the trust-on-first-run prompt on native Windows so new folders
  remain read-only without additional
    confirmation.
  - Expose a structured sandbox policy resolution from config to flag
  Windows downgrades and adjust tests (core,
  exec, TUI) to reflect the new behavior; provide a Windows-only approvals
  snapshot.
  
    ## Testing
    - cargo fmt
  - cargo test -p codex-core
  config::tests::add_dir_override_extends_workspace_writable_roots
  - cargo test -p codex-exec
  suite::resume::exec_resume_preserves_cli_configuration_overrides
  - cargo test -p codex-tui
  chatwidget::tests::approvals_selection_popup_snapshot
  - cargo test -p codex-tui
  approvals_popup_includes_wsl_note_for_auto_mode
    - cargo test -p codex-tui windows_skips_trust_prompt
    - just fix -p codex-core
    - just fix -p codex-tui

  Josh McKinney · 2025-10-28 01:19:32 +00:00
  66a4b89822