Files
codex/codex-rs/shell-escalation
Michael Bolin 9a8730f31e ci: verify codex-rs Cargo manifests inherit workspace settings (#16353)
## Why

Bazel clippy now catches lints that `cargo clippy` can still miss when a
crate under `codex-rs` forgets to opt into workspace lints. The concrete
example here was `codex-rs/app-server/tests/common/Cargo.toml`: Bazel
flagged a clippy violation in `models_cache.rs`, but Cargo did not
because that crate inherited workspace package metadata without
declaring `[lints] workspace = true`.

We already mirror the workspace clippy deny list into Bazel after
[#15955](https://github.com/openai/codex/pull/15955), so we also need a
repo-side check that keeps every `codex-rs` manifest opted into the same
workspace settings.

## What changed

- add `.github/scripts/verify_cargo_workspace_manifests.py`, which
parses every `codex-rs/**/Cargo.toml` with `tomllib` and verifies:
  - `version.workspace = true`
  - `edition.workspace = true`
  - `license.workspace = true`
  - `[lints] workspace = true`
- top-level crate names follow the `codex-*` / `codex-utils-*`
conventions, with explicit exceptions for `windows-sandbox-rs` and
`utils/path-utils`
- run that script in `.github/workflows/ci.yml`
- update the current outlier manifests so the check is enforceable
immediately
- fix the newly exposed clippy violations in the affected crates
(`app-server/tests/common`, `file-search`, `feedback`,
`shell-escalation`, and `debug-client`)






---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16353).
* #16351
* __->__ #16353
2026-03-31 21:59:28 +00:00
..

codex-shell-escalation

This crate contains the Unix shell-escalation protocol implementation and the codex-execve-wrapper executable.

codex-execve-wrapper receives the arguments to an intercepted execve(2) call and delegates the decision to the shell-escalation protocol over a shared file descriptor (specified by the CODEX_ESCALATE_SOCKET environment variable). The server on the other side replies with one of:

  • Run: codex-execve-wrapper should invoke execve(2) on itself to run the original command within the sandboxed shell.
  • Escalate: forward the file descriptors of the current process so the command can be run faithfully outside the sandbox. When the process completes, the server forwards the exit code back to codex-execve-wrapper.
  • Deny: the server has declared the proposed command to be forbidden, so codex-execve-wrapper prints an error to stderr and exits with 1.

Patched zsh

We carry a small patch to Src/exec.c (see patches/zsh-exec-wrapper.patch) that adds support for EXEC_WRAPPER. The patch applies to 77045ef899e53b9598bebc5a41db93a548a40ca6 from https://git.code.sf.net/p/zsh/code. To rebuild manually:

git clone https://git.code.sf.net/p/zsh/code
git checkout 77045ef899e53b9598bebc5a41db93a548a40ca6
git apply /path/to/patches/zsh-exec-wrapper.patch
./Util/preconfig
./configure
make -j"$(nproc)"