gh 2.100.0 fails HTTPS requests with an instant connection reset

首先，使用 gh auth login 和 gh api 针对 github.com 和 example.com，在 gh 2.100.0 和 2.89.0 上复现该故障，并在需要时提供 GH_DEBUG=api 输出。比较两个版本之间的 HTTPS 行为，并在报告中的企业网络上验证结果；完成的标准是请求成功且不会发生连接重置，同时保留使用 curl 时观察到的行为。

Describe the bug

On our network (corporate, some TLS/traffic inspection in the path), gh 2.100.0 fails every HTTPS request with an instant connection reset — auth, api calls, everything. gh 2.89.0 works fine, same machine, same network, tested side by side in the same minute to rule out the network just being flaky.

Not GitHub-specific — 2.100.0 fails the same way against other hosts (e.g. example.com). curl sending the identical request succeeds. So something changed in the client between these versions that this network's middlebox doesn't like — not a GitHub API issue, and probably not a universal break for everyone on 2.100.0, since a lot more people would be reporting this if it were.

Affected version

gh version 2.100.0 (2026-09-03)

Works fine on 2.89.0. Confirmed by running both binaries back-to-back on the same machine/network/minute — 2.100.0 fails 3/3, 2.89.0 succeeds 3/3.

Steps to reproduce the behavior

1. gh auth login --hostname github.com --git-protocol https --web --scopes repo
2. Approve the browser prompt
3. See error

Same thing on token-based login and plain gh api calls.

Expected vs actual behavior

Expected: login/API calls work like they do on 2.89.0.

Actual: instant connection reset, ~50ms in, on every request.

Logs

$ gh auth login --hostname github.com --git-protocol https --web --scopes repo
failed to authenticate via web browser: Post "https://github.com/login/device/code": read tcp 10.23.41.14:55833->140.82.113.4:443: read: connection reset by peer

$ gh auth login --hostname github.com --git-protocol https --scopes repo
error validating token: Get "https://api.github.com/": read tcp 10.23.41.14:56184->140.82.113.6:443: read: connection reset by peer

$ GH_TOKEN=<redacted> gh api --hostname example.com /
Get "https://example.com/api/v3/": read tcp 10.23.41.14:56609->104.20.23.154:443: read: connection reset by peer

curl with the same headers/token/UA against the same host works fine:

$ curl -H "Authorization: token <redacted>" https://api.github.com/
401

macOS, arm64, corporate network with some traffic inspection appliance in the path. Happy to grab GH_DEBUG=api output or a packet capture if useful — flagging that this may be specific to whatever's inspecting traffic on our network rather than a universal 2.100.0 break, since I couldn't find other reports pinned to this exact version.