mirror of https://github.com/openai/codex.git synced 2026-09-16 12:13:30 +00:00

Files

Michael Bolin 6ca987fd93 Make sandbox read access configurable with ReadOnlyAccess

## What

This change introduces a new `ReadOnlyAccess` model and threads it through
sandbox policy consumers so read access is explicit instead of implicit.

- Added `ReadOnlyAccess` to protocol:
- `Restricted { include_platform_defaults, readable_roots }`
- `FullAccess`
- Changed `SandboxPolicy` shape:
- `ReadOnly` is now `ReadOnly { access: ReadOnlyAccess }`
- `WorkspaceWrite` now carries `read_only_access: ReadOnlyAccess`
- Kept existing behavior for now by defaulting to `ReadOnlyAccess::FullAccess`
in constructors and current config/app-server mappings.
- Added helper methods to compute effective readable roots (including optional
platform defaults + cwd) and to detect full read access.
- Updated seatbelt policy generation to honor restricted read roots by emitting
scoped `(allow file-read* ...)` entries when full read access is not granted.
- Updated Linux backends (`bwrap`, legacy landlock path) to fail closed with an
explicit `UnsupportedOperation` when restricted read access is requested but
not yet implemented there.
- Updated Windows sandbox backends (standard, elevated, and runner paths) to
fail closed in the same way for restricted read access.
- Updated all call sites/tests/pattern matches for the new structured variants
and regenerated app-server protocol schema/types.

## Why

The previous `SandboxPolicy::ReadOnly` implied full-disk read access and left
no way to express a narrower read surface.

This refactor establishes the policy model needed to support user-configurable
read restrictions in a follow-up without changing current runtime behavior.

It also ensures we do not silently ignore future restricted-read policies on
platform backends that do not support them yet. Failing closed keeps sandbox
semantics predictable and avoids accidental over-permission.

## Compatibility and rollout notes

- Existing behavior is preserved by default (`FullAccess`).
- Existing config/app-server flows continue to serialize/deserialize cleanly.
- New schema artifacts are included to keep generated protocol outputs in sync.

## Validation

- `just fmt`
- `just fix -p codex-protocol -p codex-core -p codex-linux-sandbox -p codex-windows-sandbox -p codex-app-server-protocol`
- `cargo check -p codex-windows-sandbox`
- Targeted crate/test runs were executed during development for protocol/core/
sandbox-related crates.

2026-02-10 22:17:31 -08:00

src

Make sandbox read access configurable with ReadOnlyAccess

2026-02-10 22:17:31 -08:00

tests

Make sandbox read access configurable with ReadOnlyAccess

2026-02-10 22:17:31 -08:00

BUILD.bazel

feat: add support for building with Bazel (#8875 )

2026-01-09 11:09:43 -08:00

Cargo.toml

feat: introduce codex-utils-cargo-bin as an alternative to assert_cmd::Command (#8496 )

2025-12-23 19:29:32 -08:00

README.md

docs: update the docs for @openai/codex-shell-tool-mcp (#7962 )

2025-12-13 09:44:26 -08:00

README.md

codex-exec-server

This crate contains the code for two executables:

codex-exec-mcp-server is an MCP server that provides a tool named shell that runs a shell command inside a sandboxed instance of Bash. Every resulting execve(2) call made within Bash is intercepted and run via the executable defined by the BASH_EXEC_WRAPPER environment variable within the Bash process. In practice, BASH_EXEC_WRAPPER is set to codex-execve-wrapper.
codex-execve-wrapper is the executable that takes the arguments to the execve(2) call and "escalates" it to the MCP server via a shared file descriptor (specified by the CODEX_ESCALATE_SOCKET environment variable) for consideration. Based on the Codex .rules, the MCP server replies with one of:
- Run: codex-execve-wrapper should invoke execve(2) on itself to run the original command within Bash
- Escalate: forward the file descriptors of the current process to the MCP server so the command can be run faithfully outside the sandbox. Because the MCP server will have the original FDs for stdout and stderr, it can write those directly. When the process completes, the MCP server forwards the exit code to codex-execve-wrapper so that it exits in a consistent manner.
- Deny: the MCP server has declared the proposed command to be "forbidden," so codex-execve-wrapper will print an error to stderr and exit with 1.

Patched Bash

We carry a small patch to execute_cmd.c (see patches/bash-exec-wrapper.patch) that adds support for BASH_EXEC_WRAPPER. The original commit message is “add support for BASH_EXEC_WRAPPER” and the patch applies cleanly to a8a1c2fac029404d3f42cd39f5a20f24b6e4fe4b from https://github.com/bminor/bash. To rebuild manually:

git clone https://github.com/bminor/bash
git checkout a8a1c2fac029404d3f42cd39f5a20f24b6e4fe4b
git apply /path/to/patches/bash-exec-wrapper.patch
./configure --without-bash-malloc
make -j"$(nproc)"

Release workflow

.github/workflows/shell-tool-mcp.yml builds the Rust binaries, compiles the patched Bash variants, assembles the vendor/ tree, and creates codex-shell-tool-mcp-npm-<version>.tgz for inclusion in the Rust GitHub Release. When the version is a stable or alpha tag, the workflow also publishes the tarball to npm using OIDC. The workflow is invoked from rust-release.yml so the package ships alongside other Codex artifacts.