41 Commits

• [codex] Migrate apply_patch to executor filesystem (#17027)

  - Migrate apply-patch verification and application internals to use the
  async `ExecutorFileSystem` abstraction from `exec-server`.
  - Convert apply-patch `cwd` handling to `AbsolutePathBuf` through the
  verifier/parser/handler boundary.
  
  Doesn't change how the tool itself works.

  pakrym-oai · 2026-04-07 21:20:22 +00:00
  e9702411ab
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

  ## Why
  
  `argument-comment-lint` was green in CI even though the repo still had
  many uncommented literal arguments. The main gap was target coverage:
  the repo wrapper did not force Cargo to inspect test-only call sites, so
  examples like the `latest_session_lookup_params(true, ...)` tests in
  `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path.
  
  This change cleans up the existing backlog, makes the default repo lint
  path cover all Cargo targets, and starts rolling that stricter CI
  enforcement out on the platform where it is currently validated.
  
  ## What changed
  
  - mechanically fixed existing `argument-comment-lint` violations across
  the `codex-rs` workspace, including tests, examples, and benches
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and
  `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to
  `--all-targets` unless the caller explicitly narrows the target set
  - fixed both wrappers so forwarded cargo arguments after `--` are
  preserved with a single separator
  - documented the new default behavior in
  `tools/argument-comment-lint/README.md`
  - updated `rust-ci` so the macOS lint lane keeps the plain wrapper
  invocation and therefore enforces `--all-targets`, while Linux and
  Windows temporarily pass `-- --lib --bins`
  
  That temporary CI split keeps the stricter all-targets check where it is
  already cleaned up, while leaving room to finish the remaining Linux-
  and Windows-specific target-gated cleanup before enabling
  `--all-targets` on those runners. The Linux and Windows failures on the
  intermediate revision were caused by the wrapper forwarding bug, not by
  additional lint findings in those lanes.
  
  ## Validation
  
  - `bash -n tools/argument-comment-lint/run.sh`
  - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh`
  - shell-level wrapper forwarding check for `-- --lib --bins`
  - shell-level wrapper forwarding check for `-- --tests`
  - `just argument-comment-lint`
  - `cargo test` in `tools/argument-comment-lint`
  - `cargo test -p codex-terminal-detection`
  
  ## Follow-up
  
  - Clean up remaining Linux-only target-gated callsites, then switch the
  Linux lint lane back to the plain wrapper invocation.
  - Clean up remaining Windows-only target-gated callsites, then switch
  the Windows lint lane back to the plain wrapper invocation.

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• fix: codex-arg0 no longer depends on codex-core (#12434)

  ## Why
  
  `codex-rs/arg0` only needed two things from `codex-core`:
  
  - the `find_codex_home()` wrapper
  - the special argv flag used for the internal `apply_patch`
  self-invocation path
  
  That made `codex-arg0` depend on `codex-core` for a very small surface
  area. This change removes that dependency edge and moves the shared
  `apply_patch` invocation flag to a more natural boundary
  (`codex-apply-patch`) while keeping the contract explicitly documented.
  
  ## What Changed
  
  - Moved the internal `apply_patch` argv[1] flag constant out of
  `codex-core` and into `codex-apply-patch`.
  - Renamed the constant to `CODEX_CORE_APPLY_PATCH_ARG1` and documented
  that it is part of the Codex core process-invocation contract (even
  though it now lives in `codex-apply-patch`).
  - Updated `arg0`, the core apply-patch runtime, and the `codex-exec`
  apply-patch test to import the constant from `codex-apply-patch`.
  - Updated `codex-rs/arg0` to call
  `codex_utils_home_dir::find_codex_home()` directly instead of
  `codex_core::config::find_codex_home()`.
  - Removed the `codex-core` dependency from `codex-rs/arg0` and added the
  needed direct dependency on `codex-utils-home-dir`.
  - Added `codex-apply-patch` as a dev-dependency for `codex-rs/exec`
  tests (the apply-patch test now imports the moved constant directly).
  
  ## Verification
  
  - `cargo test -p codex-apply-patch`
  - `cargo test -p codex-arg0`
  - `cargo test -p codex-core --lib apply_patch`
  - `cargo test -p codex-exec
  test_standalone_exec_cli_can_use_apply_patch`
  - `cargo shear`

  Michael Bolin · 2026-02-21 00:20:42 -08:00
  2fe4be1aa9
• Fix minor typos in comments and documentation (#10287)

  ## Summary
  
  I have read the contribution guidelines.  
  All changes in this PR are limited to text corrections and do not modify
  any business logic, runtime behavior, or user-facing functionality.
  
  ## Details
  
  This PR fixes several minor typos, including:
  
  - `create` -> `crate`
  - `analagous` -> `analogous`
  - `apply-patch` -> `apply_patch`
  - `codecs` -> `codex`
  - ` '/" ` -> ` '/' `
  - `Respesent` -> `Represent`

  Ruyut · 2026-01-30 22:11:02 -08:00
  9327e99b28
• fix: accept whitespace-padded patch markers (#8746)

  Trim whitespace when validating '*** Begin Patch'/'*** End Patch'
  markers in codex-apply-patch so padded marker lines parse as intended,
  and add regression coverage (unit + fixture scenario); this avoids
  apply_patch failures when models include extra spacing. Tested with
  cargo test -p codex-apply-patch.

  Thibault Sottiaux · 2026-01-05 17:41:23 -08:00
  771f1ca6ab
• chore(apply-patch) move invocation tests (#8111)

  ## Summary:
  This PR is a pure copy and paste of tests from lib.rs into
  invocation.rs, to colocate logic and tests.
  
  ## Testing
  - [x] Purely a test refactor

  Dylan Hurd · 2025-12-16 12:49:06 -08:00
  a3b137d093
• chore(apply-patch) move invocation parsing (#8110)

  lib.rs has grown quite large, and mixes two responsibilities:
  1. executing patch operations
  2. parsing apply_patch invocations via a shell command
  
  This PR splits out (2) into its own file, so we can work with it more
  easily. We are explicitly NOT moving tests in this PR, to ensure
  behavior stays the same and we can avoid losing coverage via merge
  conflicts. Tests are moved in a subsequent PR.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8110).
  * #8111
  * __->__ #8110

  Dylan Hurd · 2025-12-16 10:30:59 -08:00
  e290d48264
• Revert "fix(apply-patch): preserve CRLF line endings on Windows" (#7903)

  Reverts openai/codex#7515

  Dylan Hurd · 2025-12-11 17:58:35 -08:00
  9e91e49edb
• feat: shell snapshotting (#7641)
  jif-oai · 2025-12-09 18:36:58 +00:00
  7836aeddae
• fix(apply-patch): preserve CRLF line endings on Windows (#7515)

  ## Summary
  This PR is heavily based on #4017, which contains the core logic for the
  fix. To reduce the risk, we are first introducing it only on windows. We
  can then expand to wsl / other environments as needed, and then tackle
  net new files.
  
  ## Testing
  - [x] added unit tests in apply-patch
  - [x] add integration tests to apply_patch_cli.rs
  
  ---------
  
  Co-authored-by: Chase Naples <Cnaples79@gmail.com>

  Dylan Hurd · 2025-12-05 16:43:27 -08:00
  6c9c563faf
• fix(windows) support apply_patch parsing in powershell (#7221)

  ## Summary
  Support powershell parsing of apply_patch
  
  ## Testing
  - [x] Enable apply_patch unit tests
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Dylan Hurd · 2025-11-24 19:32:47 +00:00
  1e832b1438
• Migrate coverage to shell_command (#7042)
  pakrym-oai · 2025-11-21 03:44:00 +00:00
  767b66f407
• Fix apply_patch rename move path resolution (#5486)

  Fixes https://github.com/openai/codex/issues/5485.
  
  Fixed rename hunks so `apply_patch` resolves the destination path using
  the verifier’s effective cwd, ensuring patches that run under `cd
  <worktree> && apply_patch` stay inside the worktree.
  
  Added a regression test
  (`test_apply_patch_resolves_move_path_with_effective_cwd`) that
  reproduced the old behavior (dest path resolved in the main repo) and
  now passes.
  
  Related to https://github.com/openai/codex/issues/5483.
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Shane Vitarana · 2025-11-06 17:02:09 -08:00
  316352be94
• Use assert_matches (#4756)

  assert_matches is soon to be in std but is experimental for now.

  pakrym-oai · 2025-10-05 21:12:31 +00:00
  5c42419b02
• chore: remove once_cell dependency from multiple crates (#4154)

  This commit removes the `once_cell` dependency from `Cargo.toml` files
  in the `codex-rs` and `apply-patch` directories, replacing its usage
  with `std::sync::LazyLock` and `std::sync::OnceLock` where applicable.
  This change simplifies the dependency tree and utilizes standard library
  features for lazy initialization.
  
  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.

  Tien Nguyen · 2025-09-24 09:15:57 -07:00
  00c7f7a16c
• chore: clippy on redundant closure (#4058)

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

  jif-oai · 2025-09-22 19:30:16 +00:00
  be366a31ab
• if a command parses as a patch, do not attempt to run it (#3382)

  sometimes the model forgets to actually invoke `apply_patch` and puts a
  patch as the script body. trying to execute this as bash sometimes
  creates files named `,` or `{` or does other unknown things, so catch
  this situation and return an error to the model.

  Jeremy Rose · 2025-09-12 13:47:41 -07:00
  5f6e95b592
• chore: enable clippy::redundant_clone (#3489)

  Created this PR by:
  
  - adding `redundant_clone` to `[workspace.lints.clippy]` in
  `cargo-rs/Cargol.toml`
  - running `cargo clippy --tests --fix`
  - running `just fmt`
  
  Though I had to clean up one instance of the following that resulted:
  
  ```rust
  let codex = codex;
  ```

  Michael Bolin · 2025-09-11 11:59:37 -07:00
  bec51f6c05
• apply-patch: sort replacements and add regression tests (#3425)

  - Ensure replacements are applied in index order for determinism.
  - Add tests for addition chunk followed by removal and worktree-aware
  helper.
  
  This fixes a panic I observed.
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  Jeremy Rose · 2025-09-11 09:07:03 -07:00
  377af75730
• tweak "failed to find expected lines" message in apply_patch (#3374)

  It was hard for me to read the expected lines as a `["one", "two",
  "three"]` array, maybe not so hard for the model but probably not having
  to un-escape in its head would help it out :)
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  Jeremy Rose · 2025-09-09 12:27:50 -07:00
  ee5ecae7c0
• parse cd foo && ... for exec and apply_patch (#3083)

  sometimes the model likes to run "cd foo && ..." instead of using the
  workdir parameter of exec. handle them roughly the same.

  Jeremy Rose · 2025-09-03 05:26:06 +00:00
  53413c728e
• rework message styling (#2877)

  https://github.com/user-attachments/assets/cf07f62b-1895-44bb-b9c3-7a12032eb371

  Jeremy Rose · 2025-09-02 17:29:58 +00:00
  e442ecedab
• feat: use the arg0 trick with apply_patch (#2646)

  Historically, Codex CLI has treated `apply_patch` (and its sometimes
  misspelling, `applypatch`) as a "virtual CLI," intercepting it when it
  appears as the first arg to `command` for the `"container.exec",
  `"shell"`, or `"local_shell"` tools.
  
  This approach has a known limitation where if, say, the model created a
  Python script that runs `apply_patch` and then tried to run the Python
  script, we have no insight as to what the model is trying to do and the
  Python Script would fail because `apply_patch` was never really on the
  `PATH`.
  
  One way to solve this problem is to require users to install an
  `apply_patch` executable alongside the `codex` executable (or at least
  put it someplace where Codex can discover it). Though to keep Codex CLI
  as a standalone executable, we exploit "the arg0 trick" where we create
  a temporary directory with an entry named `apply_patch` and prepend that
  directory to the `PATH` for the duration of the invocation of Codex.
  
  - On UNIX, `apply_patch` is a symlink to `codex`, which now changes its
  behavior to behave like `apply_patch` if arg0 is `apply_patch` (or
  `applypatch`)
  - On Windows, `apply_patch.bat` is a batch script that runs `codex
  --codex-run-as-apply-patch %*`, as Codex also changes its behavior if
  the first argument is `--codex-run-as-apply-patch`.

  Michael Bolin · 2025-08-24 14:35:51 -07:00
  517ffd00c6
• [apply-patch] Fix applypatch for heredocs (#2477)

  ## Summary
  Follow up to #2186 for #2072 - we added handling for `applypatch` in
  default commands, but forgot to add detection to the heredocs logic.
  
  ## Testing
  - [x] Added unit tests

  Dylan · 2025-08-20 12:16:01 -07:00
  1a1516a80b
• chore: upgrade to Rust 1.89 (#2465)

  Codex created this PR from the following prompt:
  
  > upgrade this entire repo to Rust 1.89. Note that this requires
  updating codex-rs/rust-toolchain.toml as well as the workflows in
  .github/. Make sure that things are "clippy clean" as this change will
  likely uncover new Clippy errors. `just fmt` and `cargo clippy --tests`
  are sufficient to check for correctness
  
  Note this modifies a lot of lines because it folds nested `if`
  statements using `&&`.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/2465).
  * #2467
  * __->__ #2465

  Michael Bolin · 2025-08-19 13:22:02 -07:00
  50c48e88f5
• 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
• [apply-patch] Support applypatch command string (#2186)

  ## Summary
  GPT-OSS and `gpt-5-mini` have training artifacts that cause the models
  to occasionally use `applypatch` instead of `apply_patch`. I think
  long-term we'll want to provide `apply_patch` as a first class tool, but
  for now let's silently handle this case to avoid hurting model
  performance
  
  ## Testing
  - [x] Added unit test

  Dylan · 2025-08-11 13:11:04 -07:00
  5f8984aa7d
• Propagate apply_patch filesystem errors (#1892)

  ## Summary
  We have been returning `exit code 0` from the apply patch command when
  writes fail, which causes our `exec` harness to pass back confusing
  messages to the model. Instead, we should loudly fail so that the
  harness and the model can handle these errors appropriately.
  
  Also adds a test to confirm this behavior.
  
  ## Testing
  - `cargo test -p codex-apply-patch`

  Dylan · 2025-08-06 14:58:53 -07:00
  f25b2e8e2c
• 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
• chore(rs): update dependencies (#1494)

  ### Chores
  - Update cargo dependencies
  - Remove unused cargo dependencies
  - Fix clippy warnings
  - Update Dockerfile (package.json requires node 22)
  - Let Dependabot update bun, cargo, devcontainers, docker,
  github-actions, npm (nix still not supported)
  
  ### TODO
  - Upgrade dependencies with breaking changes
  
  ```shell
  $ cargo update --verbose
     Unchanged crossterm v0.28.1 (available: v0.29.0)
     Unchanged schemars v0.8.22 (available: v1.0.4)
  ```

  Rene Leonhardt · 2025-07-10 11:08:16 -07:00
  82b0cebe8b
• fix: provide tolerance for apply_patch tool (#993)

  As explained in detail in the doc comment for `ParseMode::Lenient`, we
  have observed that GPT-4.1 does not always generate a valid invocation
  of `apply_patch`. Fortunately, the error is predictable, so we introduce
  some new logic to the `codex-apply-patch` crate to recover from this
  error.
  
  Because we would like to avoid this becoming a de facto standard (as it
  would be incompatible if `apply_patch` were provided as an actual
  executable, unless we also introduced the lenient behavior in the
  executable, as well), we require passing `ParseMode::Lenient` to
  `parse_patch_text()` to make it clear that the caller is opting into
  supporting this special case.
  
  Note the analogous change to the TypeScript CLI was
  https://github.com/openai/codex/pull/930. In addition to changing the
  accepted input to `apply_patch`, it also introduced additional
  instructions for the model, which we include in this PR.
  
  Note that `apply-patch` does not depend on either `regex` or
  `regex-lite`, so some of the checks are slightly more verbose to avoid
  introducing this dependency.
  
  That said, this PR does not leverage the existing
  `extract_heredoc_body_from_apply_patch_command()`, which depends on
  `tree-sitter` and `tree-sitter-bash`:
  
  
  https://github.com/openai/codex/blob/5a5aa899143f9b9ef606692c401b010368b15bdb/codex-rs/apply-patch/src/lib.rs#L191-L246
  
  though perhaps it should.

  Michael Bolin · 2025-06-03 09:06:38 -07:00
  6fcc528a43
• fix: introduce ExtractHeredocError that implements PartialEq (#958)
  Michael Bolin · 2025-05-16 09:42:27 -07:00
  3d9f4fcd8a
• fix: apply patch issue when using different cwd (#942)

  If you run a codex instance outside of the current working directory
  from where you launched the codex binary it won't be able to apply
  patches correctly, even if the sandbox policy allows it. This manifests
  weird behaviours, such as
  
  * Reading the same filename in the binary working directory, and
  overwriting it in the session working directory. e.g. if you have a
  `readme` in both folders it will overwrite the readme in the session
  working directory with the readme in the binary working directory
  *applied with the suggested patch*.
  * The LLM ends up in weird loops trying to verify and debug why the
  apply_patch won't work, and it can result in it applying patches by
  manually writing python or javascript if it figures out that either is
  supported by the system instead.
  
  I added a test-case to ensure that the patch contents are based on the
  cwd.
  
  ## Issue: mixing relative & absolute paths in apply_patch
  
  1. The apply_patch tool use relative paths based on the session working
  directory.
  2. `unified_diff_from_chunks` eventually ends up [reading the source
  file](https://github.com/reflectionai/codex/blob/main/codex-rs/apply-patch/src/lib.rs#L410)
  to figure out what the diff is, by using the relative path.
  3. The changes are targeted using an absolute path derived from the
  current working directory.
  
  The end-result in case session working directory differs from the binary
  working directory: we get the diff for a file relative to the binary
  working directory, and apply it on a file in the session working
  directory.

  Sebastian Lund · 2025-05-16 09:12:16 -07:00
  84e01f4b62
• 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
• Workspace lints and disallow unwrap (#855)

  Sets submodules to use workspace lints. Added denying unwrap as a
  workspace level lint, which found a couple of cases where we could have
  propagated errors. Also manually labeled ones that were fine by my eye.

  jcoens-openai · 2025-05-08 09:46:18 -07:00
  87cf120873
• Update cargo to 2024 edition (#842)

  Some effects of this change:
  - New formatting changes across many files. No functionality changes
  should occur from that.
  - Calls to `set_env` are considered unsafe, since this only happens in
  tests we wrap them in `unsafe` blocks

  jcoens-openai · 2025-05-07 08:37:48 -07:00
  8a89d3aeda
• fix: ensure apply_patch resolves relative paths against workdir or project cwd (#810)

  https://github.com/openai/codex/pull/800 kicked off some work to be more
  disciplined about honoring the `cwd` param passed in rather than
  assuming `std::env::current_dir()` as the `cwd`. As part of this, we
  need to ensure `apply_patch` calls honor the appropriate `cwd` as well,
  which is significant if the paths in the `apply_patch` arg are not
  absolute paths themselves. Failing that:
  
  - The `apply_patch` function call can contain an optional`workdir`
  param, so:
  - If specified and is an absolute path, it should be used to resolve
  relative paths
  - If specified and is a relative path, should be resolved against
  `Config.cwd` and then any relative paths will be resolved against the
  result
  - If `workdir` is not specified on the function call, relative paths
  should be resolved against `Config.cwd`
  
  Note that we had a similar issue in the TypeScript CLI that was fixed in
  https://github.com/openai/codex/pull/556.
  
  As part of the fix, this PR introduces `ApplyPatchAction` so clients can
  deal with that instead of the raw `HashMap<PathBuf,
  ApplyPatchFileChange>`. This enables us to enforce, by construction,
  that all paths contained in the `ApplyPatchAction` are absolute paths.

  Michael Bolin · 2025-05-04 12:32:51 -07:00
  5d924d44cf
• fix: eliminate runtime dependency on patch(1) for apply_patch (#718)

  When processing an `apply_patch` tool call, we were already computing
  the new file content in order to compute the unified diff. Before this
  PR, we were shelling out to `patch(1)` to apply the unified diff once
  the user accepted the change, but this updates the code to just retain
  the new file content and use it to write the file when the user accepts.
  This simplifies deployment because it no longer assumes `patch(1)` is on
  the host.
  
  Note this change is internal to the Codex agent and does not affect
  `protocol.rs`.

  Michael Bolin · 2025-04-28 21:15:41 -07:00
  b9bba09819
• fix: handling weird unicode characters in apply_patch (#674)

  I � unicode

  Misha Davidov · 2025-04-25 16:01:58 -07:00
  15bf5ca971
• 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