[part 1] Overview

[part 2] Isolating Claude’s traffic with network namespaces

[part 3] Extracting hostnames from encrypted traffic

[part 4] Decrypting HTTPS with a MITM proxy

[part 5] Classifying all of Claude’s network connections & Analyzing traffic by category

In part 3, we explored pulling hostnames from an encrypted session. In this post, we’ll crack some TLS.

Decrypting HTTPS with a MITM proxy

The hostname extraction helped us discover where scraping is launching from. WebFetch connects directly to target websites from your machine. But hostnames alone don’t reveal what Claude sends in those requests: the HTTP headers, the User-Agent string, the exact URL paths, or the response bodies it receives. To see the full content of Claude’s network traffic and understand exactly what target servers receive and what data flows back, we need to decrypt the TLS.

How MITM proxying works

We use a Man-in-the-Middle (MITM) proxy to read the plaintext content of claude’s HTTPS requests and responses. The proxy sits between claude and the target server, terminating TLS on both sides so it can read the traffic in between:

claude ──TLS──► mitmproxy ──TLS──► example.com
         ▲           │
         │      reads plaintext
         │      request & response
         │
  trusts proxy's CA
  (NODE_EXTRA_CA_CERTS)

1. Claude connects to mitmproxy (thinking it’s the real server)
2. mitmproxy presents a certificate it generated on-the-fly, signed by its own CA
3. Claude accepts this certificate because we told Node.js to trust that CA
4. mitmproxy reads the plaintext request
5. mitmproxy connects to the real server and forwards the request
6. The real server responds; mitmproxy reads the response
7. mitmproxy forwards the response back to claude

mitmproxy now has a complete plaintext transcript of every HTTP request and response.

Example analogy:

A MITM proxy is like a bilingual translator at a diplomatic meeting. Both sides think they’re talking directly to each other, but the translator sits in the middle, receiving every message, reading it, and forwarding it. The key requirement: each side must trust the translator’s credentials. If either side refuses to accept the translator, the communication fails.

Where this analogy breaks down: A real translator can only work if both parties agree to use one. In MITM proxying, the server doesn’t agree to anything. It sees a normal TLS connection from the proxy’s IP address. Only the client must be tricked (or, in our case, explicitly configured) into accepting the proxy’s certificates, so you only need to modify the client’s trust configuration, not the server’s.

Mental Model Check: “MITM is an attack technique.”

MITM interception on a network you don’t control is an attack. MITM proxying on your own machine, for a process you launched, with a CA you generated is a debugging technique. The mechanism is identical for both attacks and debugging. The only difference is authorization context. Burp Suite (penetration testing), Charles Proxy (mobile app debugging), Fiddler (Windows HTTP debugging), and corporate TLS inspection appliances all use the same approach. The claude-mitm.sh script is doing exactly what these tools do, scoped to one process.

Scoping the trust to one process

We scope the trust to one process. We don’t install the mitmproxy CA system-wide. Instead, we set three environment variables only for the claude process:

export HTTPS_PROXY=”http://127.0.0.1:8080″ # Route HTTPS through the proxy
export HTTP_PROXY=”http://127.0.0.1:8080″ # Route HTTP through the proxy
export NODE_EXTRA_CA_CERTS=”$HOME/.mitmproxy/mitmproxy-ca-cert.pem” # Trust the proxy’s CA

Node.js honors both HTTPS_PROXY (route traffic through a proxy) and NODE_EXTRA_CA_CERTS (trust additional CA certificates). These are set only in the shell environment of the claude process. No other process on the system is affected.

We can scope the trust this way because Node.js reads CA certificates from environment variables at startup. That means we can modify the trust configuration of one Node.js process without affecting any other process on the system. If claude were written in Go or Rust, we’d need a different approach. Those runtimes use the system certificate store and don’t honor NODE_EXTRA_CA_CERTS. The environment-variable approach works here specifically because claude is a Node.js application.

Running the MITM capture

Interactive mode (two terminals):

Terminal 1:

./claude-mitm.sh proxy    # Starts mitmweb with web UI at http://127.0.0.1:8081

Terminal 2:

./claude-mitm.sh run      # Launches claude routed through the proxy

Browse to http://127.0.0.1:8081 to see decrypted traffic in real time.

One-shot scripted mode (single command):

./mitm-capture.sh "Use the WebFetch tool to fetch https://example.com and report the title."

This starts mitmdump (the CLI version of mitmproxy) with the mitm_logger.py addon, runs one claude prompt through it, and writes a plaintext transcript to mitm.txt.

Reading the decrypted transcript

grep '^>>> ' mitm.txt    # Every outbound request
less mitm.txt             # Full headers and bodies

Here’s a real captured WebFetch request :

>>> GET https://example.com/
    Accept: text/markdown, text/html, */*
    Accept-Encoding: gzip, compress, deflate, br
    User-Agent: Claude-User (claude-code/2.1.168; +https://support.anthropic.com/)
    Host: example.com
<<< 200 OK  (example.com)
    Content-Type: text/html
    ...
--- response body ---
<!doctype html><html lang="en"><head><title>Example Domain</title>...

What the decrypted traffic reveals

With the TLS removed, we can now see exactly what Claude sends and receives. A few things stand out:

1. User-Agent: WebFetch identifies itself as Claude-User (claude-code/<version>; +https://support.anthropic.com/). Target servers can identify these requests.
2. Content preference: The Accept header lists text/markdown first. claude asks the server for markdown before HTML because markdown is more useful to a language model than raw HTML.
3. Direct connection: The request goes directly to example.com, confirming the SNI evidence from the encrypted traffic analysis. There is no intermediate Anthropic proxy.
4. API calls: You’ll also see POST https://api.anthropic.com/v1/messages. These are the model inference calls containing your prompt, tool results, and the model’s responses.
5. Telemetry: Requests to http-intake.logs.us5.datadoghq.com carrying usage metrics.

Security warning. mitm.txt contains your decrypted API authorization token in plaintext. Look for the Authorization: Bearer sk-ant-... header in every POST to api.anthropic.com. This is your Anthropic API key. It can be used by anyone who obtains it to make API calls billed to your account. The mitm.txt file is .gitignore‘d in the project. Delete it when you’re done: rm mitm.txt. Treat it with the same care as a credential dump.

[part 1] Overview

[part 2] Isolating Claude’s traffic with network namespaces

[part 3] Extracting hostnames from encrypted traffic

[part 4] Decrypting HTTPS with a MITM proxy

[part 5] Classifying all of Claude’s network connections & Analyzing traffic by category

In Part 1, we introduced the idea that coding agents like Claude Code may chose to scrape using a direct request from the host and a proxied request via Anthropic Infrastructure. In this post, we’ll start isolating traffic for an application using namespaces.

Isolating Claude’s traffic with network namespaces

The concept

We use a network namespace to filter out all networking traffic on the host that is unrelated to the claude process. A namespace gives a process its own isolated copy of the Linux network stack. The process in the namespace gets its own interfaces, routing table, iptables rules, and socket space, completely separated from the host. Because claude is the only process inside the namespace, every packet on that namespace’s interface belongs to claude. No filtering or guesswork required.

Example analogy:

Putting the process in a private interrogation room with one-way glass. The process can still make phone calls (network access via NAT), but every call goes through a single monitored line. Nothing else in the building uses that line, so the wiretap is perfectly clean.

Where this analogy breaks down: In a real interrogation room, the person knows they’re being watched. In a network namespace, the process has no way to detect that it’s isolated. It sees a normal network stack with a normal interface and normal routes. The process behaves exactly as it would in the real environment, which means your observations in the namespace are faithful representations of how the process works.

Mental Model Check: “Aren’t namespaces a Docker thing?”

Docker uses namespaces: network namespaces, PID namespaces, mount namespaces, and more. But namespaces are a kernel primitive, not a Docker feature. They’ve existed since Linux 2.6.24 (2008), years before Docker. You can create and manage them directly with ip netns and unshare, no container runtime needed. What we’re doing here is using them at the lowest level (Just the network namespace, nothing else) to get the isolation we need for traffic capture for the process.

The plumbing: veth pairs

We use a veth pair to connect the namespace to the host so claude can still reach the internet. A veth pair is a virtual ethernet cable with two endpoints. Packets entering one end emerge from the other. We place one end inside the namespace (where claude runs) and keep the other end in the host namespace (where we capture). This dedicated link is the only path claude’s traffic can take, which is what makes the capture clean.

Example analogy:

A private FaceTime call between two people. Everything said on the call is only heard by those two participants. No one else’s conversation is mixed in. If you record the call, you capture exactly that conversation and nothing else.

Where this analogy breaks down: A FaceTime call traverses real networks and can suffer latency, jitter, or dropped packets. A veth pair is a kernel data structure where packets pass between the two ends with no measurable delay or loss. It behaves like a direct wire, not a network connection.

┌──────────────────────────┐      ┌──────────────────────────┐
│     Host namespace       │      │    claudesbx namespace   │
│                          │      │                          │
│  ┌──────────────┐        │      │        ┌──────────────┐  │
│  │  veth-host   │◄━━━━━━━╋━━━━━━╋━━━━━━━►│   veth-ns    │  │
│  │ 10.200.1.1   │ veth   │      │  veth  │ 10.200.1.2   │  │
│  └──────┬───────┘ pair   │      │  pair  └──────────────┘  │
│         │                │      │                          │
│   iptables NAT           │      │     claude process       │
│   (MASQUERADE)           │      │     runs here            │
│         │                │      │                          │
│  ┌──────┴───────┐        │      └──────────────────────────┘
│  │  eth0/wlan0  │        │
│  │  (real NIC)  │        │
│  └──────────────┘        │
│                          │
└──────────────────────────┘

We capture at veth-host (the host side of the virtual cable) because every packet claude sends must cross this interface to reach the internet, and no other process’s traffic uses it. That gives us a clean, process-scoped capture with no filtering required.

NAT: Giving the namespace internet access

The namespace gives claude a private IP (10.200.1.2) that doesn’t exist on the real network, so claude can’t reach the internet without help. We set up NAT masquerading to bridge that gap. NAT masquerading is the same mechanism your home router uses for NAT. Outbound packets from 10.200.1.2 get rewritten with the host’s real IP as the source, and return traffic gets translated back. This gives claude full internet access while keeping all its traffic confined to the namespace’s interface where we can capture it.

Three pieces need to be in place for this to work:

1. IP forwarding (sysctl net.ipv4.ip_forward=1) tells the kernel to route between interfaces
2. MASQUERADE rule: rewrite the source IP on outbound packets
3. FORWARD rules: allows traffic to flow between the veth and the real NIC

Mental Model Check: “NAT is just one iptables rule.”

A word of warning: treating NAT as a single iptables rule is a common misconception that causes silent failures. MASQUERADE handles address rewriting, but the kernel won’t route packets between interfaces unless IP forwarding is enabled (net.ipv4.ip_forward), and the default iptables FORWARD policy is often DROP. You need all three: the sysctl, the NAT rule, and the FORWARD ACCEPT rules. Miss any of these changes and the namespace has no connectivity. It drops packets with no error message.

I have a helpful script for creating a network namespace for use with claude called claude-sandbox.sh

claude-sandbox.sh up does the following work, step by step.

Create the namespace an empty, isolated network stack:

ip netns add claudesbx

Create the virtual cable (both ends start in the host namespace)

ip link add veth-host type veth peer name veth-ns

Move one end into the namespace (this is the crucial step)

ip link set veth-ns netns claudesbx

Configure the host side (this becomes the capture point.

ip addr add 10.200.1.1/24 dev veth-host
ip link set veth-host up

Configure the namespace side- this is the process’s gateway

ip netns exec claudesbx ip addr add 10.200.1.2/24 dev veth-ns
ip netns exec claudesbx ip link set veth-ns up
ip netns exec claudesbx ip link set lo up
ip netns exec claudesbx ip route add default via 10.200.1.1

DNS: point the namespace at Cloudflare’s resolver

mkdir -p /etc/netns/claudesbx
echo "nameserver 1.1.1.1" > /etc/netns/claudesbx/resolv.conf

NAT: masquerade namespace traffic out the real interface

sysctl -wq net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.200.1.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i veth-host -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o veth-host -m state --state RELATED,ESTABLISHED -j ACCEPT

Note: The script dynamically detects your uplink interface rather than hardcoding eth0. The actual line is: UPLINK="$(ip route show default | awk '/default/ {print $5; exit}')".

We can configure DNS separately for the namespace because Linux automatically binds /etc/netns/<name>/resolv.conf into it. The kernel’s namespace implementation includes this mount namespace integration, so processes inside the namespace see their own DNS configuration without any explicit mount commands.

Running the capture (privileged path)

This is a two-terminal workflow:

Terminal 1: bring up the namespace and start capturing:

sudo ./claude-sandbox.sh up
sudo ./claude-sandbox.sh sniff    # writes claude.pcap, prints live DNS + TLS SNI

Terminal 2: run claude inside the namespace:

sudo ./claude-sandbox.sh run

Use claude normally Ask it to fetch a URL, run a web search, anything. Watch Terminal 1 for live hostnames. When done:

sudo ./claude-sandbox.sh down     # removes namespace, NAT rules, veth

The rootless alternative

If you don’t want to use sudo, rootless-capture.sh achieves the same isolation using user namespaces:

The rootless-capture script is a helper script that invokes claude and activates packet capture for the namespace without requiring root. You pass it a prompt and it handles orchestrating the creation of the namespace for claude & corresponding packet captures.

 
./rootless-capture.sh "Use WebFetch to fetch https://example.com and tell me the page title."

This creates a user+net+mount namespace as your normal user, attaches slirp4netns for userspace networking, and captures with a custom raw-socket sniffer (nssniff.py).

Why a custom sniffer instead of tcpdump? Inside a --map-root-user namespace, the kernel denies setgroups(). tcpdump insists on dropping privileges at startup (calling setgroups), so it exits without capturing anything. Even with -Z root. nssniff.py opens an AF_PACKET socket and never drops privileges. It writes standard pcap format that any tool can read.

tcpdump’s privilege-dropping behavior is a security feature in normal contexts. It prevents a packet capture process from retaining root powers. But inside a user namespace where setgroups is blocked by design, that security feature becomes a compatibility obstacle. The custom sniffer exists because the “right” behavior in one context is the “broken” behavior in another.

What you now have

Checkpoint: After either path, you have claude.pcap. This is a packet capture containing only claude’s network traffic. This is the foundation everything else builds on.

In Part 3, we’ll explore extracting hostnames of the connection source and destinations from encrypted traffic.

This is an analysis of how Claude Code initiates web scraping requests. You might be surprised to find that claude code could scrape from an API endpoint, or from the host that’s running claude code. In this series, you will learn how to use network namespaces, tcpdump and MITMproxy to isolate a client’s network traffic and experimentally discover whether claude code is scraping content from an api endpoint or from the host that’s running claude code. Code for this project is available at my github.

You installed Claude Code. It ships with built-in network tools (WebFetch & WebSearch) that can reach out to the internet on your behalf. Each use requires your explicit approval (unless you’ve configured auto-approve policies). But here’s the question nobody answers in the documentation:

What exactly does it send and where is it sending requests from?

Inspecting Claude Code’s Network Traffic with Linux Namespaces and MITM Proxying

In the proxied fetch model, the request would route through Anthropic’s servers. The target system sees Anthropic’s IP, and Anthropic’s infrastructure handles the fetched content:

These two models have very different privacy and security implications. Which one does Claude Code actually use? This guide answers that question empirically.

When claude code “searches the web,” whose IP address does the search engine see- yours or Anthropic’s? What telemetry does it send home?

These aren’t hypothetical concerns. If you’re running an AI agent that has built-in network tools on a machine that can reach internal services, you need to know its traffic pattern. This guide shows you how you can discover this behavior directly and what I found during my analysis.

What you’ll learn

By the end of this guide, you’ll be able to:

• Isolate a single process’s network traffic on Linux using network namespaces: this technique ensures you won’t have other process’s packets in the capture
• Extract destination hostnames from encrypted TLS traffic using SNI and DNS metadata
• Decrypt HTTPS traffic for a specific process using MITM proxying with mitmproxy, scoped so only that one process is affected
• Classify all traffic the Claude CLI generates: API calls, web fetches, web searches, telemetry, and MCP connections
• Understand the security implications of a local-fetch model: What it means for your LAN and internal services

Prerequisites

You should be comfortable with:

• Linux terminal and shell scripting
• Basic networking concepts (IP addresses, ports, TCP, DNS)
• What tcpdump does (even if you don’t use it daily)
• What TLS/HTTPS provides (encrypted transport)

You’ll need installed:

• Linux with kernel namespace support (any modern distro)
• tcpdump, iproute2 (ip command), iptables
• Python 3 (for the analysis scripts)
• mitmproxy (pipx install mitmproxy or pip install mitmproxy) for the decryption sections
• The claude CLI on your PATH
• slirp4netns for the rootless approach to collecting packets (available in most distro repos)

git clone git@github.com:CaptainMcCrank/claude-netns.git
cd claude-netns
chmod +x claude-sandbox.sh claude-mitm.sh rootless-capture.sh mitm-capture.sh

Key Concepts Before We Start

This guide relies on Linux networking and TLS concepts that may be unfamiliar or counterintuitive.

There is no per-process packet capture on Linux. Linux’s packet capture mechanism (AF_PACKET) attaches to interfaces, not processes. There is no tcpdump --pid. If you capture on an interface shared by every process on the box, you get everything mixed together. The first half of this guide builds a workaround for this using network namespaces.

HTTPS does not hide all metadata. TLS encrypts the payload. The payload includes the URL path, headers, and body. But the destination hostname leaks in plaintext via the TLS SNI extension in every ClientHello, and DNS queries leak it again via standard unencrypted lookups. You can’t read the content, but you can see where traffic goes. That partial visibility turns out to be enough to answer the most important question (where does WebFetch connect?) without any decryption at all.

MITM proxying is a standard debugging technique. The same TLS interception mechanism used by attackers on hostile networks is used every day by Burp Suite, Charles Proxy, Fiddler, mitmproxy, and corporate TLS inspection appliances. Despite the fact that these tools have legitimate applications, many corporate security tools treat them as hacking tools. Only perform MITM Proxying on networks and clients you’re authorized to inspect. Do not proceed if you have any doubts about your authorization for such techniques. While this is all legitimate debugging and auditing, there’s no way for a 3rd party to independently distinguish if this work is an attack or authorized. Many corporate security teams configure monitoring tools to alarm when they see tools such as MITM proxy installed.

Where WebFetch actually connects is an empirical question. Does the request go through Anthropic’s servers, or does it connect directly from your machine? This guide answers that with packet captures.

Why a general tcpdump of all traffic fails

The straightforward approach is to capture traffic on your main interface:

sudo tcpdump -i eth0 -n -c 100 -w everything.pcap

Running this while using claude in another terminal produces a capture, but it contains a wall of noise: browser tabs, system update checks, NTP syncs, SSH keepalives, DNS queries from every application on the box. Claude’s traffic is in there somewhere, but finding it requires picking apart hundreds of flows by hand.

You might try filtering by destination:

sudo tcpdump -i eth0 -n host api.anthropic.com -w filtered.pcap

Better- but this requires you to know every destination in advance (e.g. api.anthropic.com). If claude contacts a URL you didn’t predict, you miss it. Additionally- other processes might also contact api.anthropic.com if you have other Anthropic integrations running.

Why this happens

tcpdump filters by network interface, not by process. There is no tcpdump --pid 12345 on Linux. The kernel’s packet capture mechanism (AF_PACKET sockets) attaches to interfaces and your main interface (eth0, wlan0, etc.) carries traffic from every process on the system.

Example analogy:

Trying to record one person’s phone calls by tapping the entire building’s phone line. You hear every tenant: browsers, updaters, background services. There’s no way to isolate one voice because they all share the same wire.

We need a way to give claude its own private network interface that carries only its traffic and nothing else. In Part 2, we’ll explore creating a Linux Namespace that enables us to isolate all network traffic for a specific process.

[part 1] Overview

[part 2] Isolating Claude’s traffic with network namespaces

[part 3] Extracting hostnames from encrypted traffic

[part 4] Decrypting HTTPS with a MITM proxy

[part 5] Classifying all of Claude’s network connections & Analyzing traffic by category

Steve Yegge posted about Gastown in January 2026. I read it at the time but didn’t really understand it. Some concepts resonated with me- but I found the language and metaphors of gastown obfuscatory. There are parts of the writing that I associate with LLM-psychosis. I’m disappointed in myself for that reaction. My bias kept me from understanding with what he was actually doing. The nano-banana graphics didn’t help. There’s an uncanny valley quality to them. Whimsical, but slightly off. My mind rushed to label the ideas as lower value because the marmots are for weirdos.

Fast-forward to April: I’d been building my own orchestration solutions around Kanban boards and Claude Code / OpenCode. Something prompted me to re-read the Gastown post in April. I discovered I that had duplicated parallel versions of his orchestration (minus beads, which looks amazing). I didn’t realize what he was doing, and ended up with my own version of this thing. Parallel innovation is the theme of 2026.

If you haven’t read it yet, take some time to read the Gastown post. It’s hard to absorb on the first pass. If you lose all patience, the interview links below will help you get oriented on the important parts without the hyperbole and less dependency on mastery of the metaphors.

————————

From TWiT — Full episode

(note: Leo Laporte’s team can wander into tangents that go nowhere. They’re usually easy to spot, but set your own tolerance level going in.)

• 8 stages of vibe coder evolution
• What is Gastown?
• Is vibe coding reasoning-capable?
• What is Gastown? (second summary)
• What is Beads?
• Gastown is just a tool for vibe coding
• Steve’s workflow
• Steve’s workflow (continued)
• The human only works on the hard problems
• The AI vampiric effect

————————

From AI Tinkerers — Full episode

• Exponential growth of AI
• Why do LLMs find bugs in their own code?
  • LLMs are better at evaluating outputs than generating them — it’s easier to spot what’s wrong than to build from scratch.
  • Technique: ask it to build something, force it to propose an alternative, then have it review both and synthesize a better approach.
• Code review techniques
• Beads

————————

Another interview (good material, but heavy on ads): YouTube

————————

Beads quickstart: gastownhall.github.io

UPDATE:

Provocative Interview:
Steve Yegge’s Vibe Coding Manifesto: Why Claude Code Isn’t It & What Comes After the IDE

2026: The Year The IDE Died — Steve Yegge & Gene Kim, Authors, Vibe Coding

https://www.youtube.com/watch?v=7Dtu2bilcFs