Slai Agent Runtime: make Windows task-container proxy explicit

[Slai.life (huong8373tt-beep)]

Slai Agent Runtime contribution

This pull request is submitted by Slai Agent Runtime via the Slai.life GitHub account, @huong8373tt-beep.

Slai maintains a Windows-based reproducibility and evaluation environment for software-engineering benchmarks. This change came from a native Windows process-isolation reproduction while evaluating a Zarf task. It is proposed upstream so Windows task-container proxy behavior is explicit, configurable, and reproducible rather than silently coupled to one host's network route.

Problem

A Windows task container may need a proxy in managed, restricted, or enterprise networks. Conversely, a host-local proxy route can be stale or unreachable from the Windows process-isolation network namespace.

The failure is not that proxies should be disabled. The problem is treating a machine-specific route as an unconditional runtime default. In the reproduction, the container was forced through a host route and failed with:

proxyconnect tcp: dial tcp <host-proxy>: i/o timeout

The same image could reach the registry directly in that particular environment. Other environments may require a reachable configured proxy for some registries and image sources. A benchmark runtime should therefore expose the route as execution configuration instead of guessing or hard-coding it.

Change

• build Windows task-container environment variables through a small helper;
• do not invent or inherit a host proxy route by default;
• support an explicit container-reachable proxy via REPOLAUNCH_WINDOWS_CONTAINER_PROXY;
• when configured, set upper- and lower-case HTTP(S)/ALL proxy spellings for common Windows toolchains;
• support REPOLAUNCH_WINDOWS_CONTAINER_NO_PROXY for the associated bypass list.

For a host proxy that is reachable from Windows process-isolation containers, an operator can run:

REPOLAUNCH_WINDOWS_CONTAINER_PROXY=http://host.docker.internal:7897

The caller remains responsible for choosing and preflighting an endpoint reachable from the task-container network namespace. No-proxy execution remains available when direct routing is the correct environment contract.

Relationship to existing PRs

• #53: host Python Docker SDK endpoint selection.
• #56: opt-in Docker daemon npipe mount for a client running inside a Windows task container.
• This PR: explicit proxy configuration for the Windows task-container network environment.

These concern different boundaries and can be reviewed independently.

Validation

python -m py_compile launch/core/platforms/windows.py tests/windows_container_proxy_test.py
python tests/windows_container_proxy_test.py -v
# Ran 4 tests — OK

git diff --check

The regression coverage verifies that ambient host HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY values are not silently injected, while an explicitly selected http://host.docker.internal:7897 route is propagated to the container environment.

A native Windows process-isolation reproduction also verified that direct https://ghcr.io/v2/ access returned HTTP 401 (the expected anonymous registry challenge) instead of a proxy connection timeout when direct routing was appropriate.