Coding agent telemetry: Ano ang naipapadala?

Ano talaga ang saklaw ng telemetry ng coding agent

Ang telemetry ng coding agent ay binubuo ng apat na magkahiwalay na data flow na gumagamit ng iisang termino, at may sariling control ang bawat flow. Dinadala ng model inference ang iyong prompts at code sa provider ng model, at walang setting na makakapagpatigil dito. Ipinapadala sa vendor ang product analytics at crash reports, at madalas ay ipinapadala rin sa logging company na binabayaran ng vendor. Ang retention para sa training ay usapin ng kontrata, hindi ng network. Ang ikaapat na flow ang madalas hindi napapansin: bawat integration na idinaragdag mo ay maaaring magbukas ng connection sa host na hindi mo naman pinili.

Ang listahan ng kasalukuyang vendor defaults ang pinakamabilis maluma sa paksang ito. Maaaring baguhin ng isang release ang default, at maaaring magdagdag ang isang bagong feature ng destination na hindi saklaw ng alinman sa mga kasalukuyang switch. Kaya ang pangmatagalang kasanayan ay isang audit na maaari mong ulitin sa anumang agent: basahin ang dokumentasyon ng vendor, tingnan kung aling config ang aktuwal na na-apply sa machine na ito, i-monitor ang proseso mula mismo sa machine, at pagkatapos ay piliin ang mga control na handa mong paglaanan ng gastos. Ang bawat command sa ibaba ay pinapatakbo mo sa sarili mong machine, laban sa sarili mong traffic.

Apat na kategorya, at kung bakit magkakaiba ang kailangan nilang control

Hindi maiiwasan ang model inference traffic. Ipinapadala ng agent ang prompt mo, ang mga file na binasa nito, ang output ng mga command na pinatakbo nito, at ang sarili nitong nabuong text sa isang model endpoint. Iyan ang normal na paggana ng produkto. Ang tanging tunay na desisyon ay kung sino ang tatanggap nito: isang API na pinapatakbo ng ibang tao, o isang model na ikaw mismo ang nagpapatakbo. Ang company cloud account (Bedrock, Vertex, Foundry) ay naglilipat sa tatanggap; hindi nito inaalis ang daloy. Walang bahagi ng natitirang post na ito ang makababawas sa inference traffic, kaya ihiwalay mo ito sa isip mo mula sa tatlo pang kategorya.

Ibang daloy patungo sa ibang host ang product analytics at crash reporting. Karaniwang ipinapadala ang usage counter, latency number, feature-flag lookup, at stack trace sa mga hostname na walang kaugnayan sa model API, at madalas sa third-party error tracker. Karaniwang tinutukoy ng mga vendor ang mga ito bilang "metrics" at "error reports", at karaniwan silang nagbibigay ng tig-iisang environment variable para sa bawat kategorya. Napakaliit ng volume, kaya hindi ito matutukoy ng byte count. Mga hostname, hindi bandwidth, ang hinahanap mo.

Policy, hindi mga packet, ang retention at training. Kung itinatago ng vendor ang mga prompt mo, kung gaano katagal, at kung ginagamit niya ang mga ito sa pag-train ng susunod na model, nakasulat ito sa mga tuntuning kalakip ng plan mo. Karaniwang magkaiba ang consumer plan at commercial plan, at kadalasang hiwalay na agreement ang zero-retention arrangement. Hindi mo mabe-verify ang alinman dito gamit ang tcpdump, dahil magkapareho ang hitsura ng packet sa alinmang sitwasyon. Basahin ang mga tuntunin, at kung mahalaga ito sa employer mo, kunin ito nang nakasulat.

Tahimik na nagdaragdag ng hop ang mga integration. Ang MCP (model context protocol) server, plugin marketplace, auto-update check, web search tool, at safety check na nagre-resolve ng URL bago ito kunin ay mga request sa host na hindi model endpoint. Dito lumilitaw ang mga hindi inaasahang daloy, dahil maaaring i-route ng isang harness ang gawaing inakala mong local sa sarili nitong service, at maaaring magsimulang gawin iyon ng isang release nang hindi binabago ang kahit isang linya ng config mo. Ituring ang bawat tool na idaragdag mo bilang bagong destination hanggang sa ma-monitor mo ito sa network traffic.

Hakbang 1: ano ang nakasaad sa dokumentasyon ng vendor?

Buksan ang settings reference at data usage page para sa agent mo, at basahin ang mga ito habang may word list ka: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. Karaniwang magkakahiwalay na switch ang bawat isa sa mga salitang ito. Isulat nang eksakto ang mga variable name, dahil hahanapin ng step 2 ang mga ito gamit ang grep.

May isang salitang maaaring makapanlinlang sa iyo. Sa ilang agent, ang ibig sabihin ng “telemetry” sa dokumentasyon ay isang OpenTelemetry export na kino-configure mong magpadala ng metrics sa collector na pinapatakbo mo. Kabaligtaran ito ng pagpapadala ng data sa vendor. Isa rito ang Claude Code: kapag sine-set ang CLAUDE_CODE_ENABLE_TELEMETRY=1, nagsisimula ito ng export papunta sa endpoint na tinukoy mo sa OTEL_EXPORTER_OTLP_ENDPOINT. Hindi ito nauugnay sa sariling analytics ng vendor, na may ibang opt-out setting. Tukuyin muna kung saan dumadaloy ang data bago ka mag-set ng anuman.

Asahan ang isang master switch, pero asahan ding may mga limitasyon ito. Noong August 2026, pinapatay ng CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ng Claude Code ang metrics, error reports, feedback command, at session surveys nang sabay-sabay. Sinasabi rin sa parehong dokumentasyon na hindi nito saklaw ang WebFetch domain safety check. Ipinapadala ng safety check na ito sa vendor API ang hostname na kukunin mo, at mayroon itong sarili at hiwalay na setting. Hindi ito partikular na problema ng isang produkto. Ganito ang karaniwang anyo ng problema: sinasaklaw ng master switch ang mga category na umiiral noong isinulat ito.

Asahan ding may kapalit ang pag-opt out. Nakatala rin sa parehong dokumentasyon na kapag na-disable ang telemetry, nade-disable din ang feature-flag evaluation na kinakailangan ng ilang feature. Dahil dito, maaaring ma-disable ng privacy switch ang feature na ginagamit mo, nang walang error message na nag-uugnay sa dalawang pangyayari. Basahin ang pangungusap sa tabi ng flag, hindi lang ang pangalan ng flag.

Hakbang 2: aling config ang aktuwal na nailapat?

Ang setting na isinulat mo ay hindi awtomatikong setting na nailapat. Pinagsasama ng mga agent ang config mula sa ilang file, at ang isa sa mga ito ay maaaring nasa repository na kakaklone mo lang mula sa ibang tao. Magsimula sa environment ng sarili mong shell.

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

Pagkatapos, i-print ang lahat ng settings file na binabasa ng tool, ayon sa pagkakasunod na nasa docs. Para sa Claude Code, noong August 2026, kabilang dito ang user file, dalawang project file, at isang managed policy directory sa 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

Ang project file na kasama ng isang git clone ay config na isinulat ng ibang tao, at maaari nitong muling i-enable ang isinara ng user file mo. Kung may status command ang agent na naglilista ng mga source na na-load nito, iyon ang pinakamabilis na paraan para makumpirma ang aktuwal na pinagmulan: ipinapakita ng Claude Code ang mga na-load na settings source sa /status.

Ang pinakamatibay na pagsusuri ay binabasa ang tumatakbong process sa halip na anumang file. Bigyan muna ang agent ng sarili nitong Linux user account. Dahil dito, mas maikli ang bawat command sa post na ito. Pagkatapos, basahin ang environment na ginamit sa pagsisimula ng process.

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

Ipinapakita ng /proc/<pid>/environ ang mga variable na mayroon ang process sa oras ng exec. Dahil dito, natutukoy nito kung hindi nakarating ang .bashrc export mo sa service na sinimulan ng systemd. Kung nawawala rito ang variable na itinakda mo, hindi ito kailanman naging aktibo, anuman ang sinasabi ng iyong dotfiles.

Hakbang 3: saang host ito kumokonekta?

Magsimula sa mga open socket, na i-filter batay sa account na ginagamit ng agent sa pagtakbo.

sudo ss -tnpe state established

Idinadagdag ng -e ang field na uid: sa bawat linya, kaya maihihiwalay mo ang mga koneksyon ng agent sa mga koneksyon ng browser nang hindi sinusuri ang mga pangalan ng proseso. Itala ang remote address, pagkatapos ay kunin ang mga pangalan sa likod ng mga ito. Ang pinakamalinis na pinagmumulan ng mga pangalan ay ang TLS (transport layer security) handshake, dahil nagsisimula ang bawat bagong koneksyon sa ClientHello na may field na SNI (server name indication), na hostname na hiningi ng client.

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

Makakakuha ka ng tig-isang linya para sa bawat bagong koneksyon. Ito mismo ang inventory na kailangan mo: ang model API, update server, analytics host, error tracker, at anumang idinagdag ng integration. Kapag walang laman ang name column, gumamit ang client ng ECH (encrypted client hello), kaya hindi nakikita sa network traffic ang hostname. Sa halip, gamitin ang destination IP address, reverse lookup, o ang proxy sa step 4.

Kapaki-pakinabang na cross-check ang DNS (domain name system) view, dahil ipinapakita nito ang mga pangalan na hinanap ng agent kahit para sa mga koneksyong hindi nito natapos.

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

Nagtatapos ang bawat query line sa record type at pangalan, sa anyong A? host.example.net. (39). Mag-capture sa any sa halip na sa external interface, dahil kapag may systemd-resolved, nakikipag-ugnayan ang application sa isang local stub listener sa 127.0.0.53 at ang stub lamang ang nakikipag-ugnayan sa labas. Kung wala kang nakikitang DNS traffic habang malinaw na gumagana ang agent, gumagamit ang runtime na iyon ng DNS over HTTPS mismo. Step 4 lamang ang makakapagbigay sa iyo ng mga pangalan.

Mag-capture habang gumagawa ng aktuwal na trabaho ang agent. Magsimula ng session, ipabasa rito ang isang file, ipatakbo rito ang isang command, at hayaan itong mabigo sa isang gawain. Ang traffic na isang beses lamang lumalabas sa startup, o lumalabas lamang kapag may exception, ay hindi makikita sa idle capture. Ang idle capture ang pinakakaraniwang dahilan kung bakit nagkakaroon ang audit ng maling sagot na mukhang tama.

Hakbang 4: ano ang nasa loob ng mga request?

Sinasabi ng mga hostname kung sino. Para makita kung ano ang ipinapadala, maglagay ng proxy na kontrolado mo sa harap ng agent at pagkatiwalaan ang certificate authority (CA) nito para lamang sa runtime na iyon. Ang mitmproxy ang karaniwang tool para rito. Inirerekomenda ng project ang standalone binaries mula sa mitmproxy.org, at idinodokumento nito ang uv tool install mitmproxy bilang paraan gamit ang Python package.

mitmdump -w /tmp/agent-flows.mitm

Sa unang pagtakbo, nagsusulat ito ng CA sa ~/.mitmproxy/, kung saan ang mitmproxy-ca-cert.pem ang certificate mismo. Sa shell kung saan mo ilulunsad ang agent, ituro ang client sa proxy at sa certificate na iyon.

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"

Maraming agent CLI ang Node programs, at binabasa ng Node ang NODE_EXTRA_CA_CERTS kapag nagsisimula ang process. Kaya i-export ito bago mo ilunsad ang agent, hindi sa ibang terminal pagkatapos nito. Binabasa ng Python clients ang REQUESTS_CA_BUNDLE o SSL_CERT_FILE, at binabasa ng Go binary na gumagamit ng standard library ang SSL_CERT_FILE sa Linux. Patunayan na gumagana ang path gamit ang curl bago mo sisihin ang agent.

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

Nagpi-print ang gumaganang proxy ng 200, at lumilitaw ang request sa output ng mitmdump. Nagbibigay ang hindi pinagkakatiwalaang CA ng curl: (60) SSL certificate problem: self-signed certificate in certificate chain, at ang katumbas na error mula sa Node agent ay may code na SELF_SIGNED_CERT_IN_CHAIN. Basahin pagkatapos ang mga na-save na flow gamit ang console viewer. Doon, maaari mong buksan ang isang request at basahin ang headers at body nito.

mitmproxy -r /tmp/agent-flows.mitm

May apat na resultang dapat tukuyin. Nakikita mo ang mga request; basahin ang mga ito at magpasya. Tumangging magsimula ang agent dahil sa certificate error; trust problem ito sa runtime na iyon at hindi finding tungkol sa vendor. Model API lamang ang nakikita mo; nangangahulugan itong naka-off ang ibang category o nagti-trigger ang mga ito sa event na hindi mo sinimulan. O wala kang nakikita kahit malinaw na gumagana ang agent; nangangahulugan itong binabalewala ng client ang proxy environment variables o nagpi-pin ito ng certificates, kaya hindi mapagkakatiwalaan ang anumang application setting para sabihin sa iyo ang totoo. Ang huling resultang ito ang pinakamahalaga, at ibinabalik ka nito sa step 3, dahil hindi maaaring kumbinsihin ang packet capture na huwag makita ang isang connection.

Mga Control, mula sa pinakamahina hanggang sa pinakamalakas

Mga setting na opt-out. Pinakamura at pinakamahina ang mga ito dahil nakadepende ang mga ito sa pagsunod ng vendor at sumasaklaw lamang sa kategoryang dati nang umiiral. Itakda ang mga ito sa lugar na nananatili matapos ang reboot at sa bagong terminal, gaya ng user settings file o shell profile. Idagdag din ang DO_NOT_TRACK=1 habang naroon ka: convention ito na sinusunod ng maraming command-line tool, kabilang ang ilang agent, at wala itong dagdag na gastos. Pagkatapos ng susunod na update, patakbuhing muli ang step 3 dahil doon nagbabago ang coverage.

Egress restriction. Dito, hindi ka na nagtatanong; nagpapatupad ka na. Patakbuhin ang agent gamit ang sarili nitong user, pagkatapos ay payagan ang loopback at DNS para sa user na iyon at i-drop ang iba pang traffic. Nagdaragdag ito ng sarili nitong table, kaya hindi nito binabago ang mga dati nang firewall rule.

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
  }
}

Ilapat ito gamit ang sudo nft -f /etc/nftables.d/agent.nft, bantayan ang counter gamit ang sudo nft list table inet agentegress, at basahin ang mga drop gamit ang sudo journalctl -k -g agent-egress-drop. Ang tumataas na drop counter na may hostname na hindi mo inaasahan ang mismong layunin ng hakbang na ito. May dalawang mahalagang limitasyon. Tinutugma ng meta skuid ang user na nagmamay-ari ng socket, kaya epektibo lamang ito habang hindi nagiging ibang user ang account na iyon: ginagawang mungkahi lamang ng passwordless sudo para sa agent ang rule na ito. Bukod dito, ang pag-iwan sa UDP 53 na bukas para sa kahit anong server ay nag-iiwan ng channel na maaaring maglabas ng data sa mga query name. Isara rin ito kung kailangan iyon ng threat model mo, sa pamamagitan ng pag-configure sa resolver ng agent na gumamit ng host na ikaw ang nagpapatakbo. Sa halip na sa nftables, sa proxy dapat ilagay ang hostname allowlist dahil ang mga API endpoint ay nasa likod ng content delivery network na maaaring magpalit ng IP address nang hindi mo kontrolado. Ang kapalit ng control na ito ay breakage at maintenance: mabibigo ang package install, git sa SSH, at sariling update check ng agent hanggang sa payagan mo ang mga ito. Ikaw na rin ang kailangang mag-maintain ng listahang iyon. Kung ise-set up mo ito sa server sa halip na laptop, ang parehong account at firewall layout ang batayan ng ligtas na pagpapatakbo ng Claude Code sa VPS.

Isang disposable machine. Bigyan ang agent ng virtual machine (VM) na walang credentials na mahalaga sa iyo at winawasak pagkatapos ng task. Hindi nito binabawasan ang ipinapadala ng agent. Binabawasan nito ang mga resource na maaari nitong pagkunan at pagpapadalhan ng data, na karaniwang siyang aktuwal na risk na mahalaga sa iyo. Isabay ito sa mga egress rule sa itaas dahil maaabot pa rin ng bagong VM na may unrestricted internet access ang bawat host na nasa capture mo. Tinalakay ang method at ang state na kailangan mong buuin muli sa bawat paggamit sa pagpapatakbo ng coding agent sa disposable VM, at ang usapin ng sizing sa pagpapatakbo ng coding agent sa VPS.

Self-hosting ng model. Ito lamang ang control na nag-aalis sa inference flow dahil hindi umaalis sa hardware mo ang prompt. Totoo ang kapalit nito: hindi mo maaaring i-self-host ang closed model, kaya kailangan mong pumili ng open weights at tanggapin ang capability gap sa mahihirap na task, pati ang hardware na kailangan para patakbuhin ang mga ito. Tinalakay ang trade-off sa kung maaari mong i-self-host ang Claude, at ang pagkakaiba ng capability ng mga pangunahing agent sa pagkakaiba ng Claude Code, Cursor, Codex at Copilot.

Wala sa apat na control na ito ang nagbabago sa mga file na pinapayagang basahin ng agent sa disk, at dala ng inference traffic ang anumang mabasa nito. Kung nasa working directory ang isang .env file, ipinapadala ito sa model sa sandaling mag-grep ang agent para sa pangalan ng variable. Hiwalay na gawain ang pag-iwas na maabot ng agent ang naturang materyal. Tinalakay ito sa pag-iwas na mapasama ang mga secret sa context ng AI agent.

Ano ang dapat suriin pagkatapos ng bawat update

1. I-diff ang mga page ng vendor tungkol sa settings at paggamit ng data laban sa naitala mo noong nakaraan, at hanapin ang mga bagong switch at bagong pinangalanang serbisyo.
2. Basahin muli ang process environment mula sa /proc/<pid>/environ upang kumpirmahing nakalapat pa rin ang iyong mga opt-out sa tumatakbong process.
3. I-print muli ang mga settings file ng project, dahil maaaring magdala ang isang git pull ng config file na binago ng isang kasamahan.
4. Patakbuhin ang SNI capture sa loob ng isang buong session ng aktuwal na trabaho, at ihambing ang listahan ng hostname sa nauna mong listahan.
5. Suriin ang firewall drop counter, dahil karaniwang unang lumilitaw doon ang bagong destination bago mo ito mapansin sa ibang lugar.

Humigit-kumulang sampung minuto ito, at ito lamang ang bahagi ng proseso na hindi naluluma. Ang default na na-verify mo noong Agosto 2026 ay tumpak para sa Agosto 2026. Ang capture ay tumpak para sa araw na ito.

FAQ

Maaari ko bang pigilan ang coding agent ko na ipadala ang code ko sa model?

Hindi, at anumang setting na nagsasabing kaya nito ay ibang bagay ang tinutukoy. Ang pagpapadala ng prompt mo, mga file na binasa ng agent, at output ng mga command na pinatakbo nito sa model endpoint ang paraan ng inference, kaya ang tanging nagbabago ay kung sino ang tatanggap nito. Mapapalitan mo ang tatanggap sa pamamagitan ng pagturo sa agent sa company cloud account o sa model na ikaw mismo ang nag-host, at mababawasan mo ang ipinapadala nito sa pamamagitan ng paglilimita sa mga file na pinapayagan itong basahin. Walang epekto sa flow na ito ang pag-off ng analytics at error reporting.

Paano ko makikita kung aling mga host ang kinokonektahan ng coding agent ko?

Patakbuhin ang agent gamit ang sarili nitong Linux user, pagkatapos ay i-capture ang TLS ClientHello ng bawat bagong connection habang ginagamit mo ito: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. May isang linya para sa bawat connection, kasama ang destination address at hinihinging hostname. I-cross-check ang mga pangalan gamit ang sudo tcpdump -ni any 'udp port 53', at mag-capture sa any dahil isang local resolver stub sa 127.0.0.53 ang unang humahawak sa query. Isagawa ang capture habang gumagawa ng aktuwal na trabaho ang agent, dahil hindi lumalabas sa idle capture ang mga startup ping at crash report.

Walang nakikitang traffic ang proxy ko habang gumagana ang agent. Ano ang nangyari?

Maaaring binabalewala ng client ang HTTP_PROXY at HTTPS_PROXY, o pini-pin nito ang mga certificate at tinatanggihan ang CA mo. Subukan muna ang path gamit ang curl: kung nakakarating sa internet ang curl sa pamamagitan ng proxy at hindi lumilitaw ang agent sa flow list, hindi ginagamit ng agent ang proxy environment variables. May ilang runtime na nangangailangan ng partikular na paraan ng pag-supply ng CA, at ang Node, partikular, ay nagbabasa lamang ng NODE_EXTRA_CA_CERTS sa pagsisimula ng process, kaya walang epekto ang pag-export nito pagkatapos ilunsad ang agent. Kapag hindi makita ng proxy ang traffic, gumamit ng packet capture bilang fallback, dahil walang application setting na makalalampas dito.

Kapag pinatay ko ang telemetry, mapipigilan ba nitong gamitin ang code ko para sa training?

Hindi. Ibang flow ang analytics at crash reporting kumpara sa inference, kaya kapag hindi pinagana ang mga ito, matatanggal ang usage counter at stack trace, ngunit mananatiling gaya ng dati ang bawat prompt na ipinapadala sa model. Ang retention ng mga prompt na iyon at kung gagamitin ang mga ito para mag-train ng susunod na model ay nakatakda sa terms ng plan mo, at karaniwang magkaiba ang consumer plan at commercial plan. Contract ito na kailangang basahin, hindi packet na kailangang i-capture, kaya tingnan ang data usage page para sa plan mo at, kung mahalaga ito sa sitwasyon, mag-ayos ng commercial o zero-retention agreement bago ang unang session.