517ffd00c6
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`.
28 lines
420 B
TOML
28 lines
420 B
TOML
[package]
|
|
edition = "2024"
|
|
name = "codex-apply-patch"
|
|
version = { workspace = true }
|
|
|
|
[lib]
|
|
name = "codex_apply_patch"
|
|
path = "src/lib.rs"
|
|
|
|
[[bin]]
|
|
name = "apply_patch"
|
|
path = "src/main.rs"
|
|
|
|
[lints]
|
|
workspace = true
|
|
|
|
[dependencies]
|
|
anyhow = "1"
|
|
similar = "2.7.0"
|
|
thiserror = "2.0.12"
|
|
tree-sitter = "0.25.8"
|
|
tree-sitter-bash = "0.25.0"
|
|
|
|
[dev-dependencies]
|
|
assert_cmd = "2"
|
|
pretty_assertions = "1.4.1"
|
|
tempfile = "3.13.0"
|