Remote env tests can fail due to host->bridge IP assumption (exec-server websocket timeout)

Summary

codex-core remote-env tests can fail on Linux setups where host cannot route to Docker bridge container IPs returned at runtime by docker inspect, even though Docker itself is healthy.

Observed on upstream/latest-alpha-cli when running:

• suite::view_image::view_image_tool_does_not_force_original_resolution_with_capability_feature_only

Failure:

• Error: timed out connecting to exec-server websocket \ws://172.17.0.2:...\

Repro

Environment:

• Debian 13 (Linux)
• Docker daemon running
• CODEX_TEST_REMOTE_ENV set to a test container

Observed direct connectivity probe:

• exec-server started in container and printed ws://0.0.0.0:<port>
• container IP from docker inspect was 172.17.0.2
• host TCP probe to that IP/port failed: tcp_connect=fail

Root cause hypothesis

The remote test harness assumes host->container connectivity via Docker bridge container IP (docker inspect ... .IPAddress).
That assumption does not hold on all valid Linux host setups.

Validated fix

Using host-network container mode for the remote test env, plus localhost fallback when container IP is empty, makes the upstream test pass repeatedly.

Tested change:

• scripts/test-remote-env.sh: run remote env with docker run --network host ...
• codex-rs/core/tests/common/test_codex.rs: when container IP is empty, fall back to 127.0.0.1
• commit: https://github.com/rebroad/codex/commit/2226d95df
• branch: https://github.com/rebroad/codex/tree/upstream-latest-alpha-cli-hostnet-only-fix

Validation outcome:

• 3/3 passes for the target test with the host-network fix.

Request

Could upstream harden remote-env test setup so it does not assume host->bridge IP routing from Docker? This currently causes false-negative failures unrelated to feature behavior.