63 Commits

• [tools] Add apply_patch tool (#2303)

  ## Summary
  We've been seeing a number of issues and reports with our synthetic
  `apply_patch` tool, e.g. #802. Let's make this a real tool - in my
  anecdotal testing, it's critical for GPT-OSS models, but I'd like to
  make it the standard across GPT-5 and codex models as well.
  
  ## Testing
  - [x] Tested locally
  - [x] Integration test

  Dylan · 2025-08-15 11:55:53 -04:00
  6df8e35314
• Added allow-expect-in-tests / allow-unwrap-in-tests (#2328)

  This PR:
  * Added the clippy.toml to configure allowable expect / unwrap usage in
  tests
  * Removed as many expect/allow lines as possible from tests
  * moved a bunch of allows to expects where possible
  
  Note: in integration tests, non `#[test]` helper functions are not
  covered by this so we had to leave a few lingering `expect(expect_used`
  checks around

  Parker Thompson · 2025-08-14 17:59:01 -07:00
  a075424437
• fix: change OPENAI_DEFAULT_MODEL to "gpt-5" (#1943)
  Michael Bolin · 2025-08-07 10:13:13 -07:00
  107d2ce4e7
• [config] Onboarding flow with persistence (#1929)

  ## Summary
  In collaboration with @gpeal: upgrade the onboarding flow, and persist
  user settings.
  
  ---------
  
  Co-authored-by: Gabriel Peal <gabriel@openai.com>

  Dylan · 2025-08-07 09:27:38 -07:00
  bc28b87c7b
• chore: fix outstanding review comments from the bot on #1919 (#1928)

  I should have read the comments before submitting!

  Michael Bolin · 2025-08-07 01:30:13 -07:00
  13982d6b4e
• feat: add /tmp by default (#1919)

  Replaces the `include_default_writable_roots` option on
  `sandbox_workspace_write` (that defaulted to `true`, which was slightly
  weird/annoying) with `exclude_tmpdir_env_var`, which defaults to
  `false`.
  
  Though perhaps more importantly `/tmp` is now enabled by default as part
  of `sandbox_mode = "workspace-write"`, though `exclude_slash_tmp =
  false` can be used to disable this.

  Michael Bolin · 2025-08-07 00:17:00 -07:00
  cd5f9074af
• Prefer env var auth over default codex auth (#1861)

  ## Summary
  - Prioritize provider-specific API keys over default Codex auth when
  building requests
  - Add test to ensure provider env var auth overrides default auth
  
  ## Testing
  - `just fmt`
  - `just fix` *(fails: `let` expressions in this position are unstable)*
  - `cargo test --all-features` *(fails: `let` expressions in this
  position are unstable)*
  
  ------
  https://chatgpt.com/codex/tasks/task_i_68926a104f7483208f2c8fd36763e0e3

  pakrym-oai · 2025-08-06 13:02:00 -07:00
  8262ba58b2
• fix: support $CODEX_HOME/AGENTS.md instead of $CODEX_HOME/instructions.md (#1891)

  The docs and code do not match. It turns out the docs are "right" in
  they are what we have been meaning to support, so this PR updates the
  code:
  
  
  https://github.com/openai/codex/blob/ae88b69b09f876a3017196a9cd66f83dac79d9d7/README.md#L298-L302
  
  Support for `instructions.md` is a holdover from the TypeScript CLI, so
  we are just going to drop support for it altogether rather than maintain
  it in perpetuity.

  Michael Bolin · 2025-08-06 11:48:03 -07:00
  64f2f2eca2
• chore: remove unnecessary default_ prefix (#1854)

  This prefix is not inline with the other fields on the `ConfigOverrides`
  struct.

  Michael Bolin · 2025-08-05 14:42:49 -07:00
  42bd73e150
• Introduce --oss flag to use gpt-oss models (#1848)

  This adds support for easily running Codex backed by a local Ollama
  instance running our new open source models. See
  https://github.com/openai/gpt-oss for details.
  
  If you pass in `--oss` you'll be prompted to install/launch ollama, and
  it will automatically download the 20b model and attempt to use it.
  
  We'll likely want to expand this with some options later to make the
  experience smoother for users who can't run the 20b or want to run the
  120b.
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  easong-openai · 2025-08-05 11:31:11 -07:00
  9285350842
• Rescue chat completion changes (#1846)

  https://github.com/openai/codex/pull/1835 has some messed up history.
  
  This adds support for streaming chat completions, which is useful for ollama. We should probably take a very skeptical eye to the code introduced in this PR.
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>

  easong-openai · 2025-08-05 08:56:13 +00:00
  e0303dbac0
• chore: introduce ModelFamily abstraction (#1838)

  To date, we have a number of hardcoded OpenAI model slug checks spread
  throughout the codebase, which makes it hard to audit the various
  special cases for each model. To mitigate this issue, this PR introduces
  the idea of a `ModelFamily` that has fields to represent the existing
  special cases, such as `supports_reasoning_summaries` and
  `uses_local_shell_tool`.
  
  There is a `find_family_for_model()` function that maps the raw model
  slug to a `ModelFamily`. This function hardcodes all the knowledge about
  the special attributes for each model. This PR then replaces the
  hardcoded model name checks with checks against a `ModelFamily`.
  
  Note `ModelFamily` is now available as `Config::model_family`. We should
  ultimately remove `Config::model` in favor of
  `Config::model_family::slug`.

  Michael Bolin · 2025-08-04 23:50:03 -07:00
  136b3ee5bf
• Revert to 3f13ebce10 without rewriting history. Wrong merge
  Ahmed Ibrahim · 2025-08-04 17:03:24 -07:00
  e38ce39c51
• unify flag
  Ahmed Ibrahim · 2025-08-04 16:56:52 -07:00
  1a33de34b0
• add raw reasoning
  Ahmed Ibrahim · 2025-08-04 16:49:42 -07:00
  bd171e5206
• feat: accept custom instructions in profiles (#1803)

  Allows users to set their experimental_instructions_file in configs.
  
  For example the below enables experimental instructions when running
  `codex -p foo`.
  ```
  [profiles.foo]
  experimental_instructions_file = "/Users/foo/.codex/prompt.md"
  ```
  
  # Testing
  - ✅ Running against a profile with experimental_instructions_file works.
  - ✅ Running against a profile without experimental_instructions_file
  works.
  - ✅ Running against no profile with experimental_instructions_file
  works.
  - ✅ Running against no profile without experimental_instructions_file
  works.

  ae · 2025-08-04 09:34:46 -07:00
  dc15a5cf0b
• chore: introduce SandboxPolicy::WorkspaceWrite::include_default_writable_roots (#1785)

  Without this change, it is challenging to create integration tests to
  verify that the folders not included in `writable_roots` in
  `SandboxPolicy::WorkspaceWrite` are read-only because, by default,
  `get_writable_roots_with_cwd()` includes `TMPDIR`, which is where most
  integrationt
  tests do their work.
  
  This introduces a `use_exact_writable_roots` option to disable the
  default
  includes returned by `get_writable_roots_with_cwd()`.
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1785).
  * #1765
  * __->__ #1785

  Michael Bolin · 2025-08-01 14:15:55 -07:00
  92f3566d78
• Add a custom originator setting (#1781)
  pakrym-oai · 2025-08-01 09:55:23 -07:00
  88ea215c80
• Add support for a separate chatgpt auth endpoint (#1712)

  Adds a `CodexAuth` type that encapsulates information about available
  auth modes and logic for refreshing the token.
  Changes `Responses` API to send requests to different endpoints based on
  the auth type.
  Updates login_with_chatgpt to support API-less mode and skip the key
  exchange.

  pakrym-oai · 2025-07-30 19:40:15 +00:00
  ea01a5ffe2
• Add an experimental plan tool (#1726)

  This adds a tool the model can call to update a plan. The tool doesn't
  actually _do_ anything but it gives clients a chance to read and render
  the structured plan. We will likely iterate on the prompt and tools
  exposed for planning over time.

  Gabriel Peal · 2025-07-29 14:22:02 -04:00
  8828f6f082
• Relative instruction file (#1722)

  Passing in an instruction file with a bad path led to silent failures,
  also instruction relative paths were handled in an unintuitive fashion.

  easong-openai · 2025-07-29 10:06:05 -07:00
  f8fcaaaf6f
• feat: support dotenv (including ~/.codex/.env) (#1653)

  This PR adds a `load_dotenv()` helper function to the `codex-common`
  crate that is available when the `cli` feature is enabled. The function
  uses [`dotenvy`](https://crates.io/crates/dotenvy) to update the
  environment from:
  
  - `$CODEX_HOME/.env`
  - `$(pwd)/.env`
  
  To test:
  
  - ran `printenv OPENAI_API_KEY` to verify the env var exists in my
  environment
  - ran `just codex exec hello` to verify the CLI uses my `OPENAI_API_KEY`
  - ran `unset OPENAI_API_KEY`
  - ran `just codex exec hello` again and got **ERROR: Missing environment
  variable: `OPENAI_API_KEY`**, as expected
  - created `~/.codex/.env` and added `OPENAI_API_KEY=sk-proj-...` (also
  ran `chmod 400 ~/.codex/.env` for good measure)
  - ran `just codex exec hello` again and it worked, verifying it picked
  up `OPENAI_API_KEY` from `~/.codex/.env`
  
  Note this functionality was available in the TypeScript CLI:
  https://github.com/openai/codex/pull/122 and was recently requested over
  on https://github.com/openai/codex/issues/1262#issuecomment-3093203551.

  Michael Bolin · 2025-07-22 15:54:33 -07:00
  d6c4083f98
• Add support for custom base instructions (#1645)

  Allows providing custom instructions file as a config parameter and
  custom instruction text via MCP tool call.

  pakrym-oai · 2025-07-22 09:42:22 -07:00
  6d82907082
• Add session loading support to Codex (#1602)

  ## Summary
  - extend rollout format to store all session data in JSON
  - add resume/write helpers for rollouts
  - track session state after each conversation
  - support `LoadSession` op to resume a previous rollout
  - allow starting Codex with an existing session via
  `experimental_resume` config variable
  
  We need a way later for exploring the available sessions in a user
  friendly way.
  
  ## Testing
  - `cargo test --no-run` *(fails: `cargo: command not found`)*
  
  ------
  https://chatgpt.com/codex/tasks/task_i_68792a29dd5c832190bf6930d3466fba
  
  This video is outdated. you should use `-c experimental_resume:<full
  path>` instead of `--resume <full path>`
  
  
  https://github.com/user-attachments/assets/7a9975c7-aa04-4f4e-899a-9e87defd947a

  aibrahim-oai · 2025-07-18 17:04:04 -07:00
  83eefb55fb
• Refactor env settings into config (#1601)

  ## Summary
  - add OpenAI retry and timeout fields to Config
  - inject these settings in tests instead of mutating env vars
  - plumb Config values through client and chat completions logic
  - document new configuration options
  
  ## Testing
  - `cargo test -p codex-core --no-run`
  
  ------
  https://chatgpt.com/codex/tasks/task_i_68792c5b04cc832195c03050c8b6ea94
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  aibrahim-oai · 2025-07-18 19:12:39 +00:00
  9846adeabf
• Add codex apply to apply a patch created from the Codex remote agent (#1528)

  In order to to this, I created a new `chatgpt` crate where we can put
  any code that interacts directly with ChatGPT as opposed to the OpenAI
  API. I added a disclaimer to the README for it that it should primarily
  be modified by OpenAI employees.
  
  
  https://github.com/user-attachments/assets/bb978e33-d2c9-4d8e-af28-c8c25b1988e8

  Gabriel Peal · 2025-07-11 13:30:11 -04:00
  bfeb8c92a5
• feat: add new config option: model_supports_reasoning_summaries (#1524)

  As noted in the updated docs, this makes it so that you can set:
  
  ```toml
  model_supports_reasoning_summaries = true
  ```
  
  as a way of overriding the existing heuristic for when to set the
  `reasoning` field on a sampling request:
  
  
  https://github.com/openai/codex/blob/341c091c5b09dc706ab5c7d629516e6ef5aaf902/codex-rs/core/src/client_common.rs#L152-L166

  Michael Bolin · 2025-07-10 14:30:33 -07:00
  8a424fcfa3
• feat: add reasoning fields to profile settings (#1484)
  Yusuf Eren · 2025-07-08 12:05:22 -07:00
  e444a50cf0
• feat: add support for --sandbox flag (#1476)

  On a high-level, we try to design `config.toml` so that you don't have
  to "comment out a lot of stuff" when testing different options.
  
  Previously, defining a sandbox policy was somewhat at odds with this
  principle because you would define the policy as attributes of
  `[sandbox]` like so:
  
  ```toml
  [sandbox]
  mode = "workspace-write"
  writable_roots = [ "/tmp" ]
  ```
  
  but if you wanted to temporarily change to a read-only sandbox, you
  might feel compelled to modify your file to be:
  
  ```toml
  [sandbox]
  mode = "read-only"
  # mode = "workspace-write"
  # writable_roots = [ "/tmp" ]
  ```
  
  Technically, commenting out `writable_roots` would not be strictly
  necessary, as `mode = "read-only"` would ignore `writable_roots`, but
  it's still a reasonable thing to do to keep things tidy.
  
  Currently, the various values for `mode` do not support that many
  attributes, so this is not that hard to maintain, but one could imagine
  this becoming more complex in the future.
  
  In this PR, we change Codex CLI so that it no longer recognizes
  `[sandbox]`. Instead, it introduces a top-level option, `sandbox_mode`,
  and `[sandbox_workspace_write]` is used to further configure the sandbox
  when when `sandbox_mode = "workspace-write"` is used:
  
  ```toml
  sandbox_mode = "workspace-write"
  
  [sandbox_workspace_write]
  writable_roots = [ "/tmp" ]
  ```
  
  This feels a bit more future-proof in that it is less tedious to
  configure different sandboxes:
  
  ```toml
  sandbox_mode = "workspace-write"
  
  [sandbox_read_only]
  # read-only options here...
  
  [sandbox_workspace_write]
  writable_roots = [ "/tmp" ]
  
  [sandbox_danger_full_access]
  # danger-full-access options here...
  ```
  
  In this scheme, you never need to comment out the configuration for an
  individual sandbox type: you only need to redefine `sandbox_mode`.
  
  Relatedly, previous to this change, a user had to do `-c
  sandbox.mode=read-only` to change the mode on the command line. With
  this change, things are arguably a bit cleaner because the equivalent
  option is `-c sandbox_mode=read-only` (and now `-c
  sandbox_workspace_write=...` can be set separately).
  
  Though more importantly, we introduce the `-s/--sandbox` option to the
  CLI, which maps directly to `sandbox_mode` in `config.toml`, making
  config override behavior easier to reason about. Moreover, as you can
  see in the updates to the various Markdown files, it is much easier to
  explain how to configure sandboxing when things like `--sandbox
  read-only` can be used as an example.
  
  Relatedly, this cleanup also made it straightforward to add support for
  a `sandbox` option for Codex when used as an MCP server (see the changes
  to `mcp-server/src/codex_tool_config.rs`).
  
  Fixes https://github.com/openai/codex/issues/1248.

  Michael Bolin · 2025-07-07 22:31:30 -07:00
  e0c08cea4f
• feat: support custom HTTP headers for model providers (#1473)

  This adds support for two new model provider config options:
  
  - `http_headers` for hardcoded (key, value) pairs
  - `env_http_headers` for headers whose values should be read from
  environment variables
  
  This also updates the built-in `openai` provider to use this feature to
  set the following headers:
  
  - `originator` => `codex_cli_rs`
  - `version` => [CLI version]
  - `OpenAI-Organization` => `OPENAI_ORGANIZATION` env var
  - `OpenAI-Project` => `OPENAI_PROJECT` env var
  
  for consistency with the TypeScript implementation:
  
  
  https://github.com/openai/codex/blob/bd5a9e8ba96c7d9c58ecaf5e61ec62d14ac6378d/codex-cli/src/utils/agent/agent-loop.ts#L321-L329
  
  While here, this also consolidates some logic that was duplicated across
  `client.rs` and `chat_completions.rs` by introducing
  `ModelProviderInfo.create_request_builder()`.
  
  Resolves https://github.com/openai/codex/discussions/1152

  Michael Bolin · 2025-07-07 13:09:16 -07:00
  c221eab0b5
• feat: add query_params option to ModelProviderInfo to support Azure (#1435)

  As discovered in https://github.com/openai/codex/issues/1365, the Azure
  provider needs to be able to specify `api-version` as a query param, so
  this PR introduces a generic `query_params` option to the
  `model_providers` config so that an Azure provider can be defined as
  follows:
  
  ```toml
  [model_providers.azure]
  name = "Azure"
  base_url = "https://YOUR_PROJECT_NAME.openai.azure.com/openai"
  env_key = "AZURE_OPENAI_API_KEY"
  query_params = { api-version = "2025-04-01-preview" }
  ```
  
  This PR also updates the docs with this example.
  
  While here, we also update `wire_api` to default to `"chat"`, as that is
  likely the common case for someone defining an external provider.
  
  Fixes https://github.com/openai/codex/issues/1365.

  Michael Bolin · 2025-06-30 11:39:54 -07:00
  6dad5c3b17
• feat: show number of tokens remaining in UI (#1388)

  When using the OpenAI Responses API, we now record the `usage` field for
  a `"response.completed"` event, which includes metrics about the number
  of tokens consumed. We also introduce `openai_model_info.rs`, which
  includes current data about the most common OpenAI models available via
  the API (specifically `context_window` and `max_output_tokens`). If
  Codex does not recognize the model, you can set `model_context_window`
  and `model_max_output_tokens` explicitly in `config.toml`.
  
  When then introduce a new event type to `protocol.rs`, `TokenCount`,
  which includes the `TokenUsage` for the most recent turn.
  
  Finally, we update the TUI to record the running sum of tokens used so
  the percentage of available context window remaining can be reported via
  the placeholder text for the composer:
  
  ![Screenshot 2025-06-25 at 11 20
  55 PM](https://github.com/user-attachments/assets/6fd6982f-7247-4f14-84b2-2e600cb1fd49)
  
  We could certainly get much fancier with this (such as reporting the
  estimated cost of the conversation), but for now, we are just trying to
  achieve feature parity with the TypeScript CLI.
  
  Though arguably this improves upon the TypeScript CLI, as the TypeScript
  CLI uses heuristics to estimate the number of tokens used rather than
  using the `usage` information directly:
  
  
  https://github.com/openai/codex/blob/296996d74e345b1b05d8c3451a06ace21c5ada96/codex-cli/src/utils/approximate-tokens-used.ts#L3-L16
  
  Fixes https://github.com/openai/codex/issues/1242

  Michael Bolin · 2025-06-25 23:31:11 -07:00
  fcfe43c7df
• chore: rename AskForApproval::UnlessAllowListed to AskForApproval::UnlessTrusted (#1385)

  We could just rename to `Untrusted` instead of `UnlessTrusted`, but I
  think `AskForApproval::UnlessTrusted` reads a bit better.

  Michael Bolin · 2025-06-25 12:26:13 -07:00
  72082164c1
• chore: rename unless-allow-listed to untrusted (#1378)

  For the `approval_policy` config option, renames `unless-allow-listed`
  to `untrusted`. In general, when it comes to exec'ing commands, I think
  "trusted" is a more accurate term than "safe."
  
  Also drops the `AskForApproval::AutoEdit` variant, as we were not really
  making use of it, anyway.
  
  Fixes https://github.com/openai/codex/issues/1250.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1378).
  * #1379
  * __->__ #1378

  Michael Bolin · 2025-06-24 22:19:21 -07:00
  86d5a9d80d
• feat: redesign sandbox config (#1373)

  This is a major redesign of how sandbox configuration works and aims to
  fix https://github.com/openai/codex/issues/1248. Specifically, it
  replaces `sandbox_permissions` in `config.toml` (and the
  `-s`/`--sandbox-permission` CLI flags) with a "table" with effectively
  three variants:
  
  ```toml
  # Safest option: full disk is read-only, but writes and network access are disallowed.
  [sandbox]
  mode = "read-only"
  
  # The cwd of the Codex task is writable, as well as $TMPDIR on macOS.
  # writable_roots can be used to specify additional writable folders.
  [sandbox]
  mode = "workspace-write"
  writable_roots = []  # Optional, defaults to the empty list.
  network_access = false  # Optional, defaults to false.
  
  # Disable sandboxing: use at your own risk!!!
  [sandbox]
  mode = "danger-full-access"
  ```
  
  This should make sandboxing easier to reason about. While we have
  dropped support for `-s`, the way it works now is:
  
  - no flags => `read-only`
  - `--full-auto` => `workspace-write`
  - currently, there is no way to specify `danger-full-access` via a CLI
  flag, but we will revisit that as part of
  https://github.com/openai/codex/issues/1254
  
  Outstanding issue:
  
  - As noted in the `TODO` on `SandboxPolicy::is_unrestricted()`, we are
  still conflating sandbox preferences with approval preferences in that
  case, which needs to be cleaned up.

  Michael Bolin · 2025-06-24 16:59:47 -07:00
  0776d78357
• feat: make reasoning effort/summaries configurable (#1199)

  Previous to this PR, we always set `reasoning` when making a request
  using the Responses API:
  
  
  https://github.com/openai/codex/blob/d7245cbbc9d8ff5446da45e5951761103492476d/codex-rs/core/src/client.rs#L108-L111
  
  Though if you tried to use the Rust CLI with `--model gpt-4.1`, this
  would fail with:
  
  ```shell
  "Unsupported parameter: 'reasoning.effort' is not supported with this model."
  ```
  
  We take a cue from the TypeScript CLI, which does a check on the model
  name:
  
  
  https://github.com/openai/codex/blob/d7245cbbc9d8ff5446da45e5951761103492476d/codex-cli/src/utils/agent/agent-loop.ts#L786-L789
  
  This PR does a similar check, though also adds support for the following
  config options:
  
  ```
  model_reasoning_effort = "low" | "medium" | "high" | "none"
  model_reasoning_summary = "auto" | "concise" | "detailed" | "none"
  ```
  
  This way, if you have a model whose name happens to start with `"o"` (or
  `"codex"`?), you can set these to `"none"` to explicitly disable
  reasoning, if necessary. (That said, it seems unlikely anyone would use
  the Responses API with non-OpenAI models, but we provide an escape
  hatch, anyway.)
  
  This PR also updates both the TUI and `codex exec` to show `reasoning
  effort` and `reasoning summaries` in the header.

  Michael Bolin · 2025-06-02 16:01:34 -07:00
  0f3cc8f842
• feat: add hide_agent_reasoning config option (#1181)

  This PR introduces a `hide_agent_reasoning` config option (that defaults
  to `false`) that users can enable to make the output less verbose by
  suppressing reasoning output.
  
  To test, verified that this includes agent reasoning in the output:
  
  ```
  echo hello | just exec
  ```
  
  whereas this does not:
  
  ```
  echo hello | just exec --config hide_agent_reasoning=false
  ```

  Michael Bolin · 2025-05-30 23:14:56 -07:00
  e81327e5f4
• feat: add support for -c/--config to override individual config items (#1137)

  This PR introduces support for `-c`/`--config` so users can override
  individual config values on the command line using `--config
  name=value`. Example:
  
  ```
  codex --config model=o4-mini
  ```
  
  Making it possible to set arbitrary config values on the command line
  results in a more flexible configuration scheme and makes it easier to
  provide single-line examples that can be copy-pasted from documentation.
  
  Effectively, it means there are four levels of configuration for some
  values:
  
  - Default value (e.g., `model` currently defaults to `o4-mini`)
  - Value in `config.toml` (e.g., user could override the default to be
  `model = "o3"` in their `config.toml`)
  - Specifying `-c` or `--config` to override `model` (e.g., user can
  include `-c model=o3` in their list of args to Codex)
  - If available, a config-specific flag can be used, which takes
  precedence over `-c` (e.g., user can specify `--model o3` in their list
  of args to Codex)
  
  Now that it is possible to specify anything that could be configured in
  `config.toml` on the command line using `-c`, we do not need to have a
  custom flag for every possible config option (which can clutter the
  output of `--help`). To that end, as part of this PR, we drop support
  for the `--disable-response-storage` flag, as users can now specify `-c
  disable_response_storage=true` to get the equivalent functionality.
  
  Under the hood, this works by loading the `config.toml` into a
  `toml::Value`. Then for each `key=value`, we create a small synthetic
  TOML file with `value` so that we can run the TOML parser to get the
  equivalent `toml::Value`. We then parse `key` to determine the point in
  the original `toml::Value` to do the insert/replace. Once all of the
  overrides from `-c` args have been applied, the `toml::Value` is
  deserialized into a `ConfigToml` and then the `ConfigOverrides` are
  applied, as before.

  Michael Bolin · 2025-05-27 23:11:44 -07:00
  d60f350cf8
• feat: add codex_linux_sandbox_exe: Option<PathBuf> field to Config (#1089)

  https://github.com/openai/codex/pull/1086 is a work-in-progress to make
  Linux sandboxing work more like Seatbelt where, for the command we want
  to sandbox, we build up the command and then hand it, and some sandbox
  configuration flags, to another command to set up the sandbox and then
  run it.
  
  In the case of Seatbelt, macOS provides this helper binary and provides
  it at `/usr/bin/sandbox-exec`. For Linux, we have to build our own and
  pass it through (which is what #1086 does), so this makes the new
  `codex_linux_sandbox_exe` available on `Config` so that it will later be
  available in `exec.rs` when we need it in #1086.

  Michael Bolin · 2025-05-22 21:52:28 -07:00
  d1de7bb383
• feat: introduce support for shell_environment_policy in config.toml (#1061)

  To date, when handling `shell` and `local_shell` tool calls, we were
  spawning new processes using the environment inherited from the Codex
  process itself. This means that the sensitive `OPENAI_API_KEY` that
  Codex needs to talk to OpenAI models was made available to everything
  run by `shell` and `local_shell`. While there are cases where that might
  be useful, it does not seem like a good default.
  
  This PR introduces a complex `shell_environment_policy` config option to
  control the `env` used with these tool calls. It is inevitably a bit
  complex so that it is possible to override individual components of the
  policy so without having to restate the entire thing.
  
  Details are in the updated `README.md` in this PR, but here is the
  relevant bit that explains the individual fields of
  `shell_environment_policy`:
  
  | Field | Type | Default | Description |
  | ------------------------- | -------------------------- | ------- |
  -----------------------------------------------------------------------------------------------------------------------------------------------
  |
  | `inherit` | string | `core` | Starting template for the
  environment:<br>`core` (`HOME`, `PATH`, `USER`, …), `all` (clone full
  parent env), or `none` (start empty). |
  | `ignore_default_excludes` | boolean | `false` | When `false`, Codex
  removes any var whose **name** contains `KEY`, `SECRET`, or `TOKEN`
  (case-insensitive) before other rules run. |
  | `exclude` | array&lt;string&gt; | `[]` | Case-insensitive glob
  patterns to drop after the default filter.<br>Examples: `"AWS_*"`,
  `"AZURE_*"`. |
  | `set` | table&lt;string,string&gt; | `{}` | Explicit key/value
  overrides or additions – always win over inherited values. |
  | `include_only` | array&lt;string&gt; | `[]` | If non-empty, a
  whitelist of patterns; only variables that match _one_ pattern survive
  the final step. (Generally used with `inherit = "all"`.) |
  
  
  In particular, note that the default is `inherit = "core"`, so:
  
  * if you have extra env variables that you want to inherit from the
  parent process, use `inherit = "all"` and then specify `include_only`
  * if you have extra env variables where you want to hardcode the values,
  the default `inherit = "core"` will work fine, but then you need to
  specify `set`
  
  This configuration is not battle-tested, so we will probably still have
  to play with it a bit. `core/src/exec_env.rs` has the critical business
  logic as well as unit tests.
  
  Though if nothing else, previous to this change:
  
  ```
  $ cargo run --bin codex -- debug seatbelt -- printenv OPENAI_API_KEY
  # ...prints OPENAI_API_KEY...
  ```
  
  But after this change it does not print anything (as desired).
  
  One final thing to call out about this PR is that the
  `configure_command!` macro we use in `core/src/exec.rs` has to do some
  complex logic with respect to how it builds up the `env` for the process
  being spawned under Landlock/seccomp. Specifically, doing
  `cmd.env_clear()` followed by `cmd.envs(&$env_map)` (which is arguably
  the most intuitive way to do it) caused the Landlock unit tests to fail
  because the processes spawned by the unit tests started failing in
  unexpected ways! If we forgo `env_clear()` in favor of updating env vars
  one at a time, the tests still pass. The comment in the code talks about
  this a bit, and while I would like to investigate this more, I need to
  move on for the moment, but I do plan to come back to it to fully
  understand what is going on. For example, this suggests that we might
  not be able to spawn a C program that calls `env_clear()`, which would
  be...weird. We may still have to fiddle with our Landlock config if that
  is the case.

  Michael Bolin · 2025-05-22 09:51:19 -07:00
  cb379d7797
• chore: move types out of config.rs into config_types.rs (#1054)

  `config.rs` is already quite long without these definitions. Since they
  have no real dependencies of their own, let's move them to their own
  file so `config.rs` can focus on the business logic of loading a config.

  Michael Bolin · 2025-05-20 11:55:25 -07:00
  5746561428
• feat: make it possible to toggle mouse mode in the Rust TUI (#971)

  I did a bit of research to understand why I could not use my mouse to
  drag to select text to copy to the clipboard in iTerm.
  
  Apparently https://github.com/openai/codex/pull/641 to enable mousewheel
  scrolling broke this functionality. It seems that, unless we put in a
  bit of effort, we can have drag-to-select or scrolling, but not both.
  Though if you know the trick to hold down `Option` will dragging with
  the mouse in iTerm, you can probably get by with this. (I did not know
  about this option prior to researching this issue.)
  
  Nevertheless, users may still prefer to disable mouse capture
  altogether, so this PR introduces:
  
  * the ability to set `tui.disable_mouse_capture = true` in `config.toml`
  to disable mouse capture
  * a new command, `/toggle-mouse-mode` to toggle mouse capture

  Michael Bolin · 2025-05-16 16:16:50 -07:00
  7ca84087e6
• feat: add support for file_opener option in Rust, similiar to #911 (#957)

  This ports the enhancement introduced in
  https://github.com/openai/codex/pull/911 (and the fixes in
  https://github.com/openai/codex/pull/919) for the TypeScript CLI to the
  Rust one.

  Michael Bolin · 2025-05-16 11:33:08 -07:00
  1e39189393
• feat: record messages from user in ~/.codex/history.jsonl (#939)

  This is a large change to support a "history" feature like you would
  expect in a shell like Bash.
  
  History events are recorded in `$CODEX_HOME/history.jsonl`. Because it
  is a JSONL file, it is straightforward to append new entries (as opposed
  to the TypeScript file that uses `$CODEX_HOME/history.json`, so to be
  valid JSON, each new entry entails rewriting the entire file). Because
  it is possible for there to be multiple instances of Codex CLI writing
  to `history.jsonl` at once, we use advisory file locking when working
  with `history.jsonl` in `codex-rs/core/src/message_history.rs`.
  
  Because we believe history is a sufficiently useful feature, we enable
  it by default. Though to provide some safety, we set the file
  permissions of `history.jsonl` to be `o600` so that other users on the
  system cannot read the user's history. We do not yet support a default
  list of `SENSITIVE_PATTERNS` as the TypeScript CLI does:
  
  
  https://github.com/openai/codex/blob/3fdf9df1335ac9501e3fb0e61715359145711e8b/codex-cli/src/utils/storage/command-history.ts#L10-L17
  
  We are going to take a more conservative approach to this list in the
  Rust CLI. For example, while `/\b[A-Za-z0-9-_]{20,}\b/` might exclude
  sensitive information like API tokens, it would also exclude valuable
  information such as references to Git commits.
  
  As noted in the updated documentation, users can opt-out of history by
  adding the following to `config.toml`:
  
  ```toml
  [history]
  persistence = "none" 
  ```
  
  Because `history.jsonl` could, in theory, be quite large, we take a[n
  arguably overly pedantic] approach in reading history entries into
  memory. Specifically, we start by telling the client the current number
  of entries in the history file (`history_entry_count`) as well as the
  inode (`history_log_id`) of `history.jsonl` (see the new fields on
  `SessionConfiguredEvent`).
  
  The client is responsible for keeping new entries in memory to create a
  "local history," but if the user hits up enough times to go "past" the
  end of local history, then the client should use the new
  `GetHistoryEntryRequest` in the protocol to fetch older entries.
  Specifically, it should pass the `history_log_id` it was given
  originally and work backwards from `history_entry_count`. (It should
  really fetch history in batches rather than one-at-a-time, but that is
  something we can improve upon in subsequent PRs.)
  
  The motivation behind this crazy scheme is that it is designed to defend
  against:
  
  * The `history.jsonl` being truncated during the session such that the
  index into the history is no longer consistent with what had been read
  up to that point. We do not yet have logic to enforce a `max_bytes` for
  `history.jsonl`, but once we do, we will aspire to implement it in a way
  that should result in a new inode for the file on most systems.
  * New items from concurrent Codex CLI sessions amending to the history.
  Because, in absence of truncation, `history.jsonl` is an append-only
  log, so long as the client reads backwards from `history_entry_count`,
  it should always get a consistent view of history. (That said, it will
  not be able to read _new_ commands from concurrent sessions, but perhaps
  we will introduce a `/` command to reload latest history or something
  down the road.)
  
  Admittedly, my testing of this feature thus far has been fairly light. I
  expect we will find bugs and introduce enhancements/fixes going forward.

  Michael Bolin · 2025-05-15 16:26:23 -07:00
  ce2ecbe72f
• chore: expose codex_home via Config (#941)
  Michael Bolin · 2025-05-15 00:30:13 -07:00
  5fc9fc3e3e
• feat: introduce --profile for Rust CLI (#921)

  This introduces a much-needed "profile" concept where users can specify
  a collection of options under one name and then pass that via
  `--profile` to the CLI.
  
  This PR introduces the `ConfigProfile` struct and makes it a field of
  `CargoToml`. It further updates
  `Config::load_from_base_config_with_overrides()` to respect
  `ConfigProfile`, overriding default values where appropriate. A detailed
  unit test is added at the end of `config.rs` to verify this behavior.
  
  Details on how to use this feature have also been added to
  `codex-rs/README.md`.

  Michael Bolin · 2025-05-13 16:52:52 -07:00
  3c03c25e56
• fix: agent instructions were not being included when ~/.codex/instructions.md was empty (#908)

  I had seen issues where `codex-rs` would not always write files without
  me pressuring it to do so, and between that and the report of
  https://github.com/openai/codex/issues/900, I decided to look into this
  further. I found two serious issues with agent instructions:
  
  (1) We were only sending agent instructions on the first turn, but
  looking at the TypeScript code, we should be sending them on every turn.
  
  (2) There was a serious issue where the agent instructions were
  frequently lost:
  
  * The TypeScript CLI appears to keep writing `~/.codex/instructions.md`:
  https://github.com/openai/codex/blob/55142e3e6caddd1e613b71bcb89385ce5cc708bf/codex-cli/src/utils/config.ts#L586
  * If `instructions.md` is present, the Rust CLI uses the contents of it
  INSTEAD OF the default prompt, even if `instructions.md` is empty:
  https://github.com/openai/codex/blob/55142e3e6caddd1e613b71bcb89385ce5cc708bf/codex-rs/core/src/config.rs#L202-L203
  
  The combination of these two things means that I have been using
  `codex-rs` without these key instructions:
  https://github.com/openai/codex/blob/main/codex-rs/core/prompt.md
  
  Looking at the TypeScript code, it appears we should be concatenating
  these three items every time (if they exist):
  
  * `prompt.md`
  * `~/.codex/instructions.md`
  * nearest `AGENTS.md`
  
  This PR fixes things so that:
  
  * `Config.instructions` is `None` if `instructions.md` is empty
  * `Payload.instructions` is now `&'a str` instead of `Option<&'a
  String>` because we should always have _something_ to send
  * `Prompt` now has a `get_full_instructions()` helper that returns a
  `Cow<str>` that will always include the agent instructions first.

  Michael Bolin · 2025-05-12 17:24:44 -07:00
  61b881d4e5
• Disallow expect via lints (#865)

  Adds `expect()` as a denied lint. Same deal applies with `unwrap()`
  where we now need to put `#[expect(...` on ones that we legit want. Took
  care to enable `expect()` in test contexts.
  
  # Tests
  
  ```
  cargo fmt
  cargo clippy --all-features --all-targets --no-deps -- -D warnings
  cargo test
  ```

  jcoens-openai · 2025-05-12 08:45:46 -07:00
  f3bd143867
• feat: add support for AGENTS.md in Rust CLI (#885)

  The TypeScript CLI already has support for including the contents of
  `AGENTS.md` in the instructions sent with the first turn of a
  conversation. This PR brings this functionality to the Rust CLI.
  
  To be considered, `AGENTS.md` must be in the `cwd` of the session, or in
  one of the parent folders up to a Git/filesystem root (whichever is
  encountered first).
  
  By default, a maximum of 32 KiB of `AGENTS.md` will be included, though
  this is configurable using the new-in-this-PR `project_doc_max_bytes`
  option in `config.toml`.

  Michael Bolin · 2025-05-10 17:52:59 -07:00
  2b122da087
• feat: support the chat completions API in the Rust CLI (#862)

  This is a substantial PR to add support for the chat completions API,
  which in turn makes it possible to use non-OpenAI model providers (just
  like in the TypeScript CLI):
  
  * It moves a number of structs from `client.rs` to `client_common.rs` so
  they can be shared.
  * It introduces support for the chat completions API in
  `chat_completions.rs`.
  * It updates `ModelProviderInfo` so that `env_key` is `Option<String>`
  instead of `String` (for e.g., ollama) and adds a `wire_api` field
  * It updates `client.rs` to choose between `stream_responses()` and
  `stream_chat_completions()` based on the `wire_api` for the
  `ModelProviderInfo`
  * It updates the `exec` and TUI CLIs to no longer fail if the
  `OPENAI_API_KEY` environment variable is not set
  * It updates the TUI so that `EventMsg::Error` is displayed more
  prominently when it occurs, particularly now that it is important to
  alert users to the `CodexErr::EnvVar` variant.
  * `CodexErr::EnvVar` was updated to include an optional `instructions`
  field so we can preserve the behavior where we direct users to
  https://platform.openai.com if `OPENAI_API_KEY` is not set.
  * Cleaned up the "welcome message" in the TUI to ensure the model
  provider is displayed.
  * Updated the docs in `codex-rs/README.md`.
  
  To exercise the chat completions API from OpenAI models, I added the
  following to my `config.toml`:
  
  ```toml
  model = "gpt-4o"
  model_provider = "openai-chat-completions"
  
  [model_providers.openai-chat-completions]
  name = "OpenAI using Chat Completions"
  base_url = "https://api.openai.com/v1"
  env_key = "OPENAI_API_KEY"
  wire_api = "chat"
  ```
  
  Though to test a non-OpenAI provider, I installed ollama with mistral
  locally on my Mac because ChatGPT said that would be a good match for my
  hardware:
  
  ```shell
  brew install ollama
  ollama serve
  ollama pull mistral
  ```
  
  Then I added the following to my `~/.codex/config.toml`:
  
  ```toml
  model = "mistral"
  model_provider = "ollama"
  ```
  
  Note this code could certainly use more test coverage, but I want to get
  this in so folks can start playing with it.
  
  For reference, I believe https://github.com/openai/codex/pull/247 was
  roughly the comparable PR on the TypeScript side.

  Michael Bolin · 2025-05-08 21:46:06 -07:00
  e924070cee