Coding agent telemetry: wetin dey really comot?

Wetin coding agent telemetry dey really cover

Coding agent telemetry na four different data flows wey dey share one name, and each flow get e own control. Model inference carry your prompts and your code go whoever dey serve the model, and no setting fit stop am. Product analytics and crash reports go the vendor, and many times dem also go logging company wey vendor dey pay. Whether dem fit keep the data for training na contract matter, no be network matter. The fourth flow na the one wey people dey miss: every integration wey you add fit open connection go host wey you never choose.

List of current vendor defaults na the part of this topic wey dey change fastest. A release fit change a default, and new feature fit add destination wey no existing switch dey control. So the skill wey go last na audit wey you fit repeat for any agent: read wetin vendor document, check which config really apply for this machine, monitor the process from the machine itself, then choose the controls wey you ready to pay for. Every command below na one wey you run for your own machine, against your own traffic.

The four categories, and why dem need different controls

Model inference traffic na something wey you no fit avoid. The agent dey send your prompt, the files wey e read, the output of the commands wey e run and the text wey e generate go a model endpoint. Na so the product dey work. The only real decision na who go receive am: an API wey another person dey run, or a model wey you run yourself. A company cloud account (Bedrock, Vertex, Foundry) dey change who receives am; e no remove the flow. Nothing for the rest of this post reduce inference traffic, so keep am separate for your mind from the other three.

Product analytics and crash reporting na different flow wey dey go different hosts. Usage counters, latency numbers, feature-flag lookups and stack traces normally dey go hostnames wey no get anything to do with the model API, and often dey go third-party error tracker. Vendors usually document these as "metrics" and "error reports", and usually give you one environment variable for each category. The volume small well-well, so byte counts no go ever find am. You dey look for hostnames, no be bandwidth.

Retention and training na policy, no be packets. Whether the vendor go keep your prompts, how long e go keep dem, and whether e go use dem train future model, dey written for the terms wey come with your plan. Consumer plans and commercial plans usually differ, and zero-retention arrangement normally na separate agreement. You no fit verify any of this with tcpdump, because the packet go look the same either way. Read the terms, and if e matter to your employer, get am for writing.

Integrations fit quietly add another hop. An MCP (model context protocol) server, a plugin marketplace, an auto-update check, a web search tool, or a safety check wey resolve URL before e fetch am: each one na request go a host wey no be the model endpoint. Na here surprises dey happen, because a harness fit route work wey you think dey local through e own service, and a release fit start to do that without changing one line of your config. Treat every tool wey you add as new destination until you don watch am on the wire.

Step 1: vendor documentation dey talk wetin?

Open settings reference and data usage page for your agent. Read dem with word list for hand: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. Each of these words usually represent separate switch. Write the exact variable names down, because step 2 go grep for dem.

One word fit mislead you. For some agents, "telemetry" for documentation mean OpenTelemetry export wey you configure to send metrics go collector wey you run. This na opposite of data wey dey go vendor. Claude Code na one of dem: setting CLAUDE_CODE_ENABLE_TELEMETRY=1 starts export go endpoint wey you name for OTEL_EXPORTER_OTLP_ENDPOINT. E no relate to vendor own analytics, wey get different opt-out setting. First work out which direction data dey flow before you set anything.

Expect master switch, but expect say e get holes. As of August 2026, Claude Code CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC turns off metrics, error reports, the feedback command, and session surveys together. The same documentation say e no cover WebFetch domain safety check. That check sends hostname wey you wan fetch go vendor API, and e get separate setting. This no be complaint about one product. Na the general shape of the problem: master switch covers categories wey exist when dem write am.

Expect the opt-out to cost you something too. The same documentation note say disabling telemetry also disables feature-flag evaluation wey some features depend on. So privacy switch fit turn off feature wey you dey use, without error message wey connect both things. Read the sentence beside the flag, no be only the flag name.

Step 2: which config really apply?

Setting wey you write no be necessarily setting wey apply. Agents dey merge config from different files, and one of dem fit dey inside the repository wey you just clone from another person. Start with the environment of your own shell.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Then print every settings file wey the tool dey read, for the order wey the docs give. For Claude Code, as of August 2026, na the user file, the two project files, and one managed policy directory for Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

A project file wey come with a git clone na config wey stranger write, and e fit turn on again wetin your user file turn off. If the agent get status command wey list the sources wey e load, na the fastest ground truth be that: Claude Code dey print the loaded settings sources for /status.

The strongest check dey read the running process instead of any file. First give the agent im own Linux user account. This one make every command for this post shorter. Then read the environment wey start the process.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ dey show the variables wey the process get for exec time, so e catch the case where your .bashrc export no reach service wey systemd start. If variable wey you set no dey here, e never take effect, no matter wetin your dotfiles talk.

Step 3: Which hosts e dey connect to?

Start with open sockets, then filter dem by the account wey agent dey run as.

sudo ss -tnpe state established

-e dey add one uid: field to each line. This one help you separate the agent connections from your browser own without checking process names. Note the remote addresses, then find the names wey dey behind dem. The cleanest place to get the names na the TLS (transport layer security) handshake. Every new connection dey start with a ClientHello wey carry an SNI (server name indication) field. This field na the hostname wey client request.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

You go get one line for each new connection. Na exactly the inventory wey you need be this: the model API, the update server, the analytics host, the error tracker, and anything wey an integration add. If the name column empty, e mean say client use ECH (encrypted client hello). So the hostname no dey visible for the wire. For that case, use the destination IP address, a reverse lookup, or the proxy for step 4.

The DNS (domain name system) view useful as cross-check. E show names wey agent look up, even for connections wey e no complete.

sudo tcpdump -ni any -l 'udp port 53'

Each query line dey end with the record type and the name, for the form A? host.example.net. (39). Capture for any instead of the external interface. With systemd-resolved, the application dey talk to a local stub listener for 127.0.0.53, and na only the stub dey talk to outside. If you no see any DNS traffic while agent clearly dey work, that runtime dey do DNS over HTTPS by itself. Na only step 4 go give you the names.

Capture while agent dey do real work. Start one session, make e read a file, make e run a command, and make e fail for something. Traffic wey fire once during startup, or only when exception happen, no go show for idle capture. Idle capture na the most common way audit dey reach a comfortable but wrong answer.

Step 4: wetin dey inside the requests?

Hostnames tell you who. To see wetin dey inside, put proxy wey you control in front of the agent and make that runtime trust its certificate authority (CA) only. mitmproxy na the usual tool. The project recommend the standalone binaries from mitmproxy.org, and e document uv tool install mitmproxy as the Python package route.

mitmdump -w /tmp/agent-flows.mitm

The first run go write CA inside ~/.mitmproxy/, where mitmproxy-ca-cert.pem na the certificate by itself. For the shell wey you go use launch the agent, point the client to the proxy and to that certificate.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

Many agent CLIs na Node programs, and Node dey read NODE_EXTRA_CA_CERTS when process start. So export am before you launch the agent, no be for another terminal afterwards. Python clients dey read REQUESTS_CA_BUNDLE or SSL_CERT_FILE, and Go binary wey dey use standard library dey read SSL_CERT_FILE for Linux. Prove say the path dey work with curl before you blame the agent.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Working proxy dey print 200, and the request go show for mitmdump output. CA wey no dey trusted go give curl: (60) SSL certificate problem: self-signed certificate in certificate chain, and the matching error from Node agent get code SELF_SIGNED_CERT_IN_CHAIN. Afterwards, read the saved flows with the console viewer. There, you fit open one request and read its headers and body.

mitmproxy -r /tmp/agent-flows.mitm

Four results dey worth naming. You see the requests, so read dem and decide. The agent refuse to start with certificate error. That one na trust problem for that runtime, no be finding about the vendor. You see only the model API. That one mean the other categories dey off, or dem dey fire for event wey you never trigger. Or you no see anything at all while the agent clearly dey work. That one mean the client dey ignore proxy environment variables or e pin its certificates. No application setting fit be trusted to tell you the truth. Na this last result matter pass, and e send you back to step 3, because packet capture no fit be talked out of seeing a connection.

Controls, from weakest to strongest

Opt-out settings. E cheap pass, and e weak pass, because dem dey work only if vendor respect dem and because dem cover category wey don already exist. Set dem where dem go survive reboot and new terminal, for user settings file or for your shell profile. Add DO_NOT_TRACK=1 while you dey there: na convention wey many command line tools dey respect, including some agents, and e no cost anything. Then run step 3 again after the next update, because na that time the coverage dey change.

Egress restriction. For here, you stop to ask and start to enforce. Run the agent as e own user, then allow loopback and DNS for that user and drop everything else. This add e own table, so e leave any firewall rules wey already dey untouched.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Apply am with sudo nft -f /etc/nftables.d/agent.nft, watch the counter with sudo nft list table inet agentegress, and read the drops with sudo journalctl -k -g agent-egress-drop. If drop counter dey rise for hostname wey you no expect, na the main reason for this exercise. Two honest limits. meta skuid match the user wey own the socket, so e hold only while that account no fit become another user: passwordless sudo for the agent turn this rule to mere suggestion. And if you leave UDP 53 open to any server, you leave channel wey fit carry data comot inside query names. So close am too if your threat model need am, by pointing the agent resolver to host wey you dey run. Hostname allowlists belong for proxy instead of nftables, because API endpoints dey behind content delivery networks whose IP addresses dey change without notice. The cost of this control na breakage and maintenance: package installs, git over SSH, and the agent own update check go all fail until you allow dem, and na you go maintain that list now. If you dey set this up for server instead of laptop, the same account and firewall layout na the base for running Claude Code safely for VPS.

A disposable machine. Give the agent virtual machine (VM) wey no hold credentials wey matter to you and wey you go destroy when the task finish. This no reduce wetin the agent send; e reduce wetin the agent get access to send, and na usually that one be the risk wey you really care about. Combine am with the egress rules above, because fresh VM with unrestricted internet access still fit reach every host for your capture. The method, and the state wey you need rebuild every time, dey covered for running coding agents inside disposable VM, and the sizing question dey for running coding agent for VPS.

Self-hosting the model. Na the only control wey remove the inference flow, because prompt no ever leave your hardware. The cost real: you no fit self-host closed model, so this mean say you go pick open weights and accept capability gap for hard tasks, plus the hardware wey go serve dem. The trade-off dey explained for whether you fit self-host Claude, and the capability differences between the main agents dey for how Claude Code, Cursor, Codex and Copilot dey differ.

None of these four controls change wetin the agent fit read for disk, and inference traffic carry anything wey e read. If .env file dey inside working directory, e go reach the model as soon as the agent grep for variable name. Keeping that material away from the agent na separate work, and dem cover am for keeping secrets away from AI agent context.

Wetín to check after every update

1. Compare the vendor settings and data usage pages with wetin you record last time. Look for new switches and new named services.
2. Read the process environment again from /proc/<pid>/environ to confirm say your opt-outs still dey applied to the running process.
3. Print the project settings files again, because a git pull fit bring config file wey colleague don change.
4. Run the SNI capture for one complete session of real work, then compare the hostname list with the previous one.
5. Check the firewall drop counter, because new destination usually go show there before you notice am anywhere else.

This one dey take about ten minutes, and na the only part of the process wey no dey become outdated. A default wey you verify for August 2026 na fact about August 2026. The capture na fact about today.

FAQ

How I fit stop my coding agent from sending my code go the model?

No, and any setting wey claim say e fit do am dey describe another thing. Sending your prompt, the files wey the agent read, and the output of the commands wey e run go the model endpoint na how inference dey work, so na only who receive am fit change. You fit change the receiver by pointing the agent to a company cloud account or to a model wey you host yourself. You fit also reduce wetin e sends by limiting wetin e get permission to read. Turning off analytics and error reporting no affect this flow at all.

How I fit see which hosts my coding agent dey connect to?

Run the agent as its own Linux user, then capture the TLS ClientHello of every new connection while you dey use am: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. One line go appear for each connection, with the destination address and the requested hostname. Cross-check the names with sudo tcpdump -ni any 'udp port 53', and capture for any because local resolver stub for 127.0.0.53 dey handle the query first. Do the capture while the agent dey do real work, because startup pings and crash reports no go show for idle capture.

My proxy no show traffic while the agent dey work. Wetin go wrong?

Either the client dey ignore HTTP_PROXY and HTTPS_PROXY, or e pin its certificates and refuse your CA. Test the path with curl first: if curl reach internet through the proxy and the agent no appear for the flow list, the agent no dey use proxy environment variables. Some runtimes need you supply the CA in one specific way. Node especially dey read NODE_EXTRA_CA_CERTS only when the process start, so if you export am after launching the agent, nothing go happen. When the proxy no fit see the traffic, use packet capture instead, because no application setting fit bypass am.

If I turn off telemetry, e go stop dem from using my code for training?

No. Analytics and crash reporting na different flow from inference, so disabling dem removes usage counters and stack traces, but every prompt still dey go the model exactly as before. Whether dem retain those prompts, and whether dem use dem to train future model, dey set by the terms of your plan. Consumer plans and commercial plans usually differ. This one na contract wey you need read, not packet wey you need capture. Check the data usage page for your plan and, where e matter, arrange commercial or zero-retention agreement before the first session.