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`.
21 lines
406 B
TOML
21 lines
406 B
TOML
[package]
|
|
edition = "2024"
|
|
name = "codex-arg0"
|
|
version = { workspace = true }
|
|
|
|
[lib]
|
|
name = "codex_arg0"
|
|
path = "src/lib.rs"
|
|
|
|
[lints]
|
|
workspace = true
|
|
|
|
[dependencies]
|
|
anyhow = "1"
|
|
codex-apply-patch = { path = "../apply-patch" }
|
|
codex-core = { path = "../core" }
|
|
codex-linux-sandbox = { path = "../linux-sandbox" }
|
|
dotenvy = "0.15.7"
|
|
tempfile = "3"
|
|
tokio = { version = "1", features = ["rt-multi-thread"] }
|