Context: How AWF api-proxy handles GHEC tenants today
The AWF firewall api-proxy sidecar (containers/api-proxy/server.js) has built-in GHEC tenant detection via deriveCopilotApiTarget(). When GITHUB_SERVER_URL points to a *.ghe.com tenant, it auto-derives the correct endpoints:
GITHUB_SERVER_URL=https://mycompany.ghe.com
→ Copilot inference: copilot-api.mycompany.ghe.com
→ GitHub REST API: api.mycompany.ghe.com
→ Copilot telemetry: copilot-telemetry-service.mycompany.ghe.com
The AWF CLI (src/cli.ts) also auto-populates the firewall domain allowlist with all four GHEC subdomains when it detects a *.ghe.com server URL, and auto-injects GH_HOST=<tenant>.ghe.com into the agent environment so that gh CLI targets the correct instance.
For GHES (non-ghe.com, non-github.com), Copilot traffic routes to api.enterprise.githubcopilot.com.
Priority order for Copilot API target:
- Explicit
COPILOT_API_TARGET env var (or --copilot-api-target flag)
- Auto-derived from
GITHUB_SERVER_URL
- Default:
api.githubcopilot.com
Concern: MCP Gateway also needs GHEC awareness
When the MCP gateway proxies requests for tools like gh CLI and actions/github-script, those requests target the GitHub REST API — which on GHEC tenants lives at api.<subdomain>.ghe.com, not api.github.com.
If the MCP gateway hardcodes or assumes api.github.com as the GitHub API base, GHEC tenant workflows will fail when:
gh CLI makes API calls (e.g., listing PRs, creating issues)
actions/github-script runs Octokit requests
- Any MCP tool that calls the GitHub REST or GraphQL API
What needs to work
For a GHEC tenant like mycompany.ghe.com:
gh api /repos/{owner}/{repo}/pulls → https://api.mycompany.ghe.com/repos/...
- GraphQL endpoint →
https://api.mycompany.ghe.com/graphql
- Copilot models →
https://copilot-api.mycompany.ghe.com/...
Questions
- Does the MCP gateway currently read
GITHUB_SERVER_URL / GITHUB_API_URL / GH_HOST to determine the correct API base?
- If the MCP gateway routes traffic through AWF's Squid proxy, the GHEC domains are already in the allowlist — but does the gateway itself construct the correct upstream URL?
- For GHES instances (e.g.,
github.mycompany.com), the REST API is at api.github.mycompany.com — is this handled?
Reference
Context: How AWF api-proxy handles GHEC tenants today
The AWF firewall api-proxy sidecar (
containers/api-proxy/server.js) has built-in GHEC tenant detection viaderiveCopilotApiTarget(). WhenGITHUB_SERVER_URLpoints to a*.ghe.comtenant, it auto-derives the correct endpoints:The AWF CLI (
src/cli.ts) also auto-populates the firewall domain allowlist with all four GHEC subdomains when it detects a*.ghe.comserver URL, and auto-injectsGH_HOST=<tenant>.ghe.cominto the agent environment so thatghCLI targets the correct instance.For GHES (non-ghe.com, non-github.com), Copilot traffic routes to
api.enterprise.githubcopilot.com.Priority order for Copilot API target:
COPILOT_API_TARGETenv var (or--copilot-api-targetflag)GITHUB_SERVER_URLapi.githubcopilot.comConcern: MCP Gateway also needs GHEC awareness
When the MCP gateway proxies requests for tools like
ghCLI andactions/github-script, those requests target the GitHub REST API — which on GHEC tenants lives atapi.<subdomain>.ghe.com, notapi.github.com.If the MCP gateway hardcodes or assumes
api.github.comas the GitHub API base, GHEC tenant workflows will fail when:ghCLI makes API calls (e.g., listing PRs, creating issues)actions/github-scriptruns Octokit requestsWhat needs to work
For a GHEC tenant like
mycompany.ghe.com:gh api /repos/{owner}/{repo}/pulls→https://api.mycompany.ghe.com/repos/...https://api.mycompany.ghe.com/graphqlhttps://copilot-api.mycompany.ghe.com/...Questions
GITHUB_SERVER_URL/GITHUB_API_URL/GH_HOSTto determine the correct API base?github.mycompany.com), the REST API is atapi.github.mycompany.com— is this handled?Reference
containers/api-proxy/server.jsderiveCopilotApiTarget()src/cli.tsextractGhecDomainsFromServerUrl()src/docker-manager.tsextractGhHostFromServerUrl()