## What changed
Replace fixed release pins for app-server/exec-server compatibility tests with the latest stable version and the stable release published closest to 60 days ago. Exclude drafts and prereleases, and prefer the higher version when publication dates are equally close.
Resolve release versions and SHA-256 asset digests before Linux Bazel CI runs, passing them through `CODEX_COMPAT_RELEASES` to the release archive repositories. Reuse the argument comment lint action so it also prepares compatibility releases. Add bounded retries for transient GitHub release reads.
## Testing
Add unit coverage for stable release filtering, version ordering, nearest publication dates, tie-breaking, and deduplication when both selections resolve to the same release.
GitOrigin-RevId: 5a8cf8bdabd77ab3fa89bbb711367b5d9ce8044b
## What changed
Use the stable and experimental bundles generated by `//bazel/schema:app-server` as compile-time inputs for `app-server-protocol` instead of the checked-in bundles.
Generalize `schema_generator_sources` to `schema_sources` so it can stage Rust sources alongside generated bundles. Keep empty bundle placeholders for the on-demand schema generator, which derives its output from Rust sources.
GitOrigin-RevId: a976c420a3698d631f3ea7c698b15b82391158e5
## What changed
- Add `//bazel/schema:app-server` to generate stable and experimental schemas from Rust sources without depending on committed precomputed bundles.
- Add `//sdk/python:generated` to generate Python SDK models, the notification registry, and API methods from the stable schema in scratch space, using dependencies from `uv.lock`.
- Add `generate-types --no-format` to skip formatters for build outputs while preserving formatting by default.
## Testing
Extend contract generation tests to regenerate in a temporary SDK copy, checking byte equality for formatted output and AST equality for unformatted output.
GitOrigin-RevId: 9ca7daa8ac0a33c4106a9e95c2f48bbded07df21
## What changed
- Add `runtime_package` targets for combined, primary, app-server, and Windows helper bundles, plus per-binary release archives.
- Apply release settings automatically and retain unstripped binaries with macOS dSYM or Windows PDB symbols. Require platform-specific symbols and validate that dSYM bundles contain nonempty DWARF data.
- Support a `debug` build mode for faster package smoke builds and configure platform-specific release settings, including native Windows MSVC toolchains.
- Add a composite action that refreshes Cargo workspace metadata, builds the selected archive, and extracts writable files for existing signing and packaging steps.
GitOrigin-RevId: 21109875cde228aaef67b2ba9812b3e4854aee84
## Why
Passing extra descriptors to a PTY previously selected behavior intended for inherited escalation sockets: no EOF on stdin close, different signal exit statuses, and no default `SHELL`. Launch attachments need ordinary PTY behavior and must survive execution even when marked `FD_CLOEXEC`.
## What changed
- Add `ChildFds::Attached` alongside `ChildFds::Inherited` to distinguish launch attachments from legacy inherited descriptors.
- Preserve ordinary EOF, default `SHELL`, and signal exit status behavior for PTY attachments.
- Allow explicitly supplied close-on-exec descriptors through pipe and PTY launches without changing the parent's descriptor flags, using child-side flag updates and macOS spawn inheritance actions.
- Update existing callers to use `ChildFds::Inherited`.
## Testing
Add Unix coverage for attachment accessibility, unchanged parent descriptor flags, default `SHELL`, and signal exit statuses. Extend the PTY stdin-draining test to cover attachments and EOF delivery.
GitOrigin-RevId: 864aedc6c5717d8b43c9d71057c9f54409834509
## Why
Stamped Rust binaries consume workspace status files containing build user,
host, and timestamp values. These unrelated values prevent remote cache reuse
when building the same commit across developers and CI workers.
## What changed
Generate a compiler environment file containing only `STABLE_GIT_COMMIT` through
a small stamped template action. Use it for `codex`, `codex-tui`, and
`codex-voice-host`, with Rust binary stamping disabled so their build metadata
input changes only when the embedded commit changes.
Rename the crate macro option from `stamped_binaries` to
`binaries_with_build_commit` and add `bazel_lib` for template expansion.
GitOrigin-RevId: 21d0f2e3df97670a4c2cdbc3d1972cd14cc5b439
## What changed
- Add a `schema_bundle` rule that generates stable and experimental app-server
schema directories as declared Bazel actions.
- Include the pinned `zstd` executable in the bundle so consumers can normalize
generated JSON without a separate `bazel run` invocation.
- Expose the app-server protocol test binary as the schema generator and add the
manual `//bazel/schema:public-schema-bundle` target.
GitOrigin-RevId: 0a7ce47258d297dbf20db78626f2843145ee1b49
## What changed
- Exercise Rust source discovery through a mocked `git ls-files` call, including files outside `codex-rs`, paths containing spaces, and stale entries that no longer exist.
- Assert that the formatter invokes `rustfmt` from `codex-rs` with the repository configuration in both format and check modes.
- Keep the multiline argument-comment lint fixture stable under formatting and update affected Rust test files to the expected style.
GitOrigin-RevId: 0cfffde1bb91bf620d2118bed1efc68466c0cca6
## What changed
- Map each supported release platform name to its Rust target triple.
- Build multiplatform release binaries against the corresponding `rules_rs`
platform instead of the LLVM platform definitions.
- Document that `multiplatform_binaries` accepts a subset of the declared
release platforms.
GitOrigin-RevId: 55e2fb0f92e5fa9e608c10380b1c5d893ca83895
## What changed
- Add a Bazel test rule that runs the shared Noise relay compatibility suite with current or packaged Codex binaries.
- Cover both app-server/exec-server directions for the current build, release `0.149.1`, and the minimum supported release `0.145.0` on Linux x86-64.
- Remove the standalone version-skew download scripts and the protocol constant they used.
## Testing
The new `exec-server-current-version-test`, `exec-server-stable-release-test`, and `exec-server-minimum-release-test` targets exercise the compatibility suite.
GitOrigin-RevId: 6b3b91eea8e05a38bec1fac128afc54f0d654014
## What changed
- Add a Bazel module extension that downloads checksum-pinned Linux x86-64 Codex release packages, with the Codex release host and GitHub Releases as sources.
- Generate `codex` and `package` filegroups from each package's `codex-package.json` manifest so consumers can address the entrypoint or the complete package contents.
- Register repositories for Codex `0.145.0` and `0.149.1` in `MODULE.bazel`.
GitOrigin-RevId: a73225bae76cf01a588c7e1b570f3fdd9f6e12ab
## What changed
- Add the `codex.code_mode.v1` protobuf API for managing code-mode sessions, executions, waits, tool callbacks, notifications, and content results.
- Generate and export the Rust client/server bindings with `tonic` under Cargo.
- Add Bazel protobuf targets and a `prost` toolchain that uses the workspace's Rust runtime versions.
GitOrigin-RevId: 51d9d044e01dab2f4d25ab79aa7a52585485eee3
Update the PowerShell-under-Wine test for the `spawn_pty_process` API by
explicitly requesting that no file descriptors be inherited.
GitOrigin-RevId: 38e1db3160cdac155325bb9d07cb321a2d57eb19
## Why
Bazel-backed end-to-end macrobenchmark plumbing needs a small,
deterministic first consumer that does not couple the shared
infrastructure to the remote-skill scenario.
## What
- add `codex_e2e_benchmark`, a small macro for Bazel-only Divan
benchmarks and runtime binary runfiles
- keep benchmark sources under `e2e_benches/` so Cargo does not
auto-discover them
- add a CLI example that resolves the real `codex` binary and measures
`codex --help`
- assert the spawned command succeeds
## Validation
- `bazel test --compilation_mode=fastbuild
--@rules_rust//rust/settings:extra_rustc_flag=-Cdebug-assertions=no
--@rules_rust//rust/settings:extra_exec_rustc_flag=-Cdebug-assertions=no
--cache_test_results=no --test_output=errors --test_arg=--test
//codex-rs/cli:codex-help-bench`
## Stack
1. [#31295 bench: add codex help e2e
macrobenchmark](https://github.com/openai/codex/pull/31295)
2. [#31428 bench: add e2e benchmark
entrypoints](https://github.com/openai/codex/pull/31428)
3. [#31429 ci: smoke Bazel e2e
benchmarks](https://github.com/openai/codex/pull/31429)
## Why
Make it possible to load AGENTS.md from remote exec-servers whose OS is
different than app-server.
## What
- keep `AGENTS.md` discovery and provenance as `PathUri`, with
root-aware parent and ancestor traversal
- expose lifecycle instruction sources as legacy app-server path strings
in events while retaining `PathUri` internally
- preserve and test mixed POSIX and Windows paths in model context and
TUI status output
- cover remote Windows loading end to end by seeding the Wine prefix
through host filesystem APIs
- fix bug in `PathUri`'s parent() implementation that would erase
Windows drive letters
## Why
We want to exercise a linux app-server against a windows exec-server
without having to repeat every test case. This approach has slight
precedent in the remote docker test setup.
## What
Run the shared `codex-core` integration suite against Windows
exec-server behavior from Linux. This makes cross-OS path and shell
regressions visible while keeping unsupported cases owned by individual
tests.
- Add `local`, `docker`, and `wine-exec` test environment selection with
legacy Docker compatibility.
- Extend `codex_rust_crate` to generate a sharded Wine-exec variant
using a cross-built Windows server and pinned Bazel Wine/PowerShell
runtimes.
- Teach remote-aware helpers about Windows paths and track temporary
incompatibilities with source-local `skip_if_wine_exec!` calls and
follow-up reasons.
## Why
Next slice needed to make progress on the `remote_env_windows` test is
to support passing a Windows cwd for the remote environment and using
that environment's native shell. This lets the test run a real Windows
process instead of only recording an early path or shell mismatch.
## What
- change `TurnEnvironmentSelection.cwd` from `AbsolutePathBuf` to
`PathUri`
- convert local cwd values to URIs when constructing selections
- preserve a remote primary cwd instead of replacing it with the local
legacy fallback
- prefer the selected environment's discovered shell for unified exec,
falling back to the session shell when unavailable
- convert back to a host-native absolute path at current native-only
consumer boundaries
- reject or deny unsupported foreign cwd values at the existing
request-permissions boundary, with TODOs for its future migration
- extend the hermetic Wine test to execute Windows PowerShell in
`C:\windows` and verify successful process completion
- record the current app-server rejection against the same Wine-backed
remote Windows fixture when its cwd is supplied as a native Windows path
## Why
Cross-OS tests in the wine environment will be much more faithful if we
can also test powershell integration.
## What
Add an x86_64 powershell binary to the bazel wine environment and
include smoke tests.
## Why
We want to make it possible for an app-server orchestrator on one OS to
control an exec-server on another host running a different OS. In
practice this kinda already works if you get lucky and the two hosts
have the same path format, but we mangle quite a lot of operations if
either end is Windows.
This test starts exercising that interaction, although right now the
initial bootstrap fails. Future changes will expand the test's
assertions to match improved support.
## What
Stacked on #27964. This adds a small Windows exec-server fixture and a
Linux protocol smoke test using the reusable Wine harness, covering
Windows environment discovery, non-TTY `cmd.exe` execution, output, exit
status, and working directory.
Once we've got the full codex binary cross-building under Bazel we could
consider moving to the real binary instead of the stripped down
exec-server-only binary used here.
## Why
We want to make it possible for an app-server orchestrator on one OS to
control an exec-server on another host running a different OS. In
practice this kinda already works if you get lucky and the two hosts
have the same path format, but we mangle quite a lot of operations if
either end is Windows.
We should be able to test the cross-platform interactions for
exec-server, but we want to do this fairly soon and need a lightweight
option for testing. Using Wine to run the Windows side is far from
perfect, but it should give us a decent measure of how well we're
handling the basics of paths, process spawning, shell interaction, etc.
Future changes will add actual exec-server tests and possibly extensions
to the Wine testing environment.
## What
To make the cross-target-triple build easy, these tests are added only
to the Bazel build. This change adds an x86_64 Wine prebuilt managed by
Bazel and some build rules that can set up the needed toolchain
transition.
The support library for running Wine in a test environment created by
the Bazel rules comes with its own basic unit and integration tests.
Their primary priority is to make sure we don't leak child processes on
developer machines and that we can build and launch a basic hello world
binary.
## Validation
Confirmed these new tests are running on the [x86_64 bazel ubuntu
jobs](https://github.com/openai/codex/actions/runs/27446432302/job/81132356855?pr=27937):
```
//bazel/rules/testing/wine:wine-smoke-test (cached) PASSED in 3.7s
//bazel/rules/testing/wine:wine-test-support-unit-tests (cached) PASSED in 15.8s
```
## Intent
Keep release-specific Bazel helpers out of the shared Rust crate
definitions and colocate them with Bazel platform configuration.
## Implementation
Moves `multiplatform_binaries` and its platform list from `defs.bzl`
into `bazel/platforms/release_binaries.bzl` and updates the CLI load
site. Behavior is unchanged.
## Validation
- `bazel query //codex-rs/cli:release_binaries`
Stack: 1 of 6.
felixxia-oai