bug: DIFC proxy returns 404 for GHES API paths (/api/graphql, /api/v3/...)

[lpcox]

Summary

The DIFC proxy (mcpg) returns HTTP 404 when the gh CLI sends requests using GHES-style API paths (/api/graphql for GraphQL, /api/v3/... for REST). This breaks all pre-agent gh CLI steps in agentic workflows running on GitHub Enterprise Server (GHES).

Reproduction

1. Deploy an agentic workflow on a GHES instance (e.g., copilot-api.verizon.ghe.com)
2. The compiled lock file runs configure_gh_for_ghe.sh then start_difc_proxy.sh, which starts mcpg on localhost:18443 and redirects gh CLI traffic through it
3. Any gh CLI command that makes an API call (e.g., gh issue list) sends a request to https://localhost:18443/api/graphql
4. mcpg returns 404 Not Found

Error Output

HTTP 404: 404 Not Found (https://localhost:18443/api/graphql)
Error: Process completed with exit code 1.

This occurs at the "Fetch repo data for task weighting" step, which runs gh issue list before the agent starts.

Root Cause

On github.com, the gh CLI sends GraphQL requests to https://api.github.com/graphql (path: /graphql). On GHES, the gh CLI sends them to https://<ghes-host>/api/graphql (path: /api/graphql). Similarly, REST calls use /api/v3/repos/... on GHES vs /repos/... on github.com.

When start_difc_proxy.sh redirects gh to localhost:18443, the gh CLI retains the GHES path format. The mcpg proxy apparently only routes github.com-style paths (/graphql, /repos/...) and does not recognize the /api/ prefix used by GHES.

Expected Behavior

mcpg should handle both path formats:

• /graphql → forward to upstream (github.com style)
• /api/graphql → forward to upstream (GHES style)
• /api/v3/... → forward to upstream (GHES REST style)

Or more generally, mcpg should be GHES-aware when GITHUB_SERVER_URL is not https://github.com.

Affected Workflow

• Workflow: repo-assist (from githubnext/agentics)
• Lock file compiled with gh-aw v0.68.3, awf containers v0.25.20, mcpg v0.2.19
• Customer: GHES instance using copilot-api.verizon.ghe.com

Workaround

None clean. The failing step runs before the agent and uses ${{ github.token }}, so it does not strictly need DIFC proxy enforcement. A possible workaround is to stop and restart the DIFC proxy around pre-agent gh calls, or bypass the proxy for those steps.