Describe the feature or problem you'd like to solve

Many GitHub Enterprise Server deployments sit behind authentication gateways or reverse proxies that require additional custom HTTP headers on every request — beyond the standard Authorization: token <PAT> header that gh already sends.

A common pattern is:

Client → Auth Gateway (checks custom header) → GitHub Enterprise Server (checks Authorization header)

Without the custom header, the gateway blocks the request before it ever reaches the GitHub Enterprise Server, making gh unusable for these environments.

Today, there is no way to configure gh to send additional HTTP headers for all commands. The -H flag only applies to gh api, so commands like gh pr, gh issue, gh repo, etc. are completely blocked.

Git itself supports this natively via http.<url>.extraHeader, which is widely used in enterprise environments. However, gh does not read or forward these headers.

Proposed solution

Add per-host custom HTTP header support via gh config. For example:

# ~/.config/gh/hosts.yml
github.example.com:
    user: username
    oauth_token: ghp_xxx
    http_headers:
        X-Custom-Auth: "bearer <token>"

Or via environment variable for scripting/CI:

GH_EXTRA_HEADERS="X-Custom-Auth:bearer <token>"

Implementation approach:

The existing architecture in api/http_client.go already uses a composable RoundTripper middleware pattern (AddAuthTokenHeader, AddCacheTTLHeader, ExtractHeader). A new AddCustomHeaders middleware could be added to the chain in pkg/cmd/factory/default.go — scoped per host to avoid leaking headers to unintended destinations.

Key requirements:

• Headers must only be sent to the matching host (not leaked on redirects to other hosts)
• Standard github.com usage must remain unaffected
• Backwards compatible — no behavior change without explicit configuration