[copilot-opt] Enforce MCP-only GitHub API access to prevent firewall-blocked direct `gh` CLI calls

[github-actions]

Problem

Copilot agents are attempting to call api.github.com directly via the gh CLI (gh repo view, gh pr list, etc.) instead of routing through the GitHub MCP server. This violates the documented requirement in AGENTS.md ("Copilot cannot access api.github.com — use GitHub MCP tools") and hits the sandbox firewall, causing blocked-connection warnings embedded in PR bodies. The agent continues past the failure and produces a PR with degraded quality due to missing GitHub context.

Evidence

• Analysis window: 2026-04-06 to 2026-04-20 (14 days)
• Sessions analyzed: 50 workflow runs, 1000 PRs cross-referenced
• Key metrics and examples:
  • PR copilot/add-latex-ecosystem-group contains a > [!WARNING] block: "Firewall rules blocked me from connecting to one or more addresses" with https://api.github.com/graphql as the blocked target
  • Triggering command logged: /usr/bin/gh gh repo view --json owner,name — a direct gh CLI call that bypasses MCP
  • The agent completed the PR despite the firewall block, producing a result with incomplete GitHub context
  • Pattern: agent uses gh CLI for GitHub reads instead of configured tools.github MCP toolset, even though toolsets: [default] is already in scope per project conventions
  • This can silently degrade output quality without causing outright task failure, making it a recurring hidden cost

Proposed Change

• Add an early network validation step in the Copilot coding agent workflow that asserts gh api / direct api.github.com calls are absent from agent tool traces; emit a clear error if detected
• Add a RULES.md snippet or AGENTS.md callout that explicitly instructs agents: "Never call gh api or gh repo view — always use MCP github tools for all GitHub reads"
• Consider blocking api.github.com at the MCP gateway level with an informative error message pointing to the correct MCP toolset, so the agent receives actionable feedback rather than a generic firewall block

Expected Impact

• Eliminate silent GitHub-context degradation in PRs where direct API calls are blocked mid-session
• Provide earlier, clearer feedback to the agent when it drifts toward direct API usage, reducing wasted tool cycles
• Prevent firewall-block warnings from appearing in PR bodies, improving output quality signal-to-noise ratio

Notes

• Distinct root cause category: prompt drift / incorrect tool selection for GitHub API access
• Data quality caveats: Only one confirmed firewall-block instance was directly observable in PR bodies. Actual frequency may be higher if the agent silently recovers from blocked calls without logging warnings. Full events.jsonl data (unavailable in this run) would confirm tool-call selection patterns across all sessions.

Generated by Copilot Opt · ● 1.3M · ◷