[BUG] DISABLE_TELEMETRY flag ignored - Claude Code connects to Google despite opt-out

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code establishes persistent connections to Google LLC infrastructure (IP range 142.250.0.0/15) despite having DISABLE_TELEMETRY=YES explicitly set in the environment.

Observable behavior:

• Connections to Google IPs occur every 10-30 seconds
• Approximately 300-400 connections per hour to 142.251.x.x:443 (Google LLC)
• Connections continue regardless of telemetry opt-out configuration
• All Google IPs resolve to .1e100.net domain (Google infrastructure)
• No influence

Current connection (live capture at 2025-10-28 09:49 CET):

$ ss -tunap 2>/dev/null | grep 142.251 | grep ESTAB
tcp   ESTAB    0      289    10.2.0.2:47448 → 142.251.97.207:443   users:(("claude",pid=25575,fd=20))

IP ownership verified:

$ whois 142.251.97.207 | grep -E "NetName|OrgName"
NetName:        GOOGLE
OrgName:        Google LLC

Telemetry setting confirmed active:

$ env | grep DISABLE_TELEMETRY
DISABLE_TELEMETRY=YES
HF_HUB_DISABLE_TELEMETRY=1

### What Should Happen?

When `DISABLE_TELEMETRY=YES` is set in the environment, Claude Code should:
1. **Not establish (non-essential) connections to third-party services** (including Google)
2. Only connect to essential Anthropic infrastructure (api.anthropic.com)
3. Honor the user's explicit opt-out preference

The expected behavior is that telemetry opt-out prevents ALL non-essential network connections, not just some services.

### Error Messages/Logs

```shell
- NEW: 142.251.22.207:443 - users:(("claude",pid=41468,fd=19))
- NEW: 142.251.22.207:443 - users:(("claude",pid=25575,fd=18))
- NEW: 142.251.22.207:443 - users:(("claude",pid=25575,fd=18))
- NEW: 142.251.22.207:443 - users:(("claude",pid=25575,fd=18))
- NEW: 142.251.22.207:443 - users:(("claude",pid=25575,fd=18))
- NEW: 142.251.22.207:443 - users:(("claude",pid=25575,fd=18))
- NEW: 142.251.97.207:443 - users:(("claude",pid=25575,fd=20))
- NEW: 142.251.97.207:443 - users:(("claude",pid=25575,fd=20))

Steps to Reproduce

1. Set telemetry opt-out:

``bash
export DISABLE_TELEMETRY=YES
``

1. Launch Claude Code:

``bash
claude
``

1. Monitor network connections in another terminal:

``bash
# Watch for Google connections
watch -n 1 'ss -tunap 2>/dev/null | grep claude | grep -E "142\.251"'
``

1. Verify telemetry flag is set:

``bash
env | grep DISABLE_TELEMETRY
``

1. Observe: Connections to 142.251.x.x (Google LLC) appear despite opt-out flag

Verification commands (anyone can reproduce):

# Check active Google connections
ss -tunap 2>/dev/null | grep 142.251 | grep ESTAB

# Verify IP ownership
whois 142.251.97.207 | grep -E "NetName|OrgName"

# Reverse DNS lookup
dig +short -x 142.251.26.207
# Output: hz-in-f207.1e100.net. (Google infrastructure)

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.28 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Additional Information

Functionality Impact: Google Connections Are Non-Essential

Critical finding: Blocking ALL Google connections (both IPv4 and IPv6) via firewall causes ZERO functional degradation:

# Block both IPv4 and IPv6 Google ranges
sudo iptables -I OUTPUT -d 142.250.0.0/15 -m owner --uid-owner $(id -u) -j REJECT
sudo ip6tables -I OUTPUT -d 2a00:1450::/32 -m owner --uid-owner $(id -u) -j REJECT

Tested and verified: With both IPv4 and IPv6 Google blocked:

• ✅ Chat functionality: Works perfectly
• ✅ Tool execution (Read, Write, Edit, Bash): Works perfectly
• ✅ File operations: Works perfectly
• ✅ Code generation: Works perfectly
• ✅ Git operations: Works perfectly
• ✅ All core features: 100% functional

Conclusion: This proves Google connections are completely non-essential for Claude Code operation. The application functions identically with or without Google access.

Multiple Google IPs Observed

All resolve to Google infrastructure:

• 142.251.22.207 → ye-in-f207.1e100.net
• 142.251.26.207 → hz-in-f207.1e100.net
• 142.251.97.207 → yd-in-f207.1e100.net

Process Verification

$ ps aux | grep 25575 | grep -v grep
home  25575  16.3  0.2  74791464  300764  pts/0  Sl+  09:30  1:08  claude

IPv4→IPv6 Fallback Behavior (Suspect Pattern)

Testing revealed active protocol switching:

1. Test setup: Blocked Google IPv4 range only:

``bash
sudo iptables -I OUTPUT -d 142.251.0.0/16 -m owner --uid-owner $(id -u) -j REJECT
``

1. Observed behavior: Claude Code immediately switched to IPv6 within seconds

• IPv4 connection blocked → Application detects block
• Application immediately attempts IPv6 connection to 2a00:1450::/32 (Google IPv6 range)
• Connection re-established to same Google service via IPv6

1. Pattern identified:

``
Normal: App → Try IPv4 → Fail → Error/Degradation
Observed: App → Try IPv4 → BLOCKED → Immediately Try IPv6 → Success
``

Implication: Users cannot block Google connections with IPv4 rules alone - must block both IPv4 AND IPv6, which most users won't know to do.

Related Issues

1. Documentation gap: The Data Usage page documents Statsig and Sentry but does not mention Google Cloud connections
2. DO_NOT_TRACK ignored: The industry-standard DO_NOT_TRACK=1 environment variable is also ignored
3. Dual-stack evasion: Active IPv4→IPv6 fallback makes blocking difficult for average users

Privacy Context

Users who explicitly set DISABLE_TELEMETRY=YES have a reasonable expectation that:

• Non-essential third-party connections will be prevented
• Their opt-out preference will be honored
• Any exceptions would be documented

The current behavior concerns these expectations by:

• Silently connecting to Google despite opt-out
• Not documenting these connections
• Providing no way to prevent them (except firewall blocking)