Skip to content

Copilot MCP tools fail on v0.82.x: Squid denies internal gateway (awmg-mcpg) with 403 TCP_DENIED #46826

Description

@DeagleGross

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions