Description
Copilot CLI v1.0.12 hangs on startup (and on any prompt/init) when DNS returns an IPv6 AAAA record for api.individual.githubcopilot.com that has no route. The bundled Node.js SEA binary's fetch (undici) does not fall back to IPv4, unlike system Node.js which handles this gracefully via Happy Eyeballs.
The CLI appears to work (login succeeds, Octokit API calls return 200), but the MCP server connection and model listing retry with exponential backoff (5s → 10s → 20s → 40s → 80s) across 5 attempts, making the CLI unusable for ~2.5 minutes before failing.
Root cause
- DNS returns both A (IPv4) and AAAA (IPv6) records for
api.individual.githubcopilot.com
- IPv6 is unroutable on the current network (e.g. mobile hotspot)
curl -6 https://api.individual.githubcopilot.com/ → No route to hostcurl -4 https://api.individual.githubcopilot.com/ → works (404, as expected)- System Node.js
fetch('https://api.individual.githubcopilot.com/...') → works (falls back to IPv4)
- Copilot CLI SEA binary →
TypeError: fetch failed (no fallback)
Because the binary is a Node.js Single Executable Application, NODE_OPTIONS="--dns-result-order=ipv4first" has no effect.
Environment
- OS: macOS 15 (Darwin 25.3.0), Apple Silicon
- Copilot CLI: 1.0.12 (Homebrew cask)
- Bundled Node.js: v24.11.1
- Network: iPhone hotspot (no IPv6 routing) + DNS resolver that returns AAAA records
Logs
From ~/.copilot/logs/:
[ERROR] Starting remote MCP client for github-mcp-server with url: https://api.individual.githubcopilot.com/mcp/readonly
[ERROR] Creating MCP client for github-mcp-server...
[ERROR] Connecting MCP client for github-mcp-server...
[ERROR] Error making GitHub API request: AggregateError
[WARNING] Retrying request to GitHub API in 5 seconds. Attempt 1/5
[ERROR] MCP transport for github-mcp-server closed
[ERROR] Failed to start MCP client for remote server github-mcp-server: TypeError: fetch failed
Note: Octokit requests to api.github.com succeed (200) in the same session — only fetch()-based requests to api.individual.githubcopilot.com fail.
Workaround
Disable any DNS resolver that returns AAAA records for the Copilot API endpoint (in my case, disabling Tailscale MagicDNS).
Adding an /etc/hosts entry for IPv4 does not help because getaddrinfo still returns the IPv6 address from DNS alongside the /etc/hosts IPv4 entry.
Suggested fix
The SEA binary should use Happy Eyeballs (RFC 6555/8305) or --dns-result-order=ipv4first so that an unroutable IPv6 address doesn't prevent connection over IPv4. System Node.js v24 already handles this correctly — the issue is specific to the bundled undici in the SEA build.
Description
Copilot CLI v1.0.12 hangs on startup (and on any prompt/init) when DNS returns an IPv6 AAAA record for
api.individual.githubcopilot.comthat has no route. The bundled Node.js SEA binary'sfetch(undici) does not fall back to IPv4, unlike system Node.js which handles this gracefully via Happy Eyeballs.The CLI appears to work (login succeeds, Octokit API calls return 200), but the MCP server connection and model listing retry with exponential backoff (5s → 10s → 20s → 40s → 80s) across 5 attempts, making the CLI unusable for ~2.5 minutes before failing.
Root cause
api.individual.githubcopilot.comcurl -6 https://api.individual.githubcopilot.com/→No route to hostcurl -4 https://api.individual.githubcopilot.com/→ works (404, as expected)fetch('https://api.individual.githubcopilot.com/...')→ works (falls back to IPv4)TypeError: fetch failed(no fallback)Because the binary is a Node.js Single Executable Application,
NODE_OPTIONS="--dns-result-order=ipv4first"has no effect.Environment
Logs
From
~/.copilot/logs/:Note: Octokit requests to
api.github.comsucceed (200) in the same session — onlyfetch()-based requests toapi.individual.githubcopilot.comfail.Workaround
Disable any DNS resolver that returns AAAA records for the Copilot API endpoint (in my case, disabling Tailscale MagicDNS).
Adding an
/etc/hostsentry for IPv4 does not help becausegetaddrinfostill returns the IPv6 address from DNS alongside the/etc/hostsIPv4 entry.Suggested fix
The SEA binary should use Happy Eyeballs (RFC 6555/8305) or
--dns-result-order=ipv4firstso that an unroutable IPv6 address doesn't prevent connection over IPv4. System Node.js v24 already handles this correctly — the issue is specific to the bundled undici in the SEA build.