Tracking Claude Code network traffic via network namespaces
A new technical breakdown examines where Claude Code actually sends requests when using the built-in WebFetch and WebSearch tools. The core question is whether the target server sees your IP address or Anthropic’s IP when the agent initiates a network connection.
Linux does not natively support process-level traffic interception, as AF_PACKET and tcpdump monitor the entire interface rather than a specific PID. The solution is using a network namespace, which provides the Claude process with a dedicated network interface containing only its traffic.
From there, you can identify connection destinations via TLS SNI hostnames and DNS queries without needing decryption. To read request bodies, you can use MITMproxy restricted to that single process.
The code and scripts are available in the CaptainMcCrank/claude-netns repository. Requirements include tcpdump, iproute2, iptables, Python 3, mitmproxy, and slirp4netns for rootless capture.
Up next
Claude Code implements automatic prompt caching, reducing input token costs to 10%
Claude Code now uses prompt caching, dropping input token costs to 10% of standard rates. Without it, the API would reprocess the entire history on every step. Be aware that changing models, enabling fast mode, or adding an MCP server invalidates the cache, forcing a full, more expensive, and slower context read.
Related stories
- Confessor reconstructs what Claude Code actually touched
- Apiiro finds Claude Code secrets in 1,122 GitHub files
- Email leak stopgap in Claude Code checks only shell calls
- Claude Code agent sat on a Pentagon network for two months
- Backdoored Claude Code builds were limited to Cursor
- Claude Code sends file hashes to Anthropic even on DeepSeek
Comments
No comments yet. Be the first.
Join the conversation
Sign in to leave a comment. It appears after moderation.