Feature: auto-detect Windows system proxy with smart fallback ("proxy": "auto")

[fantuan812]

Area

Proxy and routing

What are you trying to accomplish?

I run opencodex as a Windows background service and switch VPN/proxy tools frequently. Today every proxy change (new port, proxy restart, rule change) silently breaks all upstream requests with 502 Provider unreachable until I manually edit ~/.opencodex/config.json and restart the service. I need opencodex to follow the Windows system proxy automatically — including falling back to direct when the proxy is down — so outbound routing keeps working with zero manual maintenance.

What prevents this today?

config.proxy accepts only a static URL (or ${ENV_VAR} reference) that is mirrored into HTTP_PROXY/HTTPS_PROXY once at process start (applyProxyEnv). There is no way to express "use whatever the system proxy is right now":

• a hardcoded URL goes stale the moment the proxy tool changes ports or restarts;
• service-managed instances (Task Scheduler / launchd / systemd) never inherit shell-level HTTP_PROXY exports;
• on my network OpenAI endpoints (chatgpt.com) are only reachable through the proxy, while opencode.ai is only reliably reachable via a different route — so "always proxy" and "never proxy" are both wrong as static choices;
• the only current workaround is an external watchdog script that rewrites config and restarts the service, which races with the running proxy's in-memory config and only works for interactive installs.

What should OpenCodex do?

When config.proxy is the special value "auto", opencodex should:

1. Read the Windows system proxy (HKCU\...\Internet Settings ProxyEnable/ProxyServer) at startup and apply it immediately, so the first outbound request already works;
2. verify the candidate proxy against upstream targets (e.g. chatgpt.com, opencode.ai) — any HTTP status < 500 counts as reachable;
3. fall back to direct connection when the proxy is unreachable, and keep the last known proxy when both routes fail, with a clear log line in each case;
4. re-check every ~60 seconds and apply changes live, without a restart (Bun re-reads HTTP_PROXY/HTTPS_PROXY per request).

Existing behavior must stay backward compatible: static proxy URLs and ${ENV_VAR} references keep working, user-set HTTP_PROXY/HTTPS_PROXY env vars still win, and NO_PROXY loopback defaults remain appended. On non-Windows platforms auto mode should degrade to direct.

Example usage or interface

{
  "proxy": "auto"
}


Before/after: with "proxy": "http://127.0.0.1:7890" and the proxy tool switched to port 7893, every request fails with 502 Provider unreachable. With "proxy": "auto", the service picks up 7893 from the registry within 60 seconds (or falls back to direct) and requests succeed again — no config edits, no restarts.

### Alternatives or workarounds

_No response_

### Additional context

_No response_

### Checks

- [x] I searched existing issues and documentation.
- [x] This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
- [x] I removed secrets and personal data.

[Ingwannu]

This is a useful Windows service feature request, but the proposed behavior needs a narrower contract before implementation. Reading ProxyEnable/ProxyServer alone does not cover PAC/WPAD or per-scheme proxy rules, and changing process environment variables at runtime is not a reliable per-request routing abstraction. Automatic direct fallback can also bypass an operator's intended proxy boundary.\n\nA mergeable design should resolve the Windows proxy per outbound request (or through a reloadable dispatcher), define HTTP/HTTPS/PAC behavior, preserve NO_PROXY, and make direct fallback an explicit policy rather than an unconditional default. Health checks also need destination-specific semantics and must not send credentials while probing.\n\nI am leaving this open as an enhancement. A focused first slice would be startup-time WinINET static-proxy discovery behind proxy: auto, with clear logs and no live mutation/direct fallback; dynamic refresh and PAC support can follow after the request transport boundary is proven.

[lidge-jun]

리뷰 · 우선순위 60 / 80

Windows 백그라운드 서비스에서 VPN/프록시 도구가 포트를 바꿀 때마다 502 Provider unreachable이 나고, config.json을 고치고 재시작해야 하는 요청입니다. proxy 값을 auto로 두면 시스템 프록시를 따르고, 프록시가 죽으면 다이렉트로 떨어지길 바랍니다. 서비스 수명과 직결됩니다.

현재 dev의 src/types.ts proxy 필드는 정적 URL 또는 환경 변수 참조만 설명합니다. src/config.ts applyProxyEnv()는 resolveEnvValue(config.proxy)를 HTTP_PROXY/HTTPS_PROXY에 한 번 넣고, 사용자 env가 있으면 이깁니다. localhost는 NO_PROXY에 붙습니다. auto 토큰, 레지스트리 읽기, 60초 재검사, 도달성 폴백은 이 함수에 없습니다.

서비스/스케줄러로 뜬 프로세스는 셸의 HTTP_PROXY를 못 물려받습니다. doctor와 readiness 힌트도 그 점을 이미 말합니다. 어떤 호스트는 프록시가 필요하고 어떤 호스트는 다이렉트가 필요해서, 항상 프록시/항상 다이렉트 정적 선택은 둘 다 틀릴 수 있습니다.

해결방안: proxy가 auto일 때만 Windows Internet Settings를 읽고, 시작 시 바로 적용한 뒤 주기적으로 다시 보면 됩니다. 프록시가 500 미만으로 응답하면 쓰고, 안 되면 다이렉트, 둘 다 실패하면 마지막 값을 유지하면 됩니다. 정적 URL과 사용자 env, NO_PROXY 기본은 그대로 두어야 합니다. 비Windows auto는 다이렉트로 떨어지면 됩니다. 레지스트리 키 파싱 세부 패치는 여기서 추측하지 않음.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Landed the first slice on dev via #3209 (squash 5bc6939d8), scoped as the review above asked.

What shipped: "proxy": "auto" reads the Windows static proxy (WinINET ProxyEnable/ProxyServer, https= then http= entry) once at process start and mirrors it into HTTP_PROXY/HTTPS_PROXY when those are unset, logging only the proxy host. Existing environment variables still win; on other platforms, or when the system proxy is off, SOCKS-only, or unreadable, it says so once and uses direct egress. Static URLs, ${ENV} references, noProxy, and loopback NO_PROXY are unchanged.

What this does not do yet, on purpose: follow PAC/WPAD, honor ProxyOverride, re-check every 60 s, probe reachability, or fall back to direct when the proxy is down. Live mutation of process environment is not a reliable per-request routing abstraction, and an automatic direct fallback can bypass an operator's proxy boundary, so those need a request-transport seam and an explicit policy first. For the port-switch case in the report, a service restart after changing the proxy picks up the new value. If you want the dynamic slice, a fresh issue that proposes the reloadable dispatcher and the fallback policy is the right next step.