mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Adam Perry @ OpenAI
9d938a46d9
## 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.
9d938a46d9
ยท
2026-06-12 20:20:23 -07:00
History
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
- PowerShell and ConPTY/TTY behavior are 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.