mirror of https://github.com/pchuan98/codex.git synced 2026-07-01 00:31:56 +08:00

Files

T

Adam Perry @ OpenAI 1fe89de576 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.

1fe89de576 · 2026-06-16 00:38:41 +00:00

History

BUILD.bazel

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

2026-06-16 00:38:41 +00:00

README.md

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

2026-06-16 00:38:41 +00:00

remote_env_windows_test.rs

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

2026-06-14 06:07:46 +00:00

README.md

Windows remote-environment test

This Bazel-only test_codex integration test runs a Windows exec-server fixture under pinned Wine and exercises the normal model tool-call and remote-execution path.

Running the test

bazel test \
  //codex-rs/core/tests/remote_env_windows:smoke-test \
  --test_output=errors

No system Wine is required. Every process gets a fresh WINEPREFIX and isolated wineserver.

Current limitations

ConPTY/TTY behavior is not yet covered.
Wine loads shared objects and PE DLLs at runtime, so the host must still provide the declared compatible glibc version.
The target is intentionally limited to x86-64 for simplicity. It can expand if we find aarch64-specific behavior worth testing.