Summary
After upgrading a repo's workflows from a v0.81.6-compiled lock to v0.82.13 (mcpg v0.4.1, firewall 0.27.35), the Copilot agent can no longer reach the MCP gateway. Squid inside the awf sandbox returns 403 TCP_DENIED for the internal gateway host awmg-mcpg, so no MCP servers register. The agent then reports Tool 'github' does not exist and falls back to gh/curl (both blocked), so the run does nothing useful.
The gateway itself is healthy — its own host-side health check reports github: running / safeoutputs: running and the step goes green — which hides the failure. The break is only on the sandboxed Copilot CLI → gateway hop, which is proxied through Squid.
Evidence (real run)
Run: https://github.com/dotnet/aspnetcore/actions/runs/29740734721 (job agent), engine copilot/1.0.70, GH_AW_VERSION: v0.82.13.
Copilot process log:
[ERROR] Starting remote MCP client for github with url: http://awmg-mcpg:8080/mcp/github
[ERROR] Failed to start MCP client for remote server github: ... HTTP 403 Forbidden ...
The requested URL could not be retrieved: http://awmg-mcpg:8080/mcp/github ... Access Denied. (squid/6.14)
[ERROR] Failed to start MCP client for remote server safeoutputs: ... HTTP 403 Forbidden ...
Firewall Squid audit log (sandbox/firewall/logs/access.log):
awmg-mcpg:8080 POST 403 TCP_DENIED:HIER_NONE http://awmg-mcpg:8080/mcp/github "copilot/1.0.70 (linux v24.16.0)"
awmg-mcpg:8080 POST 403 TCP_DENIED:HIER_NONE http://awmg-mcpg:8080/mcp/safeoutputs "copilot/1.0.70 (linux v24.16.0)"
Agent stdio:
✗ github tool: "get_issue", input: "{"owner": "dotnet", "repo": "aspnetcore", ...}"
└ Tool 'github' does not exist.
The generated squid.conf allowed_domains ACL contains only the external allow-list; the internal gateway host awmg-mcpg is not in it, and it is not NO_PROXY'd, so the proxied POSTs are denied.
What changed between v0.81.6 and v0.82.13 (same lock file, diff)
|
v0.81.6 (mcpg v0.3.30) |
v0.82.13 (mcpg v0.4.1) |
| gateway network |
docker run --network host --name awmg-mcpg |
docker run --network bridge -p 127.0.0.1:8080:8080 --name awmg-mcpg |
| awf |
sudo -E awf ... (rootful) |
awf ... (rootless) |
awf-config network |
no isolation |
"isolation":true,"topologyAttach":["awmg-mcpg"] |
So topologyAttach: ["awmg-mcpg"] is meant to make the gateway reachable from the isolated sandbox, but it neither adds awmg-mcpg to the Squid allow-list nor bypasses the proxy for it — the agent→gateway MCP traffic is denied.
Impact
Any Copilot-engine workflow using the firewall + MCP gateway on v0.82.x loses all MCP tools (github and safeoutputs), silently (job still succeeds). PAT/token wiring is fine and not the cause.
Environment
- gh-aw /
GH_AW_VERSION: v0.82.13 (regressed from v0.81.6)
- mcpg:
v0.4.1 (was v0.3.30) · firewall: 0.27.35 (was 0.27.11)
- engine: Copilot CLI
1.0.70
- GitHub-hosted
ubuntu runner, public repo
Expected
The sandboxed agent should be able to reach the internal MCP gateway awmg-mcpg:8080 (via NO_PROXY or a Squid allow rule for the topology-attached host) so github/safeoutputs MCP servers register.
Summary
After upgrading a repo's workflows from a
v0.81.6-compiled lock tov0.82.13(mcpgv0.4.1, firewall0.27.35), the Copilot agent can no longer reach the MCP gateway. Squid inside theawfsandbox returns403 TCP_DENIEDfor the internal gateway hostawmg-mcpg, so no MCP servers register. The agent then reportsTool 'github' does not existand falls back togh/curl(both blocked), so the run does nothing useful.The gateway itself is healthy — its own host-side health check reports
github: running/safeoutputs: runningand the step goes green — which hides the failure. The break is only on the sandboxed Copilot CLI → gateway hop, which is proxied through Squid.Evidence (real run)
Run:
https://github.com/dotnet/aspnetcore/actions/runs/29740734721(jobagent), enginecopilot/1.0.70,GH_AW_VERSION: v0.82.13.Copilot process log:
Firewall Squid audit log (
sandbox/firewall/logs/access.log):Agent stdio:
The generated
squid.confallowed_domainsACL contains only the external allow-list; the internal gateway hostawmg-mcpgis not in it, and it is not NO_PROXY'd, so the proxied POSTs are denied.What changed between v0.81.6 and v0.82.13 (same lock file, diff)
docker run --network host --name awmg-mcpgdocker run --network bridge -p 127.0.0.1:8080:8080 --name awmg-mcpgsudo -E awf ...(rootful)awf ...(rootless)network"isolation":true,"topologyAttach":["awmg-mcpg"]So
topologyAttach: ["awmg-mcpg"]is meant to make the gateway reachable from the isolated sandbox, but it neither addsawmg-mcpgto the Squid allow-list nor bypasses the proxy for it — the agent→gateway MCP traffic is denied.Impact
Any Copilot-engine workflow using the firewall + MCP gateway on
v0.82.xloses all MCP tools (github and safeoutputs), silently (job still succeeds). PAT/token wiring is fine and not the cause.Environment
GH_AW_VERSION: v0.82.13 (regressed from v0.81.6)v0.4.1(wasv0.3.30) · firewall:0.27.35(was0.27.11)1.0.70ubunturunner, public repoExpected
The sandboxed agent should be able to reach the internal MCP gateway
awmg-mcpg:8080(via NO_PROXY or a Squid allow rule for the topology-attached host) sogithub/safeoutputsMCP servers register.