coding agent telemetry मध्ये काय पाठवले जाते?

coding agent telemetry मध्ये प्रत्यक्षात काय समाविष्ट असते

coding agent telemetry म्हणजे एकाच शब्दाखाली येणारे data sharing चे चार स्वतंत्र प्रवाह आहेत. प्रत्येक प्रवाहासाठी स्वतंत्र नियंत्रण असते. Model inference दरम्यान तुमचे prompts आणि code model पुरवणाऱ्या सेवेकडे पाठवले जातात. कोणतीही setting हे पूर्णपणे बंद करू शकत नाही. Product analytics आणि crash reports vendor कडे पाठवले जातात. अनेकदा vendor ज्या logging company ला पैसे देतो, तिच्याकडेही ते पाठवले जातात. Training साठी data retention हा network पेक्षा contract चा विषय आहे. चौथा प्रवाह अनेकांच्या लक्षात येत नाही: तुम्ही जोडलेले प्रत्येक integration तुम्ही निवडलेलेही नसलेल्या host शी connection उघडू शकते.

सध्याच्या vendor defaults ची यादी हा या विषयातील सर्वात वेगाने कालबाह्य होणारा भाग आहे. एखाद्या release मध्ये default बदलू शकतो. नवीन feature मुळे विद्यमान कोणत्याही switch ने नियंत्रित न होणारे destination जोडले जाऊ शकते. त्यामुळे टिकणारे कौशल्य म्हणजे कोणत्याही agent वर पुन्हा करता येईल असा audit करणे. Vendor ने काय document केले आहे ते वाचा. या machine वर प्रत्यक्षात कोणती config लागू झाली आहे ते तपासा. Machine मधूनच process चे निरीक्षण करा. त्यानंतर तुम्ही स्वीकारण्यास आणि त्याची किंमत मोजण्यास तयार असलेली controls निवडा. खालील प्रत्येक command तुम्ही तुमच्या स्वतःच्या machine वर, तुमच्या स्वतःच्या traffic विरुद्ध चालवता.

चार श्रेणी आणि त्यांच्यासाठी वेगवेगळी नियंत्रणे का आवश्यक आहेत

Model inference traffic टाळता येत नाही. Agent तुमचा prompt, त्याने वाचलेल्या files, त्याने चालवलेल्या commands चे output आणि त्याने स्वतः तयार केलेला text model endpoint कडे पाठवतो. Product अशाच प्रकारे कार्य करते. प्रत्यक्षात एकच निर्णय घ्यायचा असतो: हा data दुसऱ्या कोणीतरी चालवलेल्या API कडे पाठवायचा की तुम्ही स्वतः चालवलेल्या model कडे. कंपनीचे cloud account (Bedrock, Vertex, Foundry) प्राप्तकर्ता बदलते; data flow थांबवत नाही. या लेखातील पुढील कोणतीही बाब inference traffic कमी करत नाही. त्यामुळे तो इतर तीन प्रकारांपासून वेगळा समजा.

Product analytics आणि crash reporting हा वेगळ्या hosts कडे जाणारा वेगळा flow आहे. Usage counters, latency numbers, feature-flag lookups आणि stack traces सहसा model API शी संबंधित नसलेल्या hostnames कडे पाठवले जातात. ते अनेकदा third-party error tracker कडेही जातात. Vendors यांचे वर्णन सहसा "metrics" आणि "error reports" असे करतात. प्रत्येक category साठी ते सहसा एक environment variable देतात. याचा volume अत्यंत कमी असतो. त्यामुळे byte counts वापरून तो कधीही सापडणार नाही. तुम्ही bandwidth नव्हे, hostnames शोधत आहात.

Retention आणि training हे packets नव्हे, तर policy आहेत. Vendor तुमचे prompts ठेवतो का, किती काळ ठेवतो आणि त्यांचा वापर भविष्यातील model च्या training साठी करतो का, हे तुमच्या plan ला लागू असलेल्या terms मध्ये नमूद केलेले असते. Consumer plans आणि commercial plans सहसा वेगळे असतात. Zero-retention arrangement सहसा स्वतंत्र agreement असतो. tcpdump वापरून यापैकी कोणतीही बाब पडताळता येत नाही, कारण दोन्ही परिस्थितींमध्ये packet सारखाच दिसतो. Terms वाचा. तुमच्या employer साठी ही बाब महत्त्वाची असल्यास, ती लेखी स्वरूपात मिळवा.

Integrations शांतपणे आणखी एक hop जोडतात. MCP (model context protocol) server, plugin marketplace, auto-update check, web search tool किंवा fetch करण्यापूर्वी URL resolve करणारा safety check—यापैकी प्रत्येकामुळे model endpoint नसलेल्या host कडे request पाठवली जाते. अनपेक्षित flow याच ठिकाणी आढळतात. Harness तुम्हाला local वाटणारे काम स्वतःच्या service मार्फत route करू शकतो. तसेच तुमच्या config मध्ये एकही line न बदलता एखाद्या release मध्ये हे सुरू होऊ शकते. तुम्ही जोडलेल्या प्रत्येक tool ला, wire वर त्याचा traffic पाहेपर्यंत, नवीन destination समजा.

पायरी 1: विक्रेता कोणते दस्तऐवजीकरण देतो?

तुमच्या agent साठी settings reference आणि data usage पृष्ठ उघडा. ही पृष्ठे पुढील शब्दांची यादी समोर ठेवून वाचा: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. यातील प्रत्येक शब्दासाठी सामान्यतः स्वतंत्र switch असतो. Variable names जशीच्या तशी लिहून ठेवा, कारण पायरी 2 मध्ये त्यांच्यासाठी grep केले जाईल.

एक शब्द तुमची दिशाभूल करू शकतो. अनेक agents मध्ये दस्तऐवजीकरणातील "telemetry" म्हणजे तुम्ही चालवत असलेल्या collector कडे metrics पाठवण्यासाठी configure केलेला OpenTelemetry export असतो. म्हणजेच डेटा विक्रेत्याकडे जाण्याच्या उलट दिशा. Claude Code यापैकी एक आहे: CLAUDE_CODE_ENABLE_TELEMETRY=1 सेट केल्याने OTEL_EXPORTER_OTLP_ENDPOINT मध्ये दिलेल्या endpoint कडे export सुरू होते. याचा विक्रेत्याच्या स्वतःच्या analytics शी संबंध नाही; त्यासाठी वेगळी opt-out setting असते. कोणतीही setting करण्यापूर्वी डेटा कोणत्या दिशेने वाहतो ते निश्चित करा.

Master switch असेल अशी अपेक्षा ठेवा, पण त्याला काही अपवादही असतील. August 2026 पर्यंत, Claude Code मधील CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC metrics, error reports, feedback command आणि session surveys एकत्र बंद करते. त्याच दस्तऐवजीकरणानुसार, WebFetch domain safety check यामध्ये समाविष्ट नाही. तुम्ही fetch करणार असलेले hostname हे check vendor API कडे पाठवते आणि त्यासाठी स्वतंत्र setting असते. ही समस्या एखाद्या एका product पुरती मर्यादित नाही. सर्वत्र हीच रचना आढळते: master switch लिहिला गेला त्या वेळी अस्तित्वात असलेल्या categories वरच लागू होतो.

Opt-out केल्यामुळे काही कार्यक्षमता गमवावी लागू शकते. त्याच दस्तऐवजीकरणात नमूद केले आहे की telemetry बंद केल्यावर काही features ज्यांवर अवलंबून असतात ती feature-flag evaluation देखील बंद होते. त्यामुळे privacy साठी केलेल्या एका बदलामुळे तुम्ही वापरत असलेले feature बंद होऊ शकते; दोन्ही गोष्टी जोडणारा कोणताही error message दिसेलच असे नाही. Flag चे नावच नव्हे, तर त्याच्या शेजारील वाक्यही वाचा.

पायरी 2: प्रत्यक्षात कोणते config लागू झाले?

तुम्ही लिहिलेली setting लागू झालेली असेलच असे नाही. Agents अनेक files मधील config एकत्र करतात. त्यांपैकी एक file तुम्ही नुकतीच दुसऱ्या व्यक्तीकडून clone केलेल्या repository मध्ये असू शकते. सुरुवात तुमच्या स्वतःच्या shell च्या environment पासून करा.

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

त्यानंतर tool वाचत असलेल्या प्रत्येक settings file ची यादी docs मध्ये दिलेल्या क्रमाने print करा. August 2026 पर्यंत Claude Code साठी हा क्रम user file, दोन project files आणि Linux वरील managed policy directory असा आहे.

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

git clone सोबत आलेली project file म्हणजे दुसऱ्या व्यक्तीने लिहिलेली config आहे. ती तुमच्या user file ने बंद केलेली setting पुन्हा enable करू शकते. Agent मध्ये loaded sources ची यादी दाखवणारी status command असल्यास, तीच सर्वात विश्वासार्ह पडताळणी आहे. Claude Code loaded settings sources /status मध्ये print करते.

सर्वात ठोस पडताळणी कोणतीही file न वाचता running process तपासते. प्रथम agent साठी स्वतंत्र Linux user account द्या. त्यामुळे या post मधील प्रत्येक command लहान होईल. त्यानंतर process सुरू होताना असलेले environment वाचा.

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

/proc/<pid>/environ मध्ये process सुरू होताना त्याच्याकडे असलेले variables दिसतात. त्यामुळे तुमचा .bashrc export systemd ने सुरू केलेल्या service पर्यंत पोहोचला नाही, हे लक्षात येते. तुम्ही set केलेला variable येथे दिसत नसेल, तर तो कधीही लागू झाला नव्हता, तुमच्या dotfiles मध्ये काहीही नमूद असले तरी.

पायरी 3: ते कोणत्या hosts शी कनेक्ट होते?

Agent ज्या account अंतर्गत चालतो, त्या account नुसार filtered open sockets पासून सुरुवात करा.

sudo ss -tnpe state established

-e प्रत्येक ओळीत uid: field जोडते. त्यामुळे process names न वाचता agent चे connections आणि browser चे connections वेगळे करता येतात. Remote addresses नोंदवा. त्यानंतर त्या addresses मागील names शोधा. Names मिळवण्यासाठी TLS (transport layer security) handshake हा सर्वात स्वच्छ स्रोत आहे. प्रत्येक नवीन connection ची सुरुवात SNI (server name indication) field असलेल्या ClientHello ने होते. हे field client ने मागितलेले hostname दर्शवते.

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

प्रत्येक नवीन connection साठी एक ओळ मिळते. तुम्हाला हवी असलेली inventory नेमकी हीच असते: model API, update server, analytics host, error tracker आणि integration ने जोडलेली इतर कोणतीही सेवा. Name column रिकामा असल्यास त्या client ने ECH (encrypted client hello) वापरले आहे. त्यामुळे hostname wire वर दिसत नाही. अशा वेळी destination IP address, reverse lookup किंवा step 4 मधील proxy वापरा.

DNS (domain name system) view उपयुक्त cross-check आहे. Agent ने lookup केलेली names, connection पूर्ण झाली नसली तरी, त्यातून दिसतात.

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

प्रत्येक query line च्या शेवटी record type आणि name असते. त्याचे स्वरूप A? host.example.net. (39) असे असते. External interface ऐवजी any वर capture करा. systemd-resolved वापरल्यास application 127.0.0.53 वरील local stub listener शी संवाद साधते आणि फक्त stub बाहेरील server शी संवाद साधतो. Agent स्पष्टपणे काम करत असताना DNS traffic अजिबात दिसत नसेल, तर तो runtime स्वतः DNS over HTTPS करत आहे. अशा वेळी फक्त step 4 मधून names मिळतील.

Agent प्रत्यक्ष काम करत असताना capture घ्या. Session सुरू करा. त्याला file वाचायला सांगा. त्याच्याकडून command चालवून घ्या. एखाद्या कामात failure निर्माण करून पाहा. Startup वेळी एकदाच किंवा exception thrown झाल्यावरच निर्माण होणारा traffic idle capture मध्ये कधीच दिसत नाही. Audit मध्ये चुकीचे पण सोयीचे उत्तर मिळण्याचा सर्वात सामान्य मार्ग म्हणजे idle capture घेणे.

पायरी 4: विनंत्यांमध्ये काय आहे?

Hostname मुळे कोणाशी कनेक्शन आहे हे समजते. विनंतीमध्ये काय आहे हे पाहण्यासाठी agent च्या पुढे तुमच्या नियंत्रणाखालील proxy ठेवा आणि त्या runtime साठीच त्याची certificate authority (CA) विश्वसनीय ठरवा. यासाठी mitmproxy हे नेहमी वापरले जाणारे साधन आहे. प्रकल्प mitmproxy.org वरील standalone binaries वापरण्याची शिफारस करतो आणि Python package मार्गाचे दस्तऐवजीकरण uv tool install mitmproxy मध्ये करतो.

mitmdump -w /tmp/agent-flows.mitm

पहिल्या run मध्ये ~/.mitmproxy/ येथे CA लिहिली जाते. mitmproxy-ca-cert.pem ही फक्त त्या प्रमाणपत्राची स्वतंत्र फाइल आहे. तुम्ही agent ज्या shell मधून सुरू करणार आहात, त्या shell मध्ये client ला proxy आणि त्या प्रमाणपत्राकडे निर्देशित करा.

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"

अनेक agent CLI हे Node programs असतात. प्रक्रिया सुरू होताना Node NODE_EXTRA_CA_CERTS वाचतो. त्यामुळे agent सुरू करण्यापूर्वी ते export करा; नंतर दुसऱ्या terminal मध्ये करू नका. Python clients REQUESTS_CA_BUNDLE किंवा SSL_CERT_FILE वाचतात. standard library वापरणारा Go binary Linux वर SSL_CERT_FILE वाचतो. Agent ला दोष देण्यापूर्वी curl वापरून हा path कार्यरत आहे हे सिद्ध करा.

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

Proxy कार्यरत असल्यास 200 छापले जाते आणि विनंती mitmdump च्या output मध्ये दिसते. अविश्वसनीय CA मुळे curl: (60) SSL certificate problem: self-signed certificate in certificate chain मिळते. Node agent मध्ये याच्याशी समतुल्य त्रुटीमध्ये SELF_SIGNED_CERT_IN_CHAIN code असतो. नंतर जतन केलेले flows console viewer मधून वाचा. त्यात एक विनंती उघडून तिचे headers आणि body वाचता येतात.

mitmproxy -r /tmp/agent-flows.mitm

चार परिणाम महत्त्वाचे आहेत. विनंत्या दिसल्यास त्या वाचा आणि निर्णय घ्या. Certificate error मुळे agent सुरू होण्यास नकार देत असल्यास, ही त्या runtime मधील trust समस्या आहे; vendor विषयीचा निष्कर्ष नाही. फक्त model API दिसत असल्यास, इतर categories बंद आहेत किंवा तुम्ही trigger न केलेल्या event वर त्या कार्यरत होतात. Agent स्पष्टपणे कार्यरत असूनही काहीच दिसत नसल्यास, client proxy environment variables दुर्लक्षित करतो किंवा certificates pin करतो. अशा वेळी application setting वर सत्य सांगण्यासाठी विश्वास ठेवता येत नाही. शेवटचा परिणाम सर्वात महत्त्वाचा आहे. तो तुम्हाला पायरी 3 कडे परत पाठवतो, कारण connection दिसत असल्याचे packet capture ला नाकारता येत नाही.

कमजोर ते मजबूत नियंत्रण

नकाराधिकार सेटिंग्ज. हा सर्वात स्वस्त आणि सर्वात कमजोर पर्याय आहे, कारण तो vendor ने त्या सेटिंग्ज पाळण्यावर आणि आधीपासून अस्तित्वात असलेल्या श्रेणीला झाकण्यावर अवलंबून असतो. Reboot आणि नवीन terminal नंतरही त्या लागू राहतील अशा ठिकाणी त्या सेट करा: user settings file किंवा shell profile मध्ये. तेथेच DO_NOT_TRACK=1 जोडा. अनेक command line tools, त्यात काही agents देखील, या convention चे पालन करतात आणि त्यासाठी कोणताही खर्च येत नाही. पुढील update नंतर step 3 पुन्हा चालवा, कारण त्याच वेळी coverage बदलते.

Egress restriction. येथे विनंती करणे थांबवून अंमलबजावणी सुरू करता. Agent स्वतःच्या user म्हणून चालवा. त्या user साठी loopback आणि DNS ला परवानगी द्या आणि उर्वरित traffic drop करा. यासाठी स्वतंत्र table तयार होते. त्यामुळे विद्यमान firewall rules मध्ये बदल होत नाही.

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

ते sudo nft -f /etc/nftables.d/agent.nft वापरून लागू करा, sudo nft list table inet agentegress वापरून counter वर लक्ष ठेवा आणि sudo journalctl -k -g agent-egress-drop वापरून drops वाचा. अपेक्षित नसलेल्या hostname साठी drop counter वाढणे, हाच या उपायाचा मुख्य उद्देश आहे. दोन महत्त्वाच्या मर्यादा आहेत. meta skuid socket च्या मालकीच्या user शी जुळते. त्यामुळे त्या account मधून दुसरा user होता येत नसेल तेव्हाच हा नियम प्रभावी राहतो. Agent साठी passwordless sudo उपलब्ध असल्यास हा नियम केवळ सूचनाच ठरतो. तसेच कोणत्याही server साठी UDP 53 खुला ठेवला, तर query names मध्ये data बाहेर पाठवता येणारा channel उरतो. तुमच्या threat model नुसार आवश्यक असल्यास तोही बंद करा. त्यासाठी agent चा resolver तुम्ही चालवत असलेल्या host कडे निर्देशित करा. Hostname allowlists nftables ऐवजी proxy मध्ये ठेवणे योग्य आहे, कारण API endpoints अशा content delivery networks च्या मागे असतात ज्यांचे IP addresses तुमच्या नियंत्रणाबाहेर बदलत राहतात. या नियंत्रणाची किंमत म्हणजे breakage आणि upkeep. Package installs, SSH वरील git आणि agent ची स्वतःची update check, त्यांना परवानगी देईपर्यंत अपयशी ठरतील. आता ती यादी सांभाळण्याची जबाबदारी तुमची असेल. Laptop ऐवजी server वर हे सेट करत असल्यास, हीच account आणि firewall रचना VPS वर Claude Code सुरक्षितपणे चालवणे याची पायाभूत रचना आहे.

विल्हेवाट लावता येणारे machine. Agent साठी अशी virtual machine (VM) द्या ज्यात तुम्हाला महत्त्वाची कोणतीही credentials नसतील आणि task संपल्यावर ती नष्ट केली जाईल. यामुळे agent काय पाठवतो ते कमी होत नाही. Agent ला पाठवता येणाऱ्या सामग्रीपर्यंतचा access कमी होतो. सामान्यतः तुम्हाला महत्त्वाचा असलेला धोका हाच असतो. वरील egress rules सोबत हा उपाय वापरा, कारण unrestricted internet access असलेली नवीन VM देखील तुमच्या capture मधील प्रत्येक host पर्यंत पोहोचू शकते. ही पद्धत आणि प्रत्येक वेळी पुन्हा तयार करावी लागणारी state विल्हेवाट लावता येणाऱ्या VM मध्ये coding agents चालवणे येथे स्पष्ट केली आहे. Sizing चा प्रश्न VPS वर coding agent चालवणे येथे पाहा.

Model स्वतः host करणे. हा एकमेव असा नियंत्रण उपाय आहे जो inference flow काढून टाकतो, कारण prompt तुमच्या hardware च्या बाहेर जात नाही. याची किंमत वास्तविक आहे. Closed model स्वतः host करता येत नाही. त्यामुळे open weights निवडावे लागतात, कठीण tasks साठी capability gap स्वीकारावी लागते आणि ती models serve करण्यासाठी आवश्यक hardware द्यावे लागते. हा trade-off तुम्ही Claude स्वतः host करू शकता का येथे स्पष्ट केला आहे. मुख्य agents मधील capability differences Claude Code, Cursor, Codex आणि Copilot यांच्यातील फरक येथे दिले आहेत.

या चारपैकी कोणतेही नियंत्रण agent ला disk वर काय वाचण्याची परवानगी आहे ते बदलत नाही. Inference traffic मध्ये agent ने वाचलेली कोणतीही सामग्री असते. Working directory मध्ये .env file असल्यास, agent ने variable name साठी grep करताच ती model कडे पाठवली जाते. अशी सामग्री agent च्या access च्या बाहेर ठेवणे हे स्वतंत्र काम आहे. ते AI agent च्या context मधून secrets बाहेर ठेवणे येथे स्पष्ट केले आहे.

प्रत्येक update नंतर काय तपासावे

1. Vendor च्या settings आणि data usage पेजची तुम्ही मागील वेळी नोंदवलेल्या माहितीशी diff तुलना करा. नवीन switches आणि नावाने नमूद केलेल्या services शोधा.
2. /proc/<pid>/environ मधून process environment पुन्हा वाचा. तुमच्या opt-outs अद्याप running process वर लागू आहेत याची खात्री करा.
3. Project settings files पुन्हा print करा, कारण git pull मुळे सहकाऱ्याने बदललेली config file समाविष्ट होऊ शकते.
4. प्रत्यक्ष कामाच्या एका पूर्ण session साठी SNI capture चालवा आणि hostname list ची मागील list शी तुलना करा.
5. Firewall drop counter तपासा. नवीन destination सामान्यतः इतर कुठेही लक्षात येण्यापूर्वी तिथे दिसतो.

यासाठी सुमारे दहा मिनिटे लागतात. प्रक्रियेतील शिळी न होणारा हा एकमेव भाग आहे. August 2026 मध्ये पडताळलेला default हा August 2026 विषयीचा तथ्यात्मक निष्कर्ष आहे. Capture मात्र आजची वास्तविक स्थिती दाखवतो.

FAQ

माझा coding agent माझा code model कडे पाठवणे थांबवू शकतो का?

नाही. तसे करण्याचा दावा करणारी कोणतीही setting वेगळ्या गोष्टीचे वर्णन करत असते. तुमचा prompt, agent ने वाचलेल्या files आणि त्याने चालवलेल्या commands चे output model endpoint कडे पाठवणे हे inference कसे कार्य करते याचाच भाग आहे. त्यामुळे बदलता येणारी एकमेव गोष्ट म्हणजे ते कोणाला प्राप्त होते. Agent ला company cloud account किंवा तुम्ही स्वतः host केलेल्या model कडे निर्देश करून receiver बदलता येतो. Agent ला कोणत्या files वाचण्याची परवानगी आहे हे मर्यादित करून पाठवला जाणारा data कमी करता येतो. Analytics आणि error reporting बंद केल्याने या flow वर कोणताही परिणाम होत नाही.

माझा coding agent कोणत्या hosts शी connect होतो हे कसे पाहू?

Agent स्वतंत्र Linux user म्हणून चालवा. त्यानंतर agent वापरत असताना प्रत्येक नवीन connection चे TLS ClientHello capture करा: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. प्रत्येक connection साठी एक ओळ दिसते. त्यात destination address आणि मागवलेले hostname असते. sudo tcpdump -ni any 'udp port 53' वापरून names पडताळा. Capture any वर करा, कारण 127.0.0.53 वरील local resolver stub आधी query हाताळतो. Agent प्रत्यक्ष काम करत असताना capture करा. Startup pings आणि crash reports idle capture मध्ये कधीही दिसत नाहीत.

Agent कार्यरत असताना माझ्या proxy मध्ये कोणताही traffic दिसत नाही. काय चुकले?

एकतर client HTTP_PROXY आणि HTTPS_PROXY दुर्लक्षित करतो, किंवा तो certificates pin करतो आणि तुमचा CA नाकारतो. प्रथम curl वापरून path ची चाचणी करा. curl proxy मार्फत internet पर्यंत पोहोचत असेल आणि agent flow list मध्ये दिसत नसेल, तर agent proxy environment variables वापरत नाही. काही runtimes मध्ये CA विशिष्ट पद्धतीने द्यावा लागतो. विशेषतः Node NODE_EXTRA_CA_CERTS फक्त process सुरू होताना वाचतो. त्यामुळे agent सुरू केल्यानंतर ते export केल्याने काहीही परिणाम होत नाही. Proxy ला traffic दिसत नसेल, तर packet capture वापरा. कोणतीही application setting हा capture bypass करू शकत नाही.

Telemetry बंद केल्याने माझा code training साठी वापरला जाणे थांबते का?

नाही. Analytics आणि crash reporting हा inference पेक्षा वेगळा flow आहे. त्यामुळे ते बंद केल्याने usage counters आणि stack traces काढले जातात; मात्र प्रत्येक prompt पूर्वीप्रमाणेच model कडे जातो. हे prompts साठवले जातील का आणि त्यांचा वापर भविष्यातील model train करण्यासाठी केला जाईल का, हे तुमच्या plan च्या terms वर अवलंबून असते. Consumer plans आणि commercial plans यांमध्ये साधारणपणे फरक असतो. हा packet capture करण्याचा विषय नसून वाचण्यासारखा contract आहे. त्यामुळे तुमच्या plan साठी data usage page तपासा. जिथे आवश्यक असेल, तिथे पहिल्या session पूर्वी commercial किंवा zero-retention agreement निश्चित करा.