codex

core: load AGENTS.md from foreign environments (#28958 )

## 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

Adam Perry @ OpenAI · 2026-06-18 15:06:23 -07:00

dce673905a

Run core integration tests against a Wine-backed Windows executor (#28401 )

## 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.

Adam Perry @ OpenAI · 2026-06-16 00:38:41 +00:00

1fe89de576

[codex] exec-server honors remote environment cwd and shell (#28122 )

## 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

Adam Perry @ OpenAI · 2026-06-14 06:07:46 +00:00

efbd00f21f

bazel: add PowerShell to Wine test harness (#28120 )

## 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.

Adam Perry @ OpenAI · 2026-06-14 04:52:32 +00:00

42dec90bc4

[codex] Add hermetic Wine exec-server test (#27937 )

## 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.

Adam Perry @ OpenAI · 2026-06-12 20:20:23 -07:00

9d938a46d9

[codex] Add hermetic Wine test support (#27964 )

## 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
```

Adam Perry @ OpenAI · 2026-06-12 18:24:49 -07:00

5c8136f48a

[codex] Move release platform rules into bazel package (#27321 )

## 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.

Adam Perry @ OpenAI · 2026-06-10 19:45:29 +00:00

1deae7bd4a

7 Commits