You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: gh api .../actions/artifacts/{id}/zip and gh run download fail inside the agent sandbox under network-isolation mode with error connecting to productionresultssaN.blob.core.windows.net.
Context: Reported in github/gh-aw#54371. Reproduced on gh-aw-firewall 0.27.44 and 0.28.1, gh-aw-mcpg v0.4.8/v0.4.9.
Root Cause: Two independent, non-interacting design decisions:
gh-aw-mcpg PR #10350 stopped auto-following the GitHub 302 redirect for artifact ZIP requests, so gh (running inside cli-proxy) must follow the Location header itself.
Since mcpg now expects the client to follow the redirect, but cli-proxy has no route to productionresultssa*.blob.core.windows.net, every ZIP download fails in ~350ms.
Proposed Solution: Either (a) allow cli-proxy to route the specific redirect target through Squid (e.g., proxy the blob storage domain via the existing DIFC/mcpg tunnel or a scoped egress rule for *.blob.core.windows.net), or (b) have cli-proxy's gh wrapper detect the 302 and re-issue the download through Squid's domain-allowlisted path instead of a direct connection. Coordinate with gh-aw-mcpg since both sides changed independently.
Problem:
gh api .../actions/artifacts/{id}/zipandgh run downloadfail inside the agent sandbox under network-isolation mode witherror connecting to productionresultssaN.blob.core.windows.net.Context: Reported in github/gh-aw#54371. Reproduced on gh-aw-firewall 0.27.44 and 0.28.1, gh-aw-mcpg v0.4.8/v0.4.9.
Root Cause: Two independent, non-interacting design decisions:
gh-aw-mcpgPR #10350 stopped auto-following the GitHub 302 redirect for artifact ZIP requests, sogh(running inside cli-proxy) must follow theLocationheader itself.cli-proxy(cli-proxy-service.ts) is intentionally isolated toawf-netonly (noawf-extegress) per PR Fix cli-proxy ENETUNREACH in network-isolation mode by dual-homing it on the external bridge #7066, which reverted general egress and added a regression test enforcing isolation.Since mcpg now expects the client to follow the redirect, but cli-proxy has no route to
productionresultssa*.blob.core.windows.net, every ZIP download fails in ~350ms.Proposed Solution: Either (a) allow cli-proxy to route the specific redirect target through Squid (e.g., proxy the blob storage domain via the existing DIFC/mcpg tunnel or a scoped egress rule for
*.blob.core.windows.net), or (b) have cli-proxy'sghwrapper detect the 302 and re-issue the download through Squid's domain-allowlisted path instead of a direct connection. Coordinate with gh-aw-mcpg since both sides changed independently.