Summary
The Agent Workflow Firewall (AWF) reports its own internal MCP Gateway sidecar hostname (awmg-mcpg, logged/sanitized as awmgmcpg) as a blocked domain in the ⚠️ Firewall blocked N domain(s) warning that gets appended to every issue/PR a workflow creates via safe-outputs — even though this traffic is gh-aw's own internal container-to-container communication, not a missing external dependency. The warning is spurious noise on every single run and cannot currently be suppressed.
Environment
gh-aw compiler: v0.82.14 (pinned in the affected repo's lock files; confirmed still present through at least v0.83.3, the latest release as of this report — no intervening release notes mention a fix)gh-aw-firewall: v0.27.37- MCP Gateway (
ghcr.io/github/gh-aw-mcpg): v0.4.1
- Engine:
copilot
- Repo:
tenstorrent/tt-metal (public)
Observed noise (real examples, same warning on every run, across two independent workflows)
Each shows the identical block:
Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
awmgmcpg
To allow these domains, add them to the network.allowed list in your workflow frontmatter:
network:
allowed:
- defaults
- "awmgmcpg"
See Network Configuration for more information.
Why the suggested remediation in the warning itself doesn't work
We tried following the warning's own instructions and adding awmgmcpg to network.allowed. It fails because:
awmgmcpg is a bare hostname (no dot) — the compiler (v0.82.14) rejects it outright as neither a valid domain nor a recognized ecosystem identifier.- The gateway's actual transport,
host.docker.internal, is already present in the compiled defaults allowlist (confirmed in the generated awf-config.json — "network":{"allowDomains":[...,"host.docker.internal",...],"isolation":true,"topologyAttach":["awmg-mcpg"]}), so there is nothing left to allowlist. The block is generated from the topologyAttach sidecar name itself, not from an actual unresolved/unauthorized external domain.
We ended up documenting this as a known, unfixable-from-userland cosmetic issue directly in the workflow frontmatter (see tenstorrent/tt-metal PR tenstorrent/tt-metal#50963), and added agent instructions telling the LLM not to copy the warning block into its own follow-up comments. That only stops double-posting by the agent — it does not remove the warning gh-aw itself appends to the primary issue/PR body, which is unconditional and framework-generated, not agent-generated.
Suspected code path (from repo inspection via DeepWiki, may be imprecise)
getBlockedDomains / generateBlockedDomainsSection in firewall_blocked_domains.cjs — builds the warning section for the safe-outputs summary/footer.parseFirewallLogLine / analyzeFirewallLogLines in parse_firewall_logs.cjs — parses AWF logs and appears to surface the topologyAttach sidecar (awmg-mcpg) as if it were an ordinary blocked external domain.
Suggested fix
Either:
- Exclude hostnames present in the workflow's own
network.topologyAttach (internal sidecars gh-aw itself wires up, e.g. the MCP Gateway) from the "blocked domains" reporting entirely, since by definition they are framework-internal and were never meant to be user-allowlistable, or
- If
awmgmcpg/awmg-mcpg really is being blocked at the network layer (not just over-reported), fix the AWF config generation so the MCP Gateway sidecar's actual required hostname is included in allowDomains automatically whenever topologyAttach references it, so the block doesn't happen in the first place.
Either way, users should not need to add framework-internal plumbing to their own network.allowed list, and should not see a permanent, unfixable "Warning" on every generated issue/PR for a component they don't control.
Impact
Low severity (cosmetic), but high visibility: it appears on every single issue/PR created by every gh-aw workflow we run in this repo (daily-repo-status, repo-assist), which trains maintainers to ignore all "Firewall blocked" warnings — masking real, actionable ones if they ever occur.
Summary
The Agent Workflow Firewall (AWF) reports its own internal MCP Gateway sidecar hostname (
awmg-mcpg, logged/sanitized asawmgmcpg) as a blocked domain in the⚠️ Firewall blocked N domain(s)warning that gets appended to every issue/PR a workflow creates via safe-outputs — even though this traffic is gh-aw's own internal container-to-container communication, not a missing external dependency. The warning is spurious noise on every single run and cannot currently be suppressed.Environment
gh-awcompiler:v0.82.14(pinned in the affected repo's lock files; confirmed still present through at leastv0.83.3, the latest release as of this report — no intervening release notes mention a fix)gh-aw-firewall:v0.27.37ghcr.io/github/gh-aw-mcpg):v0.4.1copilottenstorrent/tt-metal(public)Observed noise (real examples, same warning on every run, across two independent workflows)
daily-repo-statusworkflow, 2026-07-25daily-repo-status, 2026-07-23daily-repo-status, 2026-07-22daily-repo-status, 2026-07-21repo-assistworkflow, 2026-07-25 (created after a dedicated fix attempt, see below — warning still present)Each shows the identical block:
Why the suggested remediation in the warning itself doesn't work
We tried following the warning's own instructions and adding
awmgmcpgtonetwork.allowed. It fails because:awmgmcpgis a bare hostname (no dot) — the compiler (v0.82.14) rejects it outright as neither a valid domain nor a recognized ecosystem identifier.host.docker.internal, is already present in the compileddefaultsallowlist (confirmed in the generatedawf-config.json—"network":{"allowDomains":[...,"host.docker.internal",...],"isolation":true,"topologyAttach":["awmg-mcpg"]}), so there is nothing left to allowlist. The block is generated from thetopologyAttachsidecar name itself, not from an actual unresolved/unauthorized external domain.We ended up documenting this as a known, unfixable-from-userland cosmetic issue directly in the workflow frontmatter (see
tenstorrent/tt-metalPR tenstorrent/tt-metal#50963), and added agent instructions telling the LLM not to copy the warning block into its own follow-up comments. That only stops double-posting by the agent — it does not remove the warning gh-aw itself appends to the primary issue/PR body, which is unconditional and framework-generated, not agent-generated.Suspected code path (from repo inspection via DeepWiki, may be imprecise)
getBlockedDomains/generateBlockedDomainsSectioninfirewall_blocked_domains.cjs— builds the warning section for the safe-outputs summary/footer.parseFirewallLogLine/analyzeFirewallLogLinesinparse_firewall_logs.cjs— parses AWF logs and appears to surface thetopologyAttachsidecar (awmg-mcpg) as if it were an ordinary blocked external domain.Suggested fix
Either:
network.topologyAttach(internal sidecars gh-aw itself wires up, e.g. the MCP Gateway) from the "blocked domains" reporting entirely, since by definition they are framework-internal and were never meant to be user-allowlistable, orawmgmcpg/awmg-mcpgreally is being blocked at the network layer (not just over-reported), fix the AWF config generation so the MCP Gateway sidecar's actual required hostname is included inallowDomainsautomatically whenevertopologyAttachreferences it, so the block doesn't happen in the first place.Either way, users should not need to add framework-internal plumbing to their own
network.allowedlist, and should not see a permanent, unfixable "Warning" on every generated issue/PR for a component they don't control.Impact
Low severity (cosmetic), but high visibility: it appears on every single issue/PR created by every gh-aw workflow we run in this repo (
daily-repo-status,repo-assist), which trains maintainers to ignore all "Firewall blocked" warnings — masking real, actionable ones if they ever occur.