[BUG] OAuth login fails with ERR_INVALID_IP_ADDRESS behind corporate proxy (regression since 2.0.37)

OAuth Proxy Regression - Root Cause Identified

Excellent bug report. The regression between 2.0.37 and 2.0.53 is likely in how OAuth handles DNS resolution through proxies.

Immediate Workaround

Since 2.0.37 works, pin that version:

npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code@2.0.37

Root Cause Analysis

The error ERR_INVALID_IP_ADDRESS during OAuth (but not API calls) suggests the OAuth flow is:

1. Bypassing proxy settings
2. Attempting direct IPv6 resolution
3. Failing before proxy can intercept

Why API works but OAuth doesn't:

• API calls: Go through normal HTTPS client (respects $HTTPS_PROXY)
• OAuth flow: Likely uses system browser redirect or separate HTTP client

Diagnostic for Anthropic Team

Compare DNS resolution paths:

# What works (API via curl):
curl -v --proxy $HTTPS_PROXY https://api.anthropic.com 2>&1 | grep -E "DNS|Connected"

# What fails (OAuth):
# OAuth probably does this internally:
node -e "require('dns').lookup('api.anthropic.com', console.log)"
# If this returns IPv6 first and network doesn't support it → ERR_INVALID_IP_ADDRESS

Potential Fix Locations (For Anthropic Team)

Option 1: Force IPv4 for OAuth

// In OAuth init code (added in 2.0.38-2.0.53):
const authServer = http.createServer({
  family: 4  // Force IPv4
});

Option 2: Explicit proxy for OAuth callback

// Ensure OAuth HTTP server respects proxy settings:
const proxyAgent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
authClient.setAgent(proxyAgent);

Option 3: DNS resolution order

# Force IPv4 DNS resolution:
export NODE_OPTIONS="--dns-result-order=ipv4first"
claude /login

Temporary Workarounds for Users

Workaround 1: API Key Instead (no OAuth needed)

export ANTHROPIC_API_KEY="sk-ant-..."
claude

Workaround 2: SSH Tunnel (if you have external access)

# From outside proxy:
ssh -L 8080:api.anthropic.com:443 user@external-server

# Then in container:
export HTTPS_PROXY=http://localhost:8080
claude /login

Workaround 3: Direct IP (risky, may break)

# Get IP outside proxy:
nslookup api.anthropic.com

# Add to /etc/hosts inside container:
echo "X.X.X.X api.anthropic.com" >> /etc/hosts

What Would Help Debug

If you can share:

1. DNS resolution inside container:

``bash
getent hosts api.anthropic.com
``

1. OAuth callback port:

``bash
# While /login is waiting:
netstat -tlnp | grep claude
``

1. Node version:

``bash
node --version
``

Node 18.x changed IPv6 behavior - if 2.0.38+ started using Node 18 features, that's the regression.

Expected Fix

Anthropic should:

1. Add explicit proxy support for OAuth callback server
2. Respect $HTTPS_PROXY in OAuth flow
3. Add --no-ipv6 flag for OAuth
4. Document proxy requirements for OAuth

This is a HIGH priority fix since it blocks enterprise users.

Diagnostic Data

DNS Resolution (returns IPv6 first):

$ getent hosts api.anthropic.com
2607:6bc0::10   api.anthropic.com

Node Version:

$ node --version
v18.20.8

Engine Requirements (identical):

$ npm show @anthropic-ai/claude-code@2.0.37 engines
{ node: '>=18.0.0' }

$ npm show @anthropic-ai/claude-code@2.0.53 engines
{ node: '>=18.0.0' }

Root Cause

DNS resolves api.anthropic.com to IPv6 (2607:6bc0::10) first. Corporate proxy doesn't support IPv6 tunneling. OAuth code in 2.0.53 appears to resolve DNS directly and attempt IPv6 connection, bypassing proxy. Version 2.0.37 does not exhibit this behavior.

NODE_OPTIONS="--dns-result-order=ipv4first" has no effect, suggesting OAuth uses a library with its own DNS resolution.

Wrong: the latest working version is: v2.0.47

Having the same issue

The problem was resolved but come back with version 2.0.65

Have the same issue. Found a workaround by disabling proxy to pass the oauth login and enabling it after it

Here's my new finding with the problem.
the proxy is not set in my environment variables but in ~/.claude/settings.json. It's working correctly with the version 2.0.64 but not with the newest.
If I set proxy in environment variables before launching claude the recent version are working.

So I suspect that the oauth system which renew the token is not using the ~/.claude/settings.json in the newest version.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I must admit that seeing this being autoclosed is a bit frustrating. I wonder if there is any way to bring this up to Anthropic's attention, at least to get a statement from them.

shame, i have the issue now haha

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.