mirror of
https://github.com/openai/codex.git
synced 2026-09-04 15:08:45 +00:00
## Why Unified exec can run commands on an OS that differs from the Codex host. Using host path and shell semantics for approval checks can therefore miss dangerous Windows and PowerShell commands sent to a remote executor. ## What changed - Thread the executor platform through command parsing, executable-name normalization, and dangerous-command classification. Legacy executors fall back to the host platform, while unknown reported platforms use Windows rules conservatively. - Bound model-facing `exec_command` rejection messages and avoid echoing the rejected command into the error. - Keep deterministic process IDs reserved after release so rejected test commands cannot reuse an earlier ID. ## Testing - Add coverage that a long dangerous PowerShell command targeting a remote Windows executor is rejected with a bounded response. - Verify deterministic process IDs advance after release. GitOrigin-RevId: a26b4a63ea3d6df7140032b88b3e7aec0b85b948
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.