mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Adam Perry @ OpenAI
efbd00f21f
## 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
efbd00f21f
ยท
2026-06-14 06:07:46 +00: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.