Files
codex/codex-rs/core/tests/remote_env_windows
iceweasel-oai 1f4c47343a Apply remote platform semantics to exec safety checks (#42113)
## 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
2026-09-01 18:24:56 +00:00
..

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.