48 Commits

• 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
• Revert to 3f13ebce10 without rewriting history. Wrong merge
  Ahmed Ibrahim · 2025-08-04 17:03:24 -07:00
  e38ce39c51
• add raw reasoning
  Ahmed Ibrahim · 2025-08-04 16:49:42 -07:00
  bd171e5206
• Add a TurnDiffTracker to create a unified diff for an entire turn (#1770)

  This lets us show an accumulating diff across all patches in a turn.
  Refer to the docs for TurnDiffTracker for implementation details.
  
  There are multiple ways this could have been done and this felt like the
  right tradeoff between reliability and completeness:
  *Pros*
  * It will pick up all changes to files that the model touched including
  if they prettier or another command that updates them.
  * It will not pick up changes made by the user or other agents to files
  it didn't modify.
  
  *Cons*
  * It will pick up changes that the user made to a file that the model
  also touched
  * It will not pick up changes to codegen or files that were not modified
  with apply_patch

  Gabriel Peal · 2025-08-04 11:57:04 -04:00
  1f3318c1c5
• fix command duration display (#1806)

  we were always displaying "0ms" before.
  
  <img width="731" height="101" alt="Screenshot 2025-08-02 at 10 51 22 PM"
  src="https://github.com/user-attachments/assets/f56814ed-b9a4-4164-9e78-181c60ce19b7"
  />

  Jeremy Rose · 2025-08-03 11:33:44 -07:00
  78a1d49fac
• feat: make .git read-only within a writable root when using Seatbelt (#1765)

  To make `--full-auto` safer, this PR updates the Seatbelt policy so that
  a `SandboxPolicy` with a `writable_root` that contains a `.git/`
  _directory_ will make `.git/` _read-only_ (though as a follow-up, we
  should also consider the case where `.git` is a _file_ with a `gitdir:
  /path/to/actual/repo/.git` entry that should also be protected).
  
  The two major changes in this PR:
  
  - Updating `SandboxPolicy::get_writable_roots_with_cwd()` to return a
  `Vec<WritableRoot>` instead of a `Vec<PathBuf>` where a `WritableRoot`
  can specify a list of read-only subpaths.
  - Updating `create_seatbelt_command_args()` to honor the read-only
  subpaths in `WritableRoot`.
  
  The logic to update the policy is a fairly straightforward update to
  `create_seatbelt_command_args()`, but perhaps the more interesting part
  of this PR is the introduction of an integration test in
  `tests/sandbox.rs`. Leveraging the new API in #1785, we test
  `SandboxPolicy` under various conditions, including ones where `$TMPDIR`
  is not readable, which is critical for verifying the new behavior.
  
  To ensure that Codex can run its own tests, e.g.:
  
  ```
  just codex debug seatbelt --full-auto -- cargo test if_git_repo_is_writable_root_then_dot_git_folder_is_read_only
  ```
  
  I had to introduce the use of `CODEX_SANDBOX=sandbox`, which is
  comparable to how `CODEX_SANDBOX_NETWORK_DISABLED=1` was already being
  used.
  
  Adding a comparable change for Landlock will be done in a subsequent PR.

  Michael Bolin · 2025-08-01 16:11:24 -07:00
  80555d4ff2
• 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
• collabse stdout and stderr delta events into one (#1787)
  aibrahim-oai · 2025-08-01 14:00:19 -07:00
  f20de21cb6
• feat: stream exec stdout events (#1786)

  ## Summary
  - stream command stdout as `ExecCommandStdout` events
  - forward streamed stdout to clients and ignore in human output
  processor
  - adjust call sites for new streaming API

  aibrahim-oai · 2025-08-01 13:04:34 -07:00
  bc7beddaa2
• Add /compact (#1527)

  - Add operation to summarize the context so far.
  - The operation runs a compact task that summarizes the context.
  - The operation clear the previous context to free the context window
  - The operation didn't use `run_task` to avoid corrupting the session
  - Add /compact in the tui
  
  
  
  https://github.com/user-attachments/assets/e06c24e5-dcfb-4806-934a-564d425a919c

  aibrahim-oai · 2025-07-31 21:34:32 -07:00
  e2c994e32a
• remove conversation history widget (#1727)

  this widget is no longer used.

  Jeremy Rose · 2025-07-30 10:05:40 -07:00
  347c81ad00
• 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
• Serializing the eventmsg type to snake_case (#1709)

  This was an abrupt change on our clients. We need to serialize as
  snake_case.

  aibrahim-oai · 2025-07-28 10:26:27 -07:00
  19bef7659f
• Changing method in MCP notifications (#1684)

  - Changing the codex/event type

  aibrahim-oai · 2025-07-26 10:35:49 -07:00
  5a0079fea2
• Easily Selectable History (#1672)

  This update replaces the previous ratatui history widget with an
  append-only log so that the terminal can handle text selection and
  scrolling. It also disables streaming responses, which we'll do our best
  to bring back in a later PR. It also adds a small summary of token use
  after the TUI exits.

  easong-openai · 2025-07-25 01:56:40 -07:00
  480e82b00d
• Update render name in tui for approval_policy to match with config values (#1675)

  Currently, codex on start shows the value for the approval policy as
  name of
  [AskForApproval](https://github.com/openai/codex/blob/2437a8d17a0cf972d1a6e7f303d469b6e2f57eae/codex-rs/core/src/protocol.rs#L128)
  enum, which differs from
  [approval_policy](https://github.com/openai/codex/blob/2437a8d17a0cf972d1a6e7f303d469b6e2f57eae/codex-rs/config.md#approval_policy)
  config values.
  E.g. "untrusted" becomes "UnlessTrusted", "on-failure" -> "OnFailure",
  "never" -> "Never".
  This PR changes render names of the approval policy to match with
  configuration values.

  Pavel Bezglasny · 2025-07-24 14:17:57 -07:00
  508abbe990
• Flaky CI fix (#1647)

  Flushing before sending `TaskCompleteEvent` and ending the submission
  loop to avoid race conditions.

  aibrahim-oai · 2025-07-23 15:03:26 -07:00
  b4ab7c1b73
• Add call_id to patch approvals and elicitations (#1660)

  Builds on https://github.com/openai/codex/pull/1659 and adds call_id to
  a few more places for the same reason.

  Gabriel Peal · 2025-07-23 15:55:35 -04:00
  084236f717
• Improve messages emitted for exec failures (#1659)

  1. Emit call_id to exec approval elicitations for mcp client convenience
  2. Remove the `-retry` from the call id for the same reason as above but
  upstream the reset behavior to the mcp client

  Gabriel Peal · 2025-07-23 14:43:53 -04:00
  bc944e77f5
• 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
• support deltas in core (#1587)

  - Added support for message and reasoning deltas
  - Skipped adding the support in the cli and tui for later
  - Commented a failing test (wrong merge) that needs fix in a separate
  PR.
  
  Side note: I think we need to disable merge when the CI don't pass.

  aibrahim-oai · 2025-07-16 15:11:18 -07:00
  2bd3314886
• 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
• feat: add --dangerously-bypass-approvals-and-sandbox (#1384)

  This PR reworks `assess_command_safety()` so that the combination of
  `AskForApproval::Never` and `SandboxPolicy::DangerFullAccess` ensures
  that commands are run without _any_ sandbox and the user should never be
  prompted. In turn, it adds support for a new
  `--dangerously-bypass-approvals-and-sandbox` flag (that cannot be used
  with `--approval-policy` or `--full-auto`) that sets both of those
  options.
  
  Fixes https://github.com/openai/codex/issues/1254

  Michael Bolin · 2025-06-25 12:36:10 -07:00
  50924101d2
• 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
• fix: pretty-print the sandbox config in the TUI/exec modes (#1376)

  Now that https://github.com/openai/codex/pull/1373 simplified the
  sandbox config, we can print something much simpler in the TUI (and in
  `codex exec`) to summarize the sandbox config.
  
  Before:
  
  ![Screenshot 2025-06-24 at 5 45
  52 PM](https://github.com/user-attachments/assets/b7633efb-a619-43e1-9abe-7bb0be2d0ec0)
  
  With this change:
  
  ![Screenshot 2025-06-24 at 5 46
  44 PM](https://github.com/user-attachments/assets/8d099bdd-a429-4796-a08d-70931d984e4f)
  
  For reference, my `config.toml` contains:
  
  ```
  [sandbox]
  mode = "workspace-write"
  writable_roots = ["/tmp", "/Users/mbolin/.pyenv/shims"]
  ```
  
  Fixes https://github.com/openai/codex/issues/1248

  Michael Bolin · 2025-06-24 17:48:51 -07:00
  531ce7626f
• 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
• fix(codex-rs): use codex-mini-latest as default (#1164)
  Fouad Matin · 2025-05-29 16:55:19 -07:00
  828e2062c2
• fix: introduce ResponseInputItem::McpToolCallOutput variant (#1151)

  The output of an MCP server tool call can be one of several types, but
  to date, we treated all outputs as text by showing the serialized JSON
  as the "tool output" in Codex:
  
  
  https://github.com/openai/codex/blob/25a9949c49194d5a64de54a11bcc5b4724ac9bd5/codex-rs/mcp-types/src/lib.rs#L96-L101
  
  This PR adds support for the `ImageContent` variant so we can now
  display an image output from an MCP tool call.
  
  In making this change, we introduce a new
  `ResponseInputItem::McpToolCallOutput` variant so that we can work with
  the `mcp_types::CallToolResult` directly when the function call is made
  to an MCP server.
  
  Though arguably the more significant change is the introduction of
  `HistoryCell::CompletedMcpToolCallWithImageOutput`, which is a cell that
  uses `ratatui_image` to render an image into the terminal. To support
  this, we introduce `ImageRenderCache`, cache a
  `ratatui_image::picker::Picker`, and `ensure_image_cache()` to cache the
  appropriate scaled image data and dimensions based on the current
  terminal size.
  
  To test, I created a minimal `package.json`:
  
  ```json
  {
    "name": "kitty-mcp",
    "version": "1.0.0",
    "type": "module",
    "description": "MCP that returns image of kitty",
    "main": "index.js",
    "dependencies": {
      "@modelcontextprotocol/sdk": "^1.12.0"
    }
  }
  ```
  
  with the following `index.js` to define the MCP server:
  
  ```js
  #!/usr/bin/env node
  
  import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
  import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
  import { readFile } from "node:fs/promises";
  import { join } from "node:path";
  
  const IMAGE_URI = "image://Ada.png";
  
  const server = new McpServer({
    name: "Demo",
    version: "1.0.0",
  });
  
  server.tool(
    "get-cat-image",
    "If you need a cat image, this tool will provide one.",
    async () => ({
      content: [
        { type: "image", data: await getAdaPngBase64(), mimeType: "image/png" },
      ],
    })
  );
  
  server.resource("Ada the Cat", IMAGE_URI, async (uri) => {
    const base64Image = await getAdaPngBase64();
    return {
      contents: [
        {
          uri: uri.href,
          mimeType: "image/png",
          blob: base64Image,
        },
      ],
    };
  });
  
  async function getAdaPngBase64() {
    const __dirname = new URL(".", import.meta.url).pathname;
    // From https://github.com/benjajaja/ratatui-image/blob/9705ce2c59ec669abbce2924cbfd1f5ae22c9860/assets/Ada.png
    const filePath = join(__dirname, "Ada.png");
    const imageData = await readFile(filePath);
    const base64Image = imageData.toString("base64");
    return base64Image;
  }
  
  const transport = new StdioServerTransport();
  await server.connect(transport);
  ```
  
  With the local changes from this PR, I added the following to my
  `config.toml`:
  
  ```toml
  [mcp_servers.kitty]
  command = "node"
  args = ["/Users/mbolin/code/kitty-mcp/index.js"]
  ```
  
  Running the TUI from source:
  
  ```
  cargo run --bin codex -- --model o3 'I need a picture of a cat'
  ```
  
  I get:
  
  <img width="732" alt="image"
  src="https://github.com/user-attachments/assets/bf80b721-9ca0-4d81-aec7-77d6899e2869"
  />
  
  Now, that said, I have only tested in iTerm and there is definitely some
  funny business with getting an accurate character-to-pixel ratio
  (sometimes the `CompletedMcpToolCallWithImageOutput` thinks it needs 10
  rows to render instead of 4), so there is still work to be done here.

  Michael Bolin · 2025-05-28 19:03:17 -07:00
  a768a6a41d
• feat: experimental --output-last-message flag to exec subcommand (#1037)

  This introduces an experimental `--output-last-message` flag that can be
  used to identify a file where the final message from the agent will be
  written. Two use cases:
  
  - Ultimately, we will likely add a `--quiet` option to `exec`, but even
  if the user does not want any output written to the terminal, they
  probably want to know what the agent did. Writing the output to a file
  makes it possible to get that information in a clean way.
  - Relatedly, when using `exec` in CI, it is easier to review the
  transcript written "normally," (i.e., not as JSON or something with
  extra escapes), but getting programmatic access to the last message is
  likely helpful, so writing the last message to a file gets the best of
  both worlds.
  
  I am calling this "experimental" because it is possible that we are
  overfitting and will want a more general solution to this problem that
  would justify removing this flag.

  Michael Bolin · 2025-05-19 16:08:18 -07:00
  d766e845b3
• 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: handle all cases for EventMsg (#936)

  For now, this removes the `#[non_exhaustive]` directive on `EventMsg` so
  that we are forced to handle all `EventMsg` by default. (We may revisit
  this if/when we publish `core/` as a `lib` crate.) For now, it is
  helpful to have this as a forcing function because we have effectively
  two UIs (`tui` and `exec`) and usually when we add a new variant to
  `EventMsg`, we want to be sure that we update both.

  Michael Bolin · 2025-05-14 13:36:43 -07:00
  34aa1991f1
• fix: change EventMsg enum so every variant takes a single struct (#925)

  https://github.com/openai/codex/pull/922 did this for the
  `SessionConfigured` enum variant, and I think it is generally helpful to
  be able to work with the values as each enum variant as their own type,
  so this converts the remaining variants and updates all of the
  callsites.
  
  Added a simple unit test to verify that the JSON-serialized version of
  `Event` does not have any unexpected nesting.

  Michael Bolin · 2025-05-13 20:44:42 -07:00
  a5f3a34827
• fix: tighten up some logic around session timestamps and ids (#922)

  * update `SessionConfigured` event to include the UUID for the session
  * show the UUID in the Rust TUI
  * use local timestamps in log files instead of UTC
  * include timestamps in log file names for easier discovery

  Michael Bolin · 2025-05-13 19:22:16 -07:00
  e6c206d19d
• feat: include "reasoning" messages in Rust TUI (#892)

  As shown in the screenshot, we now include reasoning messages from the
  model in the TUI under the heading "codex reasoning":
  
  
  ![image](https://github.com/user-attachments/assets/d8eb3dc3-2f9f-4e95-847e-d24b421249a8)
  
  To ensure these are visible by default when using `o4-mini`, this also
  changes the default value for `summary` (formerly `generate_summary`,
  which is deprecated in favor of `summary` according to the docs) from
  unset to `"auto"`.

  Michael Bolin · 2025-05-10 21:43:27 -07:00
  b4785b5f88
• 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
• feat: read model_provider and model_providers from config.toml (#853)

  This is the first step in supporting other model providers in the Rust
  CLI. Specifically, this PR adds support for the new entries in `Config`
  and `ConfigOverrides` to specify a `ModelProviderInfo`, which is the
  basic config needed for an LLM provider. This PR does not get us all the
  way there yet because `client.rs` still categorically appends
  `/responses` to the URL and expects the endpoint to support the OpenAI
  Responses API. Will fix that next!

  Michael Bolin · 2025-05-07 17:38:28 -07:00
  86022f097e
• feat: support mcp_servers in config.toml (#829)

  This adds initial support for MCP servers in the style of Claude Desktop
  and Cursor. Note this PR is the bare minimum to get things working end
  to end: all configured MCP servers are launched every time Codex is run,
  there is no recovery for MCP servers that crash, etc.
  
  (Also, I took some shortcuts to change some fields of `Session` to be
  `pub(crate)`, which also means there are circular deps between
  `codex.rs` and `mcp_tool_call.rs`, but I will clean that up in a
  subsequent PR.)
  
  `codex-rs/README.md` is updated as part of this PR to explain how to use
  this feature. There is a bit of plumbing to route the new settings from
  `Config` to the business logic in `codex.rs`. The most significant
  chunks for new code are in `mcp_connection_manager.rs` (which defines
  the `McpConnectionManager` struct) and `mcp_tool_call.rs`, which is
  responsible for tool calls.
  
  This PR also introduces new `McpToolCallBegin` and `McpToolCallEnd`
  event types to the protocol, but does not add any handlers for them.
  (See https://github.com/openai/codex/pull/836 for initial usage.)
  
  To test, I added the following to my `~/.codex/config.toml`:
  
  ```toml
  # Local build of https://github.com/hideya/mcp-server-weather-js
  [mcp_servers.weather]
  command = "/Users/mbolin/code/mcp-server-weather-js/dist/index.js"
  args = []
  ```
  
  And then I ran the following:
  
  ```
  codex-rs$ cargo run --bin codex exec 'what is the weather in san francisco'
  [2025-05-06T22:40:05] Task started: 1
  [2025-05-06T22:40:18] Agent message: Here’s the latest National Weather Service forecast for San Francisco (downtown, near 37.77° N, 122.42° W):
  
  This Afternoon (Tue):
  • Sunny, high near 69 °F
  • West-southwest wind around 12 mph
  
  Tonight:
  • Partly cloudy, low around 52 °F
  • SW wind 7–10 mph
  ...
  ```
  
  Note that Codex itself is not able to make network calls, so it would
  not normally be able to get live weather information like this. However,
  the weather MCP is [currently] not run under the Codex sandbox, so it is
  able to hit `api.weather.gov` and fetch current weather information.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/829).
  * #836
  * __->__ #829

  Michael Bolin · 2025-05-06 15:47:59 -07:00
  147a940449
• feat: make cwd a required field of Config so we stop assuming std::env::current_dir() in a session (#800)

  In order to expose Codex via an MCP server, I realized that we should be
  taking `cwd` as a parameter rather than assuming
  `std::env::current_dir()` as the `cwd`. Specifically, the user may want
  to start a session in a directory other than the one where the MCP
  server has been started.
  
  This PR makes `cwd: PathBuf` a required field of `Session` and threads
  it all the way through, though I think there is still an issue with not
  honoring `workdir` for `apply_patch`, which is something we also had to
  fix in the TypeScript version: https://github.com/openai/codex/pull/556.
  
  This also adds `-C`/`--cd` to change the cwd via the command line.
  
  To test, I ran:
  
  ```
  cargo run --bin codex -- exec -C /tmp 'show the output of ls'
  ```
  
  and verified it showed the contents of my `/tmp` folder instead of
  `$PWD`.

  Michael Bolin · 2025-05-04 10:57:12 -07:00
  421e159888
• feat: configurable notifications in the Rust CLI (#793)

  With this change, you can specify a program that will be executed to get
  notified about events generated by Codex. The notification info will be
  packaged as a JSON object. The supported notification types are defined
  by the `UserNotification` enum introduced in this PR. Initially, it
  contains only one variant, `AgentTurnComplete`:
  
  ```rust
  pub(crate) enum UserNotification {
      #[serde(rename_all = "kebab-case")]
      AgentTurnComplete {
          turn_id: String,
  
          /// Messages that the user sent to the agent to initiate the turn.
          input_messages: Vec<String>,
  
          /// The last message sent by the assistant in the turn.
          last_assistant_message: Option<String>,
      },
  }
  ```
  
  This is intended to support the common case when a "turn" ends, which
  often means it is now your chance to give Codex further instructions.
  
  For example, I have the following in my `~/.codex/config.toml`:
  
  ```toml
  notify = ["python3", "/Users/mbolin/.codex/notify.py"]
  ```
  
  I created my own custom notifier script that calls out to
  [terminal-notifier](https://github.com/julienXX/terminal-notifier) to
  show a desktop push notification on macOS. Contents of `notify.py`:
  
  ```python
  #!/usr/bin/env python3
  
  import json
  import subprocess
  import sys
  
  
  def main() -> int:
      if len(sys.argv) != 2:
          print("Usage: notify.py <NOTIFICATION_JSON>")
          return 1
  
      try:
          notification = json.loads(sys.argv[1])
      except json.JSONDecodeError:
          return 1
  
      match notification_type := notification.get("type"):
          case "agent-turn-complete":
              assistant_message = notification.get("last-assistant-message")
              if assistant_message:
                  title = f"Codex: {assistant_message}"
              else:
                  title = "Codex: Turn Complete!"
              input_messages = notification.get("input_messages", [])
              message = " ".join(input_messages)
              title += message
          case _:
              print(f"not sending a push notification for: {notification_type}")
              return 0
  
      subprocess.check_output(
          [
              "terminal-notifier",
              "-title",
              title,
              "-message",
              message,
              "-group",
              "codex",
              "-ignoreDnD",
              "-activate",
              "com.googlecode.iterm2",
          ]
      )
  
      return 0
  
  
  if __name__ == "__main__":
      sys.exit(main())
  ```
  
  For reference, here are related PRs that tried to add this functionality
  to the TypeScript version of the Codex CLI:
  
  * https://github.com/openai/codex/pull/160
  * https://github.com/openai/codex/pull/498

  Michael Bolin · 2025-05-02 19:48:13 -07:00
  a180ed44e8
• feat: bring back -s option to specify sandbox permissions (#739)
  Michael Bolin · 2025-04-29 18:42:52 -07:00
  27bc4516bf
• fix: overhaul SandboxPolicy and config loading in Rust (#732)

  Previous to this PR, `SandboxPolicy` was a bit difficult to work with:
  
  
  https://github.com/openai/codex/blob/237f8a11e11fdcc793a09e787e48215676d9b95b/codex-rs/core/src/protocol.rs#L98-L108
  
  Specifically:
  
  * It was an `enum` and therefore options were mutually exclusive as
  opposed to additive.
  * It defined things in terms of what the agent _could not_ do as opposed
  to what they _could_ do. This made things hard to support because we
  would prefer to build up a sandbox config by starting with something
  extremely restrictive and only granting permissions for things the user
  as explicitly allowed.
  
  This PR changes things substantially by redefining the policy in terms
  of two concepts:
  
  * A `SandboxPermission` enum that defines permissions that can be
  granted to the agent/sandbox.
  * A `SandboxPolicy` that internally stores a `Vec<SandboxPermission>`,
  but externally exposes a simpler API that can be used to configure
  Seatbelt/Landlock.
  
  Previous to this PR, we supported a `--sandbox` flag that effectively
  mapped to an enum value in `SandboxPolicy`. Though now that
  `SandboxPolicy` is a wrapper around `Vec<SandboxPermission>`, the single
  `--sandbox` flag no longer makes sense. While I could have turned it
  into a flag that the user can specify multiple times, I think the
  current values to use with such a flag are long and potentially messy,
  so for the moment, I have dropped support for `--sandbox` altogether and
  we can bring it back once we have figured out the naming thing.
  
  Since `--sandbox` is gone, users now have to specify `--full-auto` to
  get a sandbox that allows writes in `cwd`. Admittedly, there is no clean
  way to specify the equivalent of `--full-auto` in your `config.toml`
  right now, so we will have to revisit that, as well.
  
  Because `Config` presents a `SandboxPolicy` field and `SandboxPolicy`
  changed considerably, I had to overhaul how config loading works, as
  well. There are now two distinct concepts, `ConfigToml` and `Config`:
  
  * `ConfigToml` is the deserialization of `~/.codex/config.toml`. As one
  might expect, every field is `Optional` and it is `#[derive(Deserialize,
  Default)]`. Consistent use of `Optional` makes it clear what the user
  has specified explicitly.
  * `Config` is the "normalized config" and is produced by merging
  `ConfigToml` with `ConfigOverrides`. Where `ConfigToml` contains a raw
  `Option<Vec<SandboxPermission>>`, `Config` presents only the final
  `SandboxPolicy`.
  
  The changes to `core/src/exec.rs` and `core/src/linux.rs` merit extra
  special attention to ensure we are faithfully mapping the
  `SandboxPolicy` to the Seatbelt and Landlock configs, respectively.
  
  Also, take note that `core/src/seatbelt_readonly_policy.sbpl` has been
  renamed to `codex-rs/core/src/seatbelt_base_policy.sbpl` and that
  `(allow file-read*)` has been removed from the `.sbpl` file as now this
  is added to the policy in `core/src/exec.rs` when
  `sandbox_policy.has_full_disk_read_access()` is `true`.

  Michael Bolin · 2025-04-29 15:01:16 -07:00
  0a00b5ed29
• feat: load defaults into Config and introduce ConfigOverrides (#677)

  This changes how instantiating `Config` works and also adds
  `approval_policy` and `sandbox_policy` as fields. The idea is:
  
  * All fields of `Config` have appropriate default values.
  * `Config` is initially loaded from `~/.codex/config.toml`, so values in
  `config.toml` will override those defaults.
  * Clients must instantiate `Config` via
  `Config::load_with_overrides(ConfigOverrides)` where `ConfigOverrides`
  has optional overrides that are expected to be settable based on CLI
  flags.
  
  The `Config` should be defined early in the program and then passed
  down. Now functions like `init_codex()` take fewer individual parameters
  because they can just take a `Config`.
  
  Also, `Config::load()` used to fail silently if `~/.codex/config.toml`
  had a parse error and fell back to the default config. This seemed
  really bad because it wasn't clear why the values in my `config.toml`
  weren't getting picked up. I changed things so that
  `load_with_overrides()` returns `Result<Config>` and verified that the
  various CLIs print a reasonable error if `config.toml` is malformed.
  
  Finally, I also updated the TUI to show which **sandbox** value is being
  used, as we do for other key values like **model** and **approval**.
  This was also a reminder that the various values of `--sandbox` are
  honored on Linux but not macOS today, so I added some TODOs about fixing
  that.

  Michael Bolin · 2025-04-27 21:47:50 -07:00
  4eda4dd772
• feat: add ZDR support to Rust implementation (#642)

  This adds support for the `--disable-response-storage` flag across our
  multiple Rust CLIs to support customers who have opted into Zero-Data
  Retention (ZDR). The analogous changes to the TypeScript CLI were:
  
  * https://github.com/openai/codex/pull/481
  * https://github.com/openai/codex/pull/543
  
  For a client using ZDR, `previous_response_id` will never be available,
  so the `input` field of an API request must include the full transcript
  of the conversation thus far. As such, this PR changes the type of
  `Prompt.input` from `Vec<ResponseInputItem>` to `Vec<ResponseItem>`.
  
  Practically speaking, `ResponseItem` was effectively a "superset" of
  `ResponseInputItem` already. The main difference for us is that
  `ResponseItem` includes the `FunctionCall` variant that we have to
  include as part of the conversation history in the ZDR case.
  
  Another key change in this PR is modifying `try_run_turn()` so that it
  returns the `Vec<ResponseItem>` for the turn in addition to the
  `Vec<ResponseInputItem>` produced by `try_run_turn()`. This is because
  the caller of `run_turn()` needs to record the `Vec<ResponseItem>` when
  ZDR is enabled.
  
  To that end, this PR introduces `ZdrTranscript` (and adds
  `zdr_transcript: Option<ZdrTranscript>` to `struct State` in `codex.rs`)
  to take responsibility for maintaining the conversation transcript in
  the ZDR case.

  Michael Bolin · 2025-04-25 12:08:18 -07:00
  b323d10ea7
• [codex-rs] More fine-grained sandbox flag support on Linux (#632)

  ##### What/Why
  This PR makes it so that in Linux we actually respect the different
  types of `--sandbox` flag, such that users can apply network and
  filesystem restrictions in combination (currently the only supported
  behavior), or just pick one or the other.
  
  We should add similar support for OSX in a future PR.
  
  ##### Testing
  From Linux devbox, updated tests to use more specific flags:
  ```
  test linux::tests_linux::sandbox_blocks_ping ... ok
  test linux::tests_linux::sandbox_blocks_getent ... ok
  test linux::tests_linux::test_root_read ... ok
  test linux::tests_linux::test_dev_null_write ... ok
  test linux::tests_linux::sandbox_blocks_dev_tcp_redirection ... ok
  test linux::tests_linux::sandbox_blocks_ssh ... ok
  test linux::tests_linux::test_writable_root ... ok
  test linux::tests_linux::sandbox_blocks_curl ... ok
  test linux::tests_linux::sandbox_blocks_wget ... ok
  test linux::tests_linux::sandbox_blocks_nc ... ok
  test linux::tests_linux::test_root_write - should panic ... ok
  ```
  
  ##### Todo
  - [ ] Add negative tests (e.g. confirm you can hit the network if you
  configure filesystem only restrictions)

  oai-ragona · 2025-04-24 15:33:45 -07:00
  b34ed2ab83
• feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)

  As stated in `codex-rs/README.md`:
  
  Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
  run it. For a number of users, this runtime requirement inhibits
  adoption: they would be better served by a standalone executable. As
  maintainers, we want Codex to run efficiently in a wide range of
  environments with minimal overhead. We also want to take advantage of
  operating system-specific APIs to provide better sandboxing, where
  possible.
  
  To that end, we are moving forward with a Rust implementation of Codex
  CLI contained in this folder, which has the following benefits:
  
  - The CLI compiles to small, standalone, platform-specific binaries.
  - Can make direct, native calls to
  [seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
  [landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
  order to support sandboxing on Linux.
  - No runtime garbage collection, resulting in lower memory consumption
  and better, more predictable performance.
  
  Currently, the Rust implementation is materially behind the TypeScript
  implementation in functionality, so continue to use the TypeScript
  implmentation for the time being. We will publish native executables via
  GitHub Releases as soon as we feel the Rust version is usable.

  Michael Bolin · 2025-04-24 13:31:40 -07:00
  31d0d7a305