1727 Commits

• [prompt] Update prompt.md (#1839)

  ## Summary
  Additional clarifications to our prompt. Still very concise, but we'll
  continue to add more here.

  Dylan · 2025-08-05 00:43:23 -07:00
  d31e149cb1
• 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
• Stream model responses (#1810)

  Stream models thoughts and responses instead of waiting for the whole
  thing to come through. Very rough right now, but I'm making the risk call to push through.

  easong-openai · 2025-08-05 04:23:22 +00:00
  906d449760
• [prompts] Better user_instructions handling (#1836)

  ## Summary
  Our recent change in #1737 can sometimes lead to the model confusing
  AGENTS.md context as part of the message. But a little prompting and
  formatting can help fix this!
  
  ## Testing
  - Ran locally with a few different prompts to verify the model
  behaves well.
  - Updated unit tests

  Dylan · 2025-08-04 18:55:57 -07:00
  063083af15
• Restore API key and query param overrides (#1826)

  Addresses https://github.com/openai/codex/issues/1796

  pakrym-oai · 2025-08-04 18:07:49 -07:00
  84bcadb8d9
• 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
• chore(deps): bump toml from 0.9.2 to 0.9.4 in /codex-rs (#1815)

  Bumps [toml](https://github.com/toml-rs/toml) from 0.9.2 to 0.9.4.
  <details>
  <summary>Commits</summary>
  <ul>
  <li><a
  href="https://github.com/toml-rs/toml/commit/2126e6af51aa2dc276b5756c06f5c2a20b8991d3"><code>2126e6a</code></a>
  chore: Release</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/fa2100a888480f03413b64fed1f814c3a26d62aa"><code>fa2100a</code></a>
  docs: Update changelog</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/0c75bbd6f750db2330c84b94b0ff1ac47167cce1"><code>0c75bbd</code></a>
  feat(toml): Expose DeInteger/DeFloat as_str/radix (<a
  href="https://redirect.github.com/toml-rs/toml/issues/1021">#1021</a>)</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/e3d64dff479a791a0b35ab64a1ce10a87113fa65"><code>e3d64df</code></a>
  feat(toml): Expose DeFloat::as_str</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/ffdd2110334e0149e9820e23f41325c67d5f44a0"><code>ffdd211</code></a>
  feat(toml): Expose DeInteger::as_str/radix</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/9e7adcc7fa7311e20452e40d636a56ec9a998a70"><code>9e7adcc</code></a>
  docs(readme): Fix links to crates (<a
  href="https://redirect.github.com/toml-rs/toml/issues/1020">#1020</a>)</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/73d04e20b5532edb9e7bf15c2c622285b389dc45"><code>73d04e2</code></a>
  docs(readme): Fix links to crates</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/da667e8a7dd2aca6ead9e40260f8defc756ce4c0"><code>da667e8</code></a>
  chore: Release</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/b1327fbe7cf284058e06cbce8714cc5dc09eadc4"><code>b1327fb</code></a>
  docs: Update changelog</li>
  <li><a
  href="https://github.com/toml-rs/toml/commit/fb5346827ee473a7e9df474b81e3dbf047d6ecc9"><code>fb53468</code></a>
  fix(toml): Don't enable std in toml_writer (<a
  href="https://redirect.github.com/toml-rs/toml/issues/1019">#1019</a>)</li>
  <li>Additional commits viewable in <a
  href="https://github.com/toml-rs/toml/compare/toml-v0.9.2...toml-v0.9.4">compare
  view</a></li>
  </ul>
  </details>
  <br />
  
  
  [![Dependabot compatibility
  score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=toml&package-manager=cargo&previous-version=0.9.2&new-version=0.9.4)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
  
  Dependabot will resolve any conflicts with this PR as long as you don't
  alter it yourself. You can also trigger a rebase manually by commenting
  `@dependabot rebase`.
  
  [//]: # (dependabot-automerge-start)
  [//]: # (dependabot-automerge-end)
  
  ---
  
  <details>
  <summary>Dependabot commands and options</summary>
  <br />
  
  You can trigger Dependabot actions by commenting on this PR:
  - `@dependabot rebase` will rebase this PR
  - `@dependabot recreate` will recreate this PR, overwriting any edits
  that have been made to it
  - `@dependabot merge` will merge this PR after your CI passes on it
  - `@dependabot squash and merge` will squash and merge this PR after
  your CI passes on it
  - `@dependabot cancel merge` will cancel a previously requested merge
  and block automerging
  - `@dependabot reopen` will reopen this PR if it is closed
  - `@dependabot close` will close this PR and stop Dependabot recreating
  it. You can achieve the same result by closing it manually
  - `@dependabot show <dependency name> ignore conditions` will show all
  of the ignore conditions of the specified dependency
  - `@dependabot ignore this major version` will close this PR and stop
  Dependabot creating any more for this major version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this minor version` will close this PR and stop
  Dependabot creating any more for this minor version (unless you reopen
  the PR or upgrade to it yourself)
  - `@dependabot ignore this dependency` will close this PR and stop
  Dependabot creating any more for this dependency (unless you reopen the
  PR or upgrade to it yourself)
  
  
  </details>
  
  Signed-off-by: dependabot[bot] <support@github.com>
  Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

  dependabot[bot] · 2025-08-04 14:24:19 -07:00
  2899817c94
• Update prompt.md (#1819)

  The existing prompt is really bad. As a low-hanging fruit, let's correct
  the apply_patch instructions - this helps smaller models successfully
  apply patches.

  easong-openai · 2025-08-04 10:42:39 -07:00
  a6139aa003
• 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
• 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
• [sandbox] Filter out certain non-sandbox errors (#1804)

  ## Summary
  Users frequently complain about re-approving commands that have failed
  for non-sandbox reasons. We can't diagnose with complete accuracy which
  errors happened because of a sandbox failure, but we can start to
  eliminate some common simple cases.
  
  This PR captures the most common case I've seen, which is a `command not
  found` error.
  
  ## Testing
  - [x] Added unit tests
  - [x] Ran a few cases locally

  Dylan · 2025-08-03 13:05:48 -07:00
  e3565a3f43
• 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
• Fix MacOS multiprocessing by relaxing sandbox (#1808)

  The following test script fails in the codex sandbox:
  ```
  import multiprocessing
  from multiprocessing import Lock, Process
  
  def f(lock):
      with lock:
          print("Lock acquired in child process")
  
  if __name__ == '__main__':
      lock = Lock()
      p = Process(target=f, args=(lock,))
      p.start()
      p.join()
  ```
  
  with 
  ```
  Traceback (most recent call last):
    File "/Users/david.hao/code/codex/codex-rs/cli/test.py", line 9, in <module>
      lock = Lock()
             ^^^^^^
    File "/Users/david.hao/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/lib/python3.12/multiprocessing/context.py", line 68, in Lock
      return Lock(ctx=self.get_context())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/Users/david.hao/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/lib/python3.12/multiprocessing/synchronize.py", line 169, in __init__
      SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
    File "/Users/david.hao/.local/share/uv/python/cpython-3.12.9-macos-aarch64-none/lib/python3.12/multiprocessing/synchronize.py", line 57, in __init__
      sl = self._semlock = _multiprocessing.SemLock(
                           ^^^^^^^^^^^^^^^^^^^^^^^^^
  PermissionError: [Errno 1] Operation not permitted
  ```
  
  After reading, adding this line to the sandbox configs fixes things -
  MacOS multiprocessing appears to use sem_lock(), which opens an IPC
  which is considered a disk write even though no file is created. I
  interrogated ChatGPT about whether it's okay to loosen, and my
  impression after reading is that it is, although would appreciate a
  close look
  
  
  Breadcrumb: You can run `cargo run -- debug seatbelt --full-auto <cmd>`
  to test the sandbox

  David Z Hao · 2025-08-03 06:59:26 -07:00
  75eecb656e
• Fix compact (#1798)

  We are not recording the summary in the history.

  aibrahim-oai · 2025-08-02 12:05:06 -07:00
  81bb1c9e26
• 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 a custom originator setting (#1781)
  pakrym-oai · 2025-08-01 09:55:23 -07:00
  88ea215c80
• ci fix (#1782)
  aibrahim-oai · 2025-08-01 09:17:13 -07:00
  b67c485d84
• 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
• Send account id when available (#1767)

  For users with multiple accounts we need to specify the account to use.

  pakrym-oai · 2025-07-31 15:40:19 -07:00
  0935e6a875
• Initial planning tool (#1753)

  We need to optimize the prompt, but this causes the model to use the new
  planning_tool.
  
  <img width="765" height="110" alt="image"
  src="https://github.com/user-attachments/assets/45633f7f-3c85-4e60-8b80-902f1b3b508d"
  />

  easong-openai · 2025-07-31 20:45:52 +00:00
  6ce0a5875b
• chore: refactor exec.rs: create separate seatbelt.rs and spawn.rs files (#1762)

  At 550 lines, `exec.rs` was a bit large. In particular, I found it hard
  to locate the Seatbelt-related code quickly without a file with
  `seatbelt` in the name, so this refactors things so:
  
  - `spawn_command_under_seatbelt()` and dependent code moves to a new
  `seatbelt.rs` file
  - `spawn_child_async()` and dependent code moves to a new `spawn.rs`
  file

  Michael Bolin · 2025-07-31 13:11:47 -07:00
  5a0ad5ab8f
• fix: ensure PatchApplyBeginEvent and PatchApplyEndEvent are dispatched reliably (#1760)

  This is a follow-up to https://github.com/openai/codex/pull/1705, as
  that PR inadvertently lost the logic where `PatchApplyBeginEvent` and
  `PatchApplyEndEvent` events were sent when patches were auto-approved.
  
  Though as part of this fix, I believe this also makes an important
  safety fix to `assess_patch_safety()`, as there was a case that returned
  `SandboxType::None`, which arguably is the thing we were trying to avoid
  in #1705.
  
  On a high level, we want there to be only one codepath where
  `apply_patch` happens, which should be unified with the patch to run
  `exec`, in general, so that sandboxing is applied consistently for both
  cases.
  
  Prior to this change, `apply_patch()` in `core` would either:
  
  * exit early, delegating to `exec()` to shell out to `apply_patch` using
  the appropriate sandbox
  * proceed to run the logic for `apply_patch` in memory
  
  
  https://github.com/openai/codex/blob/549846b29ad52f6cb4f8560365a731966054a9b3/codex-rs/core/src/apply_patch.rs#L61-L63
  
  In this implementation, only the latter would dispatch
  `PatchApplyBeginEvent` and `PatchApplyEndEvent`, though the former would
  dispatch `ExecCommandBeginEvent` and `ExecCommandEndEvent` for the
  `apply_patch` call (or, more specifically, the `codex
  --codex-run-as-apply-patch PATCH` call).
  
  To unify things in this PR, we:
  
  * Eliminate the back half of the `apply_patch()` function, and instead
  have it also return with `DelegateToExec`, though we add an extra field
  to the return value, `user_explicitly_approved_this_action`.
  * In `codex.rs` where we process `DelegateToExec`, we use
  `SandboxType::None` when `user_explicitly_approved_this_action` is
  `true`. This means **we no longer run the apply_patch logic in memory**,
  as we always `exec()`. (Note this is what allowed us to delete so much
  code in `apply_patch.rs`.)
  * In `codex.rs`, we further update `notify_exec_command_begin()` and
  `notify_exec_command_end()` to take additional fields to determine what
  type of notification to send: `ExecCommand` or `PatchApply`.
  
  Admittedly, this PR also drops some of the functionality about giving
  the user the opportunity to expand the set of writable roots as part of
  approving the `apply_patch` command. I'm not sure how much that was
  used, and we should probably rethink how that works as we are currently
  tidying up the protocol to the TUI, in general.

  Michael Bolin · 2025-07-31 11:13:57 -07:00
  06c786b2da
• Add codex login --api-key (#1759)

  Allow setting the API key via `codex login --api-key`

  pakrym-oai · 2025-07-31 17:48:49 +00:00
  549846b29a
• fix git tests (#1747)

  the git tests were failing on my local machine due to gpg signing config
  in my ~/.gitconfig. tests should not be affected by ~/.gitconfig, so
  configure them to ignore it.

  Jeremy Rose · 2025-07-31 09:17:59 -07:00
  be0cd34300
• Auto format toml (#1745)

  Add recommended extension and configure it to auto format prompt.

  pakrym-oai · 2025-07-30 18:37:00 -07:00
  51b6bdefbe
• fix: run apply_patch calls through the sandbox (#1705)

  Building on the work of https://github.com/openai/codex/pull/1702, this
  changes how a shell call to `apply_patch` is handled.
  
  Previously, a shell call to `apply_patch` was always handled in-process,
  never leveraging a sandbox. To determine whether the `apply_patch`
  operation could be auto-approved, the
  `is_write_patch_constrained_to_writable_paths()` function would check if
  all the paths listed in the paths were writable. If so, the agent would
  apply the changes listed in the patch.
  
  Unfortunately, this approach afforded a loophole: symlinks!
  
  * For a soft link, we could fix this issue by tracing the link and
  checking whether the target is in the set of writable paths, however...
  * ...For a hard link, things are not as simple. We can run `stat FILE`
  to see if the number of links is greater than 1, but then we would have
  to do something potentially expensive like `find . -inum <inode_number>`
  to find the other paths for `FILE`. Further, even if this worked, this
  approach runs the risk of a
  [TOCTOU](https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use)
  race condition, so it is not robust.
  
  The solution, implemented in this PR, is to take the virtual execution
  of the `apply_patch` CLI into an _actual_ execution using `codex
  --codex-run-as-apply-patch PATCH`, which we can run under the sandbox
  the user specified, just like any other `shell` call.
  
  This, of course, assumes that the sandbox prevents writing through
  symlinks as a mechanism to write to folders that are not in the writable
  set configured by the sandbox. I verified this by testing the following
  on both Mac and Linux:
  
  ```shell
  #!/usr/bin/env bash
  set -euo pipefail
  
  # Can running a command in SANDBOX_DIR write a file in EXPLOIT_DIR?
  
  # Codex is run in SANDBOX_DIR, so writes should be constrianed to this directory.
  SANDBOX_DIR=$(mktemp -d -p "$HOME" sandboxtesttemp.XXXXXX)
  # EXPLOIT_DIR is outside of SANDBOX_DIR, so let's see if we can write to it.
  EXPLOIT_DIR=$(mktemp -d -p "$HOME" sandboxtesttemp.XXXXXX)
  
  echo "SANDBOX_DIR: $SANDBOX_DIR"
  echo "EXPLOIT_DIR: $EXPLOIT_DIR"
  
  cleanup() {
    # Only remove if it looks sane and still exists
    [[ -n "${SANDBOX_DIR:-}" && -d "$SANDBOX_DIR" ]] && rm -rf -- "$SANDBOX_DIR"
    [[ -n "${EXPLOIT_DIR:-}" && -d "$EXPLOIT_DIR" ]] && rm -rf -- "$EXPLOIT_DIR"
  }
  
  trap cleanup EXIT
  
  echo "I am the original content" > "${EXPLOIT_DIR}/original.txt"
  
  # Drop the -s to test hard links.
  ln -s "${EXPLOIT_DIR}/original.txt" "${SANDBOX_DIR}/link-to-original.txt"
  
  cat "${SANDBOX_DIR}/link-to-original.txt"
  
  if [[ "$(uname)" == "Linux" ]]; then
      SANDBOX_SUBCOMMAND=landlock
  else
      SANDBOX_SUBCOMMAND=seatbelt
  fi
  
  # Attempt the exploit
  cd "${SANDBOX_DIR}"
  
  codex debug "${SANDBOX_SUBCOMMAND}" bash -lc "echo pwned > ./link-to-original.txt" || true
  
  cat "${EXPLOIT_DIR}/original.txt"
  ```
  
  Admittedly, this change merits a proper integration test, but I think I
  will have to do that in a follow-up PR.

  Michael Bolin · 2025-07-30 16:45:08 -07:00
  221ebfcccc
• Send AGENTS.md as a separate user message (#1737)
  pakrym-oai · 2025-07-30 13:56:24 -07:00
  e0e245cc1c
• 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
• remove conversation history widget (#1727)

  this widget is no longer used.

  Jeremy Rose · 2025-07-30 10:05:40 -07:00
  347c81ad00
• Mcp protocol (#1715)

  - Add typed MCP protocol surface in
  `codex-rs/mcp-server/src/mcp_protocol.rs` for `requests`, `responses`,
  and `notifications`
  - Requests: `NewConversation`, `Connect`, `SendUserMessage`,
  `GetConversations`
  - Message content parts: `Text`, `Image` (`ImageUrl`/`FileId`, optional
  `ImageDetail`), File (`Url`/`Id`/`inline Data`)
  - Responses: `ToolCallResponseEnvelope` with optional `isError` and
  `structuredContent` variants (`NewConversation`, `Connect`,
  `SendUserMessageAccepted`, `GetConversations`)
  - Notifications: `InitialState`, `ConnectionRevoked`, `CodexEvent`,
  `Cancelled`
  - Uniform `_meta` on `notifications` via `NotificationMeta`
  (`conversationId`, `requestId`)
  - Unit tests validate JSON wire shapes for key
  `requests`/`responses`/`notifications`

  aibrahim-oai · 2025-07-29 20:14:41 -07:00
  3823b32b7a
• Trim bash lc and run with login shell (#1725)

  include .zshenv, .zprofile by running with the `-l` flag and don't start
  a shell inside a shell when we see the typical `bash -lc` invocation.

  pakrym-oai · 2025-07-29 16:49:02 -07:00
  6b10e22eb3
• 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
• 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
• chore: split apply_patch logic out of codex.rs and into apply_patch.rs (#1703)

  This is a straight refactor, moving apply-patch-related code from
  `codex.rs` and into the new `apply_patch.rs` file. The only "logical"
  change is inlining `#[allow(clippy::unwrap_used)]` instead of declaring
  `#![allow(clippy::unwrap_used)]` at the top of the file (which is
  currently the case in `codex.rs`).
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1703).
  * #1705
  * __->__ #1703
  * #1702
  * #1698
  * #1697

  Michael Bolin · 2025-07-28 09:51:22 -07:00
  5ebb7dd34c
• fix: support special --codex-run-as-apply-patch arg (#1702)

  This introduces some special behavior to the CLIs that are using the
  `codex-arg0` crate where if `arg1` is `--codex-run-as-apply-patch`, then
  it will run as if `apply_patch arg2` were invoked. This is important
  because it means we can do things like:
  
  ```
  SANDBOX_TYPE=landlock # or seatbelt for macOS
  codex debug "${SANDBOX_TYPE}" -- codex --codex-run-as-apply-patch PATCH
  ```
  
  which gives us a way to run `apply_patch` while ensuring it adheres to
  the sandbox the user specified.
  
  While it would be nice to use the `arg0` trick like we are currently
  doing for `codex-linux-sandbox`, there is no way to specify the `arg0`
  for the underlying command when running under `/usr/bin/sandbox-exec`,
  so it will not work for us in this case.
  
  Admittedly, we could have also supported this via a custom environment
  variable (e.g., `CODEX_ARG0`), but since environment variables are
  inherited by child processes, that seemed like a potentially leakier
  abstraction.
  
  This change, as well as our existing reliance on checking `arg0`, place
  additional requirements on those who include `codex-core`. Its
  `README.md` has been updated to reflect this.
  
  While we could have just added an `apply-patch` subcommand to the
  `codex` multitool CLI, that would not be sufficient for the standalone
  `codex-exec` CLI, which is something that we distribute as part of our
  GitHub releases for those who know they will not be using the TUI and
  therefore prefer to use a slightly smaller executable:
  
  https://github.com/openai/codex/releases/tag/rust-v0.10.0
  
  To that end, this PR adds an integration test to ensure that the
  `--codex-run-as-apply-patch` option works with the standalone
  `codex-exec` CLI.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1702).
  * #1705
  * #1703
  * __->__ #1702
  * #1698
  * #1697

  Michael Bolin · 2025-07-28 09:26:44 -07:00
  d76f96ce79
• fix: use std::env::args_os instead of std::env::args (#1698)

  Apparently `std::env::args()` will panic during iteration if any
  argument to the process is not valid Unicode:
  
  https://doc.rust-lang.org/std/env/fn.args.html
  
  Let's avoid the risk and just go with `std::env::args_os()`.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/1698).
  * #1705
  * #1703
  * #1702
  * __->__ #1698
  * #1697

  Michael Bolin · 2025-07-28 08:52:18 -07:00
  fcd197d596
• chore: update Codex::spawn() to return a struct instead of a tuple (#1677)

  Also update `init_codex()` to return a `struct` instead of a tuple, as well.

  Michael Bolin · 2025-07-27 20:01:35 -07:00
  2405c40026
• Changing method in MCP notifications (#1684)

  - Changing the codex/event type

  aibrahim-oai · 2025-07-26 10:35:49 -07:00
  5a0079fea2
• Optionally run using user profile (#1678)
  pakrym-oai · 2025-07-25 11:45:23 -07:00
  7ee87123a6
• chore: use one write call per item in rollout_writer() (#1679)

  Most of the time, we expect the `String` returned by
  `serde_json::to_string()` to have extra capacity, so `push('\n')` is
  unlikely to allocate, which seems cheaper than an extra `write(2)` call,
  on average?

  Michael Bolin · 2025-07-25 10:43:36 -07:00
  994c9a874d
• 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
• feat: expand the set of commands that can be safely identified as "trusted" (#1668)

  This PR updates `is_known_safe_command()` to account for "safe
  operators" to expand the set of commands that can be run without
  approval. This concept existed in the TypeScript CLI, and we are
  [finally!] porting it to the Rust one:
  
  
  https://github.com/openai/codex/blob/c9e2def49487585cfe6f8bb7b2be442e8c0b5e1b/codex-cli/src/approvals.ts#L531-L541
  
  The idea is that if we have `EXPR1 SAFE_OP EXPR2` and `EXPR1` and
  `EXPR2` are considered safe independently, then `EXPR1 SAFE_OP EXPR2`
  should be considered safe. Currently, `SAFE_OP` includes `&&`, `||`,
  `;`, and `|`.
  
  In the TypeScript implementation, we relied on
  https://www.npmjs.com/package/shell-quote to parse the string of Bash,
  as it could provide a "lightweight" parse tree, parsing `'beep || boop >
  /byte'` as:
  
  ```
  [ 'beep', { op: '||' }, 'boop', { op: '>' }, '/byte' ]
  ```
  
  Though in this PR, we introduce the use of
  https://crates.io/crates/tree-sitter-bash for parsing (which
  incidentally we were already using in
  [`codex-apply-patch`](https://github.com/openai/codex/blob/c9e2def49487585cfe6f8bb7b2be442e8c0b5e1b/codex-rs/apply-patch/Cargo.toml#L18)),
  which gives us a richer parse tree. (Incidentally, if you have never
  played with tree-sitter, try the
  [playground](https://tree-sitter.github.io/tree-sitter/7-playground.html)
  and select **Bash** from the dropdown to see how it parses various
  expressions.)
  
  As a concrete example, prior to this change, our implementation of
  `is_known_safe_command()` could verify things like:
  
  ```
  ["bash", "-lc", "grep -R \"Cargo.toml\" -n"]
  ```
  
  but not:
  
  ```
  ["bash", "-lc", "grep -R \"Cargo.toml\" -n || true"]
  ```
  
  With this change, the version with `|| true` is also accepted.
  
  Admittedly, this PR does not expand the safety check to support
  subshells, so it would reject, e.g. `bash -lc 'ls || (pwd && echo hi)'`,
  but that can be addressed in a subsequent PR.

  Michael Bolin · 2025-07-24 14:13:30 -07:00
  a1641743a8
• fix: add true,false,nl to the list of trusted commands (#1676)

  `nl` is a line-numbering tool that should be on the _trusted _ list, as
  there is nothing concerning on https://gtfobins.github.io/gtfobins/nl/
  that would merit exclusion.
  
  `true` and `false` are also safe, though not particularly useful given
  how `is_known_safe_command()` works today, but that will change with
  https://github.com/openai/codex/pull/1668.

  Michael Bolin · 2025-07-24 12:59:36 -07:00
  c9e2def494