How to audit what your IDE extension actually sends to the cloud

The problem nobody warns you about

I installed a new AI coding assistant last month. Within a week, my laptop fan was spinning constantly, my battery drained twice as fast, and I noticed weird spikes in network activity even when I wasn't actively using the tool.

That got me curious. What is this thing actually sending?

If you've ever wondered the same about an IDE extension, a CLI tool, or a "helpful" agent that magically integrates with your editor, this post is for you. I've been debugging this exact class of problem across three projects, and the toolkit is surprisingly approachable once you sit down with it.

Why you can't just "read the privacy policy"

Here's the uncomfortable truth: an IDE extension typically runs with the same permissions as your editor process. That means it can:

Read every file in your open workspace (and often beyond)
Make arbitrary outbound HTTPS connections
Spawn subprocesses
Access environment variables (hello, AWS_SECRET_ACCESS_KEY)
Watch your filesystem for changes

Privacy policies tell you what the vendor intends to collect. They don't tell you what's actually leaving your machine right now. And because almost everything is HTTPS, you can't just tcpdump it and call it a day.

The root cause of the visibility gap is TLS. Encrypted traffic looks like noise unless you control one of the endpoints, and most network monitors stop at the connection metadata.

Step 1: See connections at the process level

Before you go deep, just look. On macOS or Linux, lsof shows you what's open right now:

# List all network connections for a specific process by name
lsof -i -P -n | grep -i 'code\|cursor\|node'

# Or by PID once you know it
lsof -p 12345 -i -P -n

On Linux specifically, ss is faster and more modern than netstat:

# Show TCP/UDP sockets with the owning process
ss -tunap | grep <pid>

This gives you the hostnames and ports your extension is talking to. You'll usually spot a CDN endpoint, a telemetry endpoint, and the actual API. That alone is informative — if you see connections to a domain you've never heard of, that's a thread worth pulling.

Step 2: Intercept the TLS traffic

Knowing that something is talking to telemetry.example.com isn't the same as knowing what it's saying. To read the payload, you need a man-in-the-middle proxy that you explicitly trust.

mitmproxy is the gold standard here. It's free, open source, and Python-scriptable.

# Install via pipx so it doesn't pollute your global Python
pipx install mitmproxy

# Start the interactive TUI on port 8080
mitmproxy --listen-port 8080

The trick is getting your editor's traffic to flow through it. Two approaches I've used:

Approach A — HTTP_PROXY environment variables. Many extensions written in Node honor these:

# Launch your editor with proxy variables set
HTTPS_PROXY=http://127.0.0.1:8080 \
HTTP_PROXY=http://127.0.0.1:8080 \
NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem \
/Applications/YourEditor.app/Contents/MacOS/YourEditor

The NODE_EXTRA_CA_CERTS bit matters. Without trusting the mitmproxy CA, Node will reject the intercepted certificate and the extension will fail silently or fall back to who-knows-what.

Approach B — System-wide proxy. If the extension ignores environment variables (and many do, sadly), set the proxy at the OS level and install the mitmproxy root cert into the system trust store. On macOS:

# Add mitmproxy's CA to the system keychain and trust it
sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain \
  ~/.mitmproxy/mitmproxy-ca-cert.pem

Only do this on a throwaway machine or VM. You're adding a CA that can sign certs for any domain. Roll it back when you're done auditing.

Step 3: Inspect the actual payloads

Once traffic is flowing through mitmproxy, you'll see requests stream in. The interesting ones are usually POST requests to whatever the vendor's ingestion endpoint is. Here's a small mitmproxy script I keep around for dumping bodies to disk:

# dump_bodies.py — save every request body to a timestamped file
import time
import pathlib

OUT = pathlib.Path("/tmp/proxy-dump")
OUT.mkdir(exist_ok=True)

def request(flow):
    # Skip GETs and empty bodies to reduce noise
    if flow.request.method == "GET" or not flow.request.content:
        return
    ts = int(time.time() * 1000)
    host = flow.request.pretty_host.replace("/", "_")
    path = OUT / f"{ts}_{host}.bin"
    path.write_bytes(flow.request.content)

Run it like this:

mitmdump -s dump_bodies.py --listen-port 8080

Then open every file in /tmp/proxy-dump and look. You're hunting for things that shouldn't be there: file paths from outside the workspace, environment variable names, snippets of code you didn't intentionally share, contents of .env files, hostnames of internal services.

I ran this on a popular extension last quarter and was genuinely surprised at how much workspace metadata was being shipped on every keystroke. Not the file contents — but enough structural information that you could probably reconstruct the directory layout.

Step 4: Watch the filesystem too

Network is only half the story. An extension might cache things locally, write to your home directory, or stash credentials in unexpected places. Use fs_usage on macOS or inotifywait on Linux:

# macOS: watch all filesystem activity for a process
sudo fs_usage -w -f filesys | grep <process_name>

# Linux: recursive watch on the home directory
inotifywait -mr ~ --format '%w%f %e' 2>/dev/null

This is noisy. Filter aggressively. But it'll catch things like an extension writing telemetry blobs to ~/.cache/<vendor>/ that you'd never notice otherwise.

Prevention: how to not get burned in the first place

A few habits that have saved me real headaches:

Audit before you install, not after. Spin up a clean VM, install the extension, and run the steps above for an hour. If the traffic looks weird, you know before you've committed your real workflow to it.
Isolate per-project workspaces. Don't open your monorepo with secrets at the root in the same editor session as a sketchy extension. Trust boundaries should match your tolerance.
Watch your .env files. Most extensions claim they exclude these. Verify by putting a canary string in a fake .env and searching the intercepted traffic for it.
Pin extension versions. Updates can change behavior overnight. If you've audited version 1.4.2, lock it. Re-audit before bumping.
Keep a baseline. Save the list of endpoints an extension contacts in week one. If new domains show up in week six, that's a signal worth investigating.

The bigger lesson

The tools we plug into our editors have grown enormously powerful in the last couple of years, and the trust we extend them has grown alongside. That's fine — productivity wins matter — but trust without verification is just hope.

The good news is the verification toolkit is right there. lsof, mitmproxy, fs_usage. An afternoon with these gives you a much clearer picture of your development environment than any privacy policy ever will.

If you find something interesting when you run this on your own setup, I'd genuinely love to hear about it. The more of us doing this kind of auditing, the harder it gets for sketchy behavior to hide in plain sight.

推荐订阅源

DEV Community