Back to Blog
December 6, 202515 min readArion Interactive Team

Fixing GitHub Copilot Timeout Issues on WSL2: The IPv6 Problem Explained

Experiencing 60+ second timeouts with GitHub Copilot on WSL2? Learn why IPv6 routing causes this issue and how to fix it permanently with a simple kernel parameter.

WSL2GitHub CopilotIPv6TroubleshootingVS CodeNode.js
Fixing GitHub Copilot Timeout Issues on WSL2: The IPv6 Problem Explained

If you're using GitHub Copilot on WSL2 and experiencing frustrating 60+ second connection timeouts, you're not alone. This is a widespread issue affecting thousands of developers, and the culprit is an unexpected one: IPv6 routing in WSL2. This comprehensive guide explains why this happens and provides step-by-step solutions to fix it permanently.

The Problem: What You're Experiencing

You've installed GitHub Copilot in VS Code on WSL2, but every time you try to use it:

  • Long delays: Copilot takes 60+ seconds to start suggesting code
  • Frequent timeouts: "GitHub Copilot could not connect" errors
  • Inconsistent behavior: Sometimes it works, sometimes it doesn't
  • Normal network works: Your browser, curl commands, and other tools work fine

You've tried:

  • Reinstalling the Copilot extension
  • Restarting VS Code and WSL2
  • Checking your internet connection
  • Verifying your Copilot subscription

Yet the problem persists. The issue isn't with your setup, GitHub's servers, or your internet—it's a fundamental bug in how WSL2 handles IPv6 routing combined with Node.js networking behavior.

Understanding the Root Cause

The IPv6 Routing Bug in WSL2

WSL2 has a known, unresolved bug with IPv6 networking:

What's happening:

  • WSL2 configures IPv6 addresses but doesn't properly set up routing tables
  • IPv6-mapped IPv4 addresses (like 64:ff9b::8c52:7015) become unreachable
  • The Linux kernel thinks IPv6 is available, but packets never reach their destination
  • There's no error—just silent timeouts

Why Microsoft hasn't fixed it:
WSL2 uses a lightweight virtual machine with Hyper-V networking. The IPv6 implementation has edge cases that are difficult to handle without major architecture changes. Microsoft is aware of this issue (tracked on GitHub), but no fix has been released as of 2025.

Node.js Dual-Stack DNS Behavior

Node.js (which powers VS Code extensions) follows RFC 6555 (Happy Eyeballs):

The intended behavior:

  1. DNS query returns both IPv4 and IPv6 addresses
  2. Node.js attempts IPv6 connection first (if available)
  3. If IPv6 fails quickly, it falls back to IPv4
  4. Total connection time should be under 1 second

What actually happens in WSL2:

  1. DNS returns api.github.com → IPv6: 64:ff9b::8c52:7015, IPv4: 140.82.112.21
  2. Node.js tries IPv6 first
  3. Due to WSL2 routing bug, connection hangs (no immediate error)
  4. Node.js waits for TCP timeout (60-75 seconds)
  5. GitHub Copilot extension times out before IPv4 fallback happens
  6. Connection fails with "could not connect" error

Why curl Works But Copilot Doesn't

You might notice curl https://api.github.com works instantly. Why?

curl's smart fallback:

  • curl implements aggressive connection timeout (typically 2-5 seconds)
  • Quickly detects IPv6 failure and tries IPv4
  • Completes in under 1 second total

Node.js fetch/https module:

  • Follows TCP timeout specs (60+ seconds)
  • Waits patiently for IPv6 connection
  • Extension timeout fires before IPv4 attempt

VS Code/Copilot Extension:

  • Has built-in timeout (usually 30-45 seconds)
  • Gives up before Node.js completes IPv4 fallback
  • Results in connection failure

Step-by-Step Reproduction

Let's reproduce this issue to understand it better.

Step 1: Verify IPv6 is Enabled in WSL2

# Check if IPv6 is loaded
ip -6 addr show
# You'll see inet6 addresses

# Check IPv6 routing table
ip -6 route show
# Output shows routes, but they're broken

Step 2: Test DNS Resolution

# GitHub API DNS lookup
nslookup api.github.com

Expected output:

Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name:    api.github.com
Address: 140.82.112.21
Name:    api.github.com
Address: 64:ff9b::8c52:7015

Notice both IPv4 and IPv6 addresses are returned.

Step 3: Test IPv6 Connectivity

# Try to ping GitHub via IPv6
ping6 -c 4 api.github.com

Result: This will either timeout or show "Destination unreachable"—confirming IPv6 routing is broken.

Step 4: Test IPv4 Connectivity

# Force IPv4 connection with curl
curl -4 -w "@-" -o /dev/null -s "https://api.github.com" <<'EOF'
time_namelookup:  %{time_namelookup}s\n
time_connect:     %{time_connect}s\n
time_total:       %{time_total}s\n
EOF

Result: Completes in under 1 second—IPv4 works perfectly.

Step 5: Simulate Node.js Behavior

Create a test script:

// test-copilot-connection.js
const https = require('https');

console.time('GitHub API Request');

https.get('https://api.github.com', (res) => {
  console.timeEnd('GitHub API Request');
  console.log('Status:', res.statusCode);
  res.resume();
}).on('error', (err) => {
  console.timeEnd('GitHub API Request');
  console.error('Error:', err.message);
});

// Set a timeout to see the issue
setTimeout(() => {
  console.log('Still waiting after 30 seconds...');
}, 30000);

Run it:

node test-copilot-connection.js

Result: Takes 60+ seconds to complete—replicates the Copilot timeout issue.

Step 6: Watch Network Attempts

In another terminal, watch connection attempts:

sudo tcpdump -i eth0 host api.github.com

Run the Node.js test again. You'll see:

  1. IPv6 SYN packets sent
  2. No response (packets lost in WSL2 routing)
  3. Long pause
  4. Eventually IPv4 connection succeeds

The Solution: Disable IPv6 in WSL2 Kernel

The most effective solution is disabling IPv6 at the kernel level so Node.js never attempts IPv6 connections.

Method 1: Kernel Parameter (Recommended)

Step 1: Create or edit WSL configuration

On Windows, create/edit C:\Users\YourUsername\.wslconfig:

[wsl2]
kernelCommandLine = ipv6.disable=1

Step 2: Shutdown WSL completely

Open PowerShell or Command Prompt:

wsl --shutdown

Wait 10 seconds, then restart your WSL distribution.

Step 3: Verify IPv6 is disabled

# This should show no inet6 addresses
ip -6 addr show

# This should return empty or error
ip -6 route show

Step 4: Test Node.js connection

node test-copilot-connection.js

Result: Completes in under 1 second! 🎉

Step 5: Test GitHub Copilot

Open VS Code in WSL2, try Copilot suggestions. They should appear instantly.

Method 2: Sysctl Configuration (Alternative)

If you can't or don't want to use kernel parameters:

Create sysctl config:

sudo tee /etc/sysctl.d/99-disable-ipv6.conf > /dev/null <<EOF
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
EOF

Apply settings:

sudo sysctl -p /etc/sysctl.d/99-disable-ipv6.conf

Verify:

cat /proc/sys/net/ipv6/conf/all/disable_ipv6
# Should output: 1

Method 3: Hosts File Override (Quick Fix)

For immediate testing without system changes:

# Add IPv4-only entry for GitHub API
echo "140.82.112.21 api.github.com" | sudo tee -a /etc/hosts

Limitations: Only works for specific domains, not a comprehensive solution.

Verification & Testing

Test 1: DNS Resolution

nslookup api.github.com

Expected: Only IPv4 address returned.

Test 2: Copilot Connection Speed

Open VS Code, start typing in a file:

Before fix: 60+ seconds for first suggestion
After fix: Suggestions appear in 1-2 seconds

Test 3: Extension Host Log

VS Code → Output → Extension Host

Before:

[Extension Host] Timeout connecting to GitHub Copilot

After:

[Extension Host] GitHub Copilot connected successfully

Why This Fix Works

With ipv6.disable=1:

  1. Kernel doesn't load IPv6 module → No IPv6 stack available
  2. DNS queries return IPv4 only → Node.js doesn't see IPv6 addresses
  3. Node.js connects via IPv4 immediately → No timeout, no fallback needed
  4. Copilot connects in <1 second → Normal, expected behavior

Impact on Your System

What you lose:

  • IPv6 connectivity (which was broken anyway in WSL2)
  • Potential future IPv6-only services (rare in WSL2 use cases)

What you gain:

  • Fast, reliable connections for all Node.js applications
  • GitHub Copilot works instantly
  • npm/yarn package installations faster
  • All VS Code extensions that use Node.js https work better

Important: This only affects WSL2. Your Windows host still has IPv6 enabled and working normally.

Alternative Workarounds

If you can't disable IPv6 for some reason:

1. Use Copilot on Windows (not WSL)

Install VS Code on Windows and use Remote-SSH or Remote-WSL from Windows side. The Windows network stack doesn't have this issue.

2. Force IPv4 in Node.js

Set environment variable:

echo 'export NODE_OPTIONS="--dns-result-order=ipv4first"' >> ~/.bashrc
source ~/.bashrc

Limitation: Only affects applications that respect NODE_OPTIONS.

3. Use VPN or Proxy

Some VPNs disable IPv6 or route through IPv4-only tunnels, inadvertently fixing the issue.

Common Questions

Q: Will Microsoft fix this?
A: It's tracked on GitHub Issues, but no ETA. WSL2's networking architecture makes this difficult to fix without breaking changes.

Q: Does this affect WSL1?
A: No. WSL1 uses different networking (shares Windows network stack) and doesn't have this issue.

Q: Will disabling IPv6 break anything?
A: Highly unlikely in WSL2. Most services have IPv4 fallback, and WSL2's IPv6 was already non-functional.

Q: Why don't other tools (curl, wget) have this issue?
A: They implement more aggressive timeouts and faster IPv4 fallback than Node.js.

Q: Can I re-enable IPv6 later?
A: Yes, just remove the ipv6.disable=1 line from .wslconfig, run wsl --shutdown, and restart.

Conclusion

The GitHub Copilot timeout issue on WSL2 is a perfect storm of three problems:

  1. WSL2's broken IPv6 routing
  2. Node.js's patient dual-stack connection behavior
  3. GitHub serving both IPv4 and IPv6 addresses

By disabling IPv6 at the kernel level with ipv6.disable=1, you eliminate the root cause and restore normal, fast connectivity. This isn't a hack—it's working around a known WSL2 limitation that Microsoft hasn't yet resolved.

Thousands of developers have applied this fix successfully. It's simple, safe, and dramatically improves the WSL2 development experience for any Node.js-based tooling, not just GitHub Copilot.

Ready to fix your setup? Follow the steps above, and get back to productive coding with instant Copilot suggestions!

At Arion Interactive, we encounter and solve complex development environment issues daily. This experience helps us build robust applications that work reliably across different environments. Need help optimizing your development workflow? Let's talk!