Michael Bolin
e89e5136bd
## Why `shell-tool-mcp` and the Bash fork are no longer needed, but the patched zsh fork is still relevant for shell escalation and for the DotSlash-backed zsh-fork integration tests. Deleting the old `shell-tool-mcp` workflow also deleted the only pipeline that rebuilt those patched zsh binaries. This keeps the package removal, while preserving a small release path that can be reused whenever `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch` changes. ## What changed - removed the `shell-tool-mcp` workspace package, its npm packaging/release jobs, the Bash test fixture, and the remaining Bash-specific compatibility wiring - deleted the old `.github/workflows/shell-tool-mcp.yml` and `.github/workflows/shell-tool-mcp-ci.yml` workflows now that their responsibilities have been replaced or removed - kept the zsh patch under `codex-rs/shell-escalation/patches/zsh-exec-wrapper.patch` and updated the `codex-rs/shell-escalation` docs/code to describe the zsh-based flow directly - added `.github/workflows/rust-release-zsh.yml` to build only the three zsh binaries that `codex-rs/app-server/tests/suite/zsh` needs today: - `aarch64-apple-darwin` on `macos-15` - `x86_64-unknown-linux-musl` on `ubuntu-24.04` - `aarch64-unknown-linux-musl` on `ubuntu-24.04` - extracted the shared zsh build/smoke-test/stage logic into `.github/scripts/build-zsh-release-artifact.sh`, made that helper directly executable, and now invoke it directly from the workflow so the Linux and macOS jobs only keep the OS-specific setup in YAML - wired those standalone `codex-zsh-*.tar.gz` assets into `rust-release.yml` and added `.github/dotslash-zsh-config.json` so releases also publish a `codex-zsh` DotSlash file - updated the checked-in `codex-rs/app-server/tests/suite/zsh` fixture comments to explain that new releases come from the standalone zsh assets, while the checked-in fixture remains pinned to the latest historical release until a newer zsh artifact is published - tightened a couple of follow-on cleanups in `codex-rs/shell-escalation`: the `ExecParams::command` comment now describes the shell `-c`/`-lc` string more clearly, and the README now points at the same `git.code.sf.net` zsh source URL that the workflow uses ## Testing - `cargo test -p codex-shell-escalation` - `just argument-comment-lint` - `bash -n .github/scripts/build-zsh-release-artifact.sh` - attempted `cargo test -p codex-core`; unrelated existing failures remain, but the touched `tools::runtimes::shell::unix_escalation::*` coverage passed during that run
codex-core
This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.
Dependencies
Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:
macOS
Expects /usr/bin/sandbox-exec to be present.
When using the workspace-write sandbox policy, the Seatbelt profile allows
writes under the configured writable roots while keeping .git (directory or
pointer file), the resolved gitdir: target, and .codex read-only.
Network access and filesystem read/write roots are controlled by
SandboxPolicy. Seatbelt consumes the resolved policy and enforces it.
Seatbelt also supports macOS permission-profile extensions layered on top of
SandboxPolicy:
- no extension profile provided:
keeps legacy default preferences read access (
user-preference-read). - extension profile provided with no
macos_preferencesgrant: does not add preferences access clauses. macos_preferences = "readonly": enables cfprefs read clauses anduser-preference-read.macos_preferences = "readwrite": includes readonly clauses plususer-preference-writeand cfprefs shm write clauses.macos_automation = true: enables broad Apple Events send permissions.macos_automation = ["com.apple.Notes", ...]: enables Apple Events send only to listed bundle IDs.macos_launch_services = true: enables LaunchServices lookups and open/launch operations.macos_accessibility = true: enablescom.apple.axservermach lookup.macos_calendar = true: enablescom.apple.CalendarAgentmach lookup.macos_contacts = "read_only": enables Address Book read access and Contacts read services.macos_contacts = "read_write": includes the readonly Contacts clauses plus Address Book writes and keychain/temp helpers required for writes.
Linux
Expects the binary containing codex-core to run the equivalent of codex sandbox linux (legacy alias: codex debug landlock) when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.
Legacy SandboxPolicy / sandbox_mode configs are still supported on Linux.
They can continue to use the legacy Landlock path when the split filesystem
policy is sandbox-equivalent to the legacy model after cwd resolution.
Split filesystem policies that need direct FileSystemSandboxPolicy
enforcement, such as read-only or denied carveouts under a broader writable
root, automatically route through bubblewrap. The legacy Landlock path is used
only when the split filesystem policy round-trips through the legacy
SandboxPolicy model without changing semantics. That includes overlapping
cases like /repo = write, /repo/a = none, /repo/a/b = write, where the
more specific writable child must reopen under a denied parent.
The Linux sandbox helper prefers /usr/bin/bwrap whenever it is available and
supports the required argv-rewrite flags, and falls back to the vendored
bubblewrap path compiled into the binary otherwise. When /usr/bin/bwrap is
missing or too old to support the required flags, Codex also surfaces a startup
warning through its normal notification path instead of printing directly from
the sandbox helper.
Windows
Legacy SandboxPolicy / sandbox_mode configs are still supported on
Windows.
The elevated setup/runner backend supports legacy ReadOnlyAccess::Restricted
for read-only and workspace-write policies. Restricted read access honors
explicit readable roots plus the command cwd, and keeps writable roots
readable when workspace-write is used.
When include_platform_defaults = true, the elevated Windows backend adds
backend-managed system read roots required for basic execution, such as
C:\Windows, C:\Program Files, C:\Program Files (x86), and
C:\ProgramData. When it is false, those extra system roots are omitted.
The unelevated restricted-token backend still supports the legacy full-read Windows model only. Restricted read-only policies continue to fail closed there instead of running with weaker read enforcement.
New [permissions] / split filesystem policies remain supported on Windows
only when they round-trip through the legacy SandboxPolicy model without
changing semantics. Richer split-only carveouts still fail closed instead of
running with weaker enforcement.
All Platforms
Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.