Telemetry disabled by overzealous GHES host detection on non-GitHub API requests

[williammartin]

Problem

The telemetryDisablerTransport in api/http_client.go:165-170 checks every outgoing HTTP request with ghauth.IsEnterprise(host). If the host is not github.com, it calls telemetryDisabler.Disable(), which permanently disables telemetry for the entire CLI invocation.

func (t telemetryDisablerTransport) RoundTrip(req *http.Request) (*http.Response, error) {
    if ghauth.IsEnterprise(getHost(req)) {
        t.telemetryDisabler.Disable()
    }
    return t.wrappedTransport.RoundTrip(req)
}

Several commands make legitimate HTTP requests to non-GitHub hosts through the factory HTTP client, triggering this check incorrectly.

Affected commands

Command	Non-GitHub Host	How
gh cs ports forward/list/visibility	global.rel.tunnels.api.visualstudio.com	Dev-tunnels API for port management
gh cs ssh	global.rel.tunnels.api.visualstudio.com	Dev-tunnels API for SSH tunnel
gh cs logs	global.rel.tunnels.api.visualstudio.com	Dev-tunnels API for log streaming
gh cs jupyter	global.rel.tunnels.api.visualstudio.com	Dev-tunnels API for Jupyter forwarding
gh cs rebuild	global.rel.tunnels.api.visualstudio.com	Dev-tunnels API for rebuild connection
gh api <full-url>	Any host	User can pass arbitrary URLs
gh attestation download/verify/inspect	Bundle URLs	Fetches attestation bundles directly
gh extension install/upgrade	Release asset URLs	Downloads from asset.APIURL

How to reproduce

GH_TELEMETRY=log gh cs ports forward 3000:3000
# ctrl+c after ports are forwarded (requires signal handler fix from #13401)
# Output: "Telemetry payload: none"

Impact

All codespace tunnel commands produce zero telemetry even for github.com users. The gh api command also loses telemetry whenever a user passes a full non-GitHub URL.

Possible fixes

1. Allowlist known non-GitHub hosts - skip the enterprise check for known hosts like visualstudio.com
2. Only check on GitHub API requests - only run the enterprise check when the request is to a host that looks like a GitHub API endpoint
3. Check the configured host instead of request host - the intent is to detect GHES users, which is already done by mightBeGHESUser() at startup. The transport-level check could be removed or narrowed to only trigger on hosts that match the configured GH_HOST or auth hosts

References

• api/http_client.go:160-170 - telemetryDisablerTransport
• internal/ghcmd/cmd.go:88 - mightBeGHESUser() (startup check)
• internal/ghcmd/cmd.go:103-104 - telemetryService.Disable() (startup disable)

[babakks]

I think another solution, which involves deeper investigation, is to limit the use of f.HttpClient to GitHub API calls. There's no reason to use the same HTTP client for non-GH calls.

[eyupcanakman]

Looked into this.

GHES detection already runs once at startup via mightBeGHESUser(), so the per-request IsEnterprise check in telemetryDisablerTransport is redundant and fires on unrelated hosts. Option 3 (drop or narrow the transport-level check) would fix the reported commands without touching the github.com telemetry path.

@babakks also mentioned not reusing f.HttpClient for non-GitHub calls. Is the intent here the narrow transport fix, or the larger client split? Either way I'll hold off until it's labeled help wanted.

[williammartin]

GHES detection already runs once at startup via mightBeGHESUser(), so the per-request IsEnterprise check in telemetryDisablerTransport is redundant and fires on unrelated hosts

This isn't true. There are commands that accept hostname either via flags or arguments where mightBeGHESUser is not true, for example gh api https://my.ghes.com/api/v3 or gh api --hostname my.ghes.com /user

I agree we should probably have a different http client though.

[eyupcanakman]

You're right, I missed the flag/arg hostname case. The per-request check has to stay, so non-GitHub calls go to their own client and the telemetry transport stays on the GitHub one.