[awf] awf-cli-proxy: 5-run failure cluster — DIFC proxy unreachable due to IPv4/IPv6 mismatch

[lpcox]

Problem: A failure cluster of 5 runs across 3 workflows (PR Sous Chef ×3, Issue Monster, Daily Code Metrics) was killed with 0 token usage and 0 agent turns — the agent was never invoked. All failures share the same signature: awf-cli-proxy cannot reach the host DIFC proxy at host.docker.internal:18443.

Context: github/gh-aw#38201. Window: ~6h on 2026-06-09. Engine-agnostic (Copilot and Claude both affected). Distinct from #37989 (auth failure at turn 1 — this never reaches the agent).

Root Cause: The awf-cli-proxy sidecar resolves localhost to IPv6 [::1] on dual-stack hosts, but the DIFC proxy only listens on IPv4 0.0.0.0:18443. With a 2-retry fail-fast, the sidecar exits before the agent container can start. The agent depends_on the cli-proxy container being healthy, so the whole workflow is aborted.

Proposed Solution:

1. Fix start_cli_proxy.sh to probe 127.0.0.1 explicitly instead of localhost.
2. Alternatively, bind the DIFC proxy on :: (dual-stack) to accept both [::1] and 127.0.0.1.
3. Increase retry count from 2 to ≥10 with exponential backoff.
4. Improve error messages to distinguish "proxy unreachable" from "proxy not yet ready" for faster triage.

Generated by Firewall Issue Dispatcher · 380.5 AIC · ⊞ 27.8K · ◷

[github-actions]

👋 Hello! I noticed this issue might be a duplicate of an existing open issue:

• [awf] awf-cli-proxy: IPv4/IPv6 readiness probe mismatch causes fail-fast on dual-stack hosts #4656 — [awf] awf-cli-proxy: IPv4/IPv6 readiness probe mismatch causes fail-fast on dual-stack hosts

Both issues describe the same root cause: start_cli_proxy.sh resolves localhost to IPv6 [::1] on dual-stack hosts, while the DIFC proxy only listens on IPv4 0.0.0.0:18443, causing the readiness probe to fail with ECONNREFUSED and aborting the workflow before the agent starts. Both propose the same fixes (use 127.0.0.1 explicitly, increase retry count, improve diagnostics), and both appear to have been filed by the same automated workflow run at nearly the same time.

If #4656 covers your concern, please consider closing this issue as a duplicate. Otherwise, feel free to clarify how this issue differs!

This is an automated message from the issue duplication detector.

Generated by Issue Duplication Detector for issue #4657 · 63 AIC · ⊞ 32.9K · ◷

[lpcox]

Resolved by #4626 and #4675 (both merged):

• Fix cli-proxy TCP tunnel localhost binding on IPv6-enabled runners #4626 — Binds the TCP tunnel on both IPv4 and IPv6 loopback, eliminating the dual-stack mismatch
• fix(cli-proxy): resolve IPv4/IPv6 readiness probe mismatch on dual-stack hosts #4675 — Probes via explicit 127.0.0.1 (not localhost), binds server on :: (dual-stack), and increases liveness attempts from 2→10 with exponential backoff (1s, 2s, 4s, 8s… capped at 30s)

These directly address the IPv4/IPv6 mismatch root cause and the 2-retry fail-fast described in this issue.