Coding agent telemetry में कौन सा डेटा भेजा जाता है?

कोडिंग एजेंट टेलीमेट्री वास्तव में क्या कवर करती है

कोडिंग एजेंट टेलीमेट्री चार अलग-अलग डेटा प्रवाहों का समूह है, जिन्हें एक ही शब्द से संबोधित किया जाता है, और प्रत्येक प्रवाह का अपना नियंत्रण होता है। मॉडल इन्फरेंस आपके प्रॉम्प्ट्स और आपके कोड को उस सेवा प्रदाता तक ले जाता है जो मॉडल को होस्ट करता है, और इसे बंद करने के लिए कोई सेटिंग उपलब्ध नहीं है। प्रोडक्ट एनालिटिक्स और क्रैश रिपोर्ट्स वेंडर के पास जाती हैं, और अक्सर उस लॉगिंग कंपनी के पास भी जिन्हें वेंडर भुगतान करता है। ट्रेनिंग के लिए डेटा रिटेंशन एक कॉन्ट्रैक्ट संबंधी प्रश्न है, न कि नेटवर्क संबंधी। चौथा प्रवाह वह है जिसे लोग अक्सर अनदेखा कर देते हैं: आपके द्वारा जोड़ा गया प्रत्येक इंटीग्रेशन किसी ऐसे होस्ट से कनेक्शन खोल सकता है जिसे आपने कभी चुना ही नहीं था।

वर्तमान वेंडर डिफॉल्ट्स की सूची इस विषय का वह हिस्सा है जो सबसे तेजी से पुराना होता है। एक रिलीज किसी डिफॉल्ट सेटिंग को बदल सकती है, और एक नया फीचर ऐसा डेस्टिनेशन जोड़ सकता है जिसे कोई मौजूदा स्विच कवर नहीं करता। इसलिए, सबसे महत्वपूर्ण कौशल वह ऑडिट है जिसे आप किसी भी एजेंट के खिलाफ दोहरा सकते हैं: वेंडर के डॉक्यूमेंटेशन को पढ़ें, जांचें कि इस मशीन पर वास्तव में कौन सी कॉन्फ़िगरेशन लागू है, मशीन से ही प्रोसेस को मॉनिटर करें, और फिर उन कंट्रोल्स को चुनें जिनके लिए आप भुगतान करने को तैयार हैं। नीचे दिए गए प्रत्येक कमांड को आप अपनी मशीन पर, अपने स्वयं के ट्रैफिक के विरुद्ध चला सकते हैं।

चार श्रेणियां, और उन्हें अलग-अलग नियंत्रणों की आवश्यकता क्यों है

Model inference traffic अपरिहार्य है। एजेंट आपके प्रॉम्प्ट, उसके द्वारा पढ़ी गई फाइलें, उसके द्वारा चलाए गए कमांड्स का आउटपुट और स्वयं उत्पन्न टेक्स्ट को एक मॉडल एंडपॉइंट पर भेजता है। यह उत्पाद के कार्य करने का तरीका है। एकमात्र वास्तविक निर्णय यह है कि इसे कौन प्राप्त करता है: किसी और द्वारा संचालित API, या आपके द्वारा स्वयं चलाया जाने वाला मॉडल। एक कंपनी क्लाउड अकाउंट (Bedrock, Vertex, Foundry) प्राप्तकर्ता को बदलता है, लेकिन यह प्रवाह को हटाता नहीं है। इस पोस्ट के बाकी हिस्सों में कुछ भी inference traffic को कम नहीं करता है, इसलिए इसे अपने दिमाग में अन्य तीन से अलग रखें।

Product analytics और crash reporting अलग-अलग होस्ट के लिए अलग प्रवाह हैं। उपयोग काउंटर, लेटेंसी नंबर, फीचर-फ्लैग लुकअप और स्टैक ट्रेस सामान्यतः उन होस्टनेम पर जाते हैं जिनका मॉडल API से कोई लेना-देना नहीं होता है, और अक्सर किसी थर्ड-पार्टी एरर ट्रैकर पर जाते हैं। वेंडर आमतौर पर इन्हें "मेट्रिक्स" और "एरर रिपोर्ट" के रूप में प्रलेखित करते हैं और आमतौर पर आपको प्रति श्रेणी एक environment variable देते हैं। इनकी मात्रा बहुत कम होती है, इसलिए बाइट काउंट से आप इन्हें कभी नहीं ढूंढ पाएंगे। आप होस्टनेम की तलाश कर रहे हैं, बैंडविड्थ की नहीं।

Retention और training नीति है, पैकेट नहीं। वेंडर आपके प्रॉम्प्ट को रखता है या नहीं, कितनी देर तक रखता है, और क्या वे उन पर भविष्य के किसी मॉडल को प्रशिक्षित करते हैं, यह आपके प्लान से जुड़ी शर्तों में लिखा होता है। कंज्यूमर प्लान और कमर्शियल प्लान आमतौर पर अलग होते हैं, और zero-retention व्यवस्था आमतौर पर एक अलग समझौता होता है। आप tcpdump के साथ इनमें से किसी की भी पुष्टि नहीं कर सकते हैं, क्योंकि पैकेट दोनों ही स्थितियों में समान दिखता है। शर्तों को पढ़ें, और यदि यह आपके नियोक्ता के लिए मायने रखता है, तो इसे लिखित रूप में प्राप्त करें।

Integrations चुपचाप एक हॉप जोड़ते हैं। एक MCP (model context protocol) सर्वर, एक प्लगइन मार्केटप्लेस, एक ऑटो-अपडेट चेक, एक वेब सर्च टूल, एक सुरक्षा चेक जो URL को फेच करने से पहले उसे रिजॉल्व करता है: प्रत्येक एक ऐसे होस्ट के लिए अनुरोध है जो मॉडल एंडपॉइंट नहीं है। यहीं पर आश्चर्य छिपे होते हैं, क्योंकि एक हार्नेस उस काम को, जिसे आपने स्थानीय माना था, अपनी स्वयं की सेवा के माध्यम से रूट कर सकता है, और एक रिलीज आपके कॉन्फ़िगरेशन की एक भी लाइन बदले बिना ऐसा करना शुरू कर सकती है। आपके द्वारा जोड़े गए प्रत्येक टूल को तब तक एक नए गंतव्य के रूप में मानें जब तक कि आपने उसे नेटवर्क पर मॉनिटर न कर लिया हो।

चरण 1: वेंडर क्या डॉक्यूमेंट करता है?

अपने agent के लिए settings reference और data usage पेज खोलें, और उन्हें इन शब्दों की सूची के साथ पढ़ें: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace। इनमें से प्रत्येक शब्द आमतौर पर एक अलग switch होता है। सटीक variable names लिख लें, क्योंकि चरण 2 में उन्हें grep करना होगा।

एक शब्द आपको भ्रमित कर सकता है। कई agents में, docs में "telemetry" का अर्थ OpenTelemetry export होता है जिसे आप अपने द्वारा चलाए जा रहे collector पर metrics भेजने के लिए configure करते हैं, जो वेंडर को जाने वाले डेटा के बिल्कुल विपरीत है। Claude Code इनमें से एक है: CLAUDE_CODE_ENABLE_TELEMETRY=1 सेट करने से आपके द्वारा OTEL_EXPORTER_OTLP_ENDPOINT में नामित endpoint पर export शुरू हो जाता है, और इसका वेंडर के स्वयं के analytics से कोई संबंध नहीं है, जिसके लिए opt-out की प्रक्रिया अलग है। कुछ भी सेट करने से पहले यह पता लगा लें कि डेटा किस दिशा में प्रवाहित हो रहा है।

एक master switch की अपेक्षा रखें, और यह भी उम्मीद रखें कि उसमें कमियां होंगी। अगस्त 2026 तक, Claude Code का CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC metrics, error reports, feedback command और session surveys को एक साथ बंद कर देता है, और वही documentation कहता है कि यह WebFetch domain safety check को कवर नहीं करता है, जो उस hostname को वेंडर API पर भेजता है जिसे आप fetch करने वाले हैं और इसकी अपनी अलग setting होती है। यह किसी एक product के बारे में शिकायत नहीं है। यह हर जगह समस्या का स्वरूप है: एक master switch केवल उन श्रेणियों को कवर करता है जो इसके लिखे जाने के समय मौजूद थीं।

यह भी उम्मीद रखें कि opt-out की आपको कोई कीमत चुकानी पड़ेगी। वही docs नोट करते हैं कि telemetry को disable करने से feature-flag evaluation भी disable हो जाता है जिस पर कुछ features निर्भर करते हैं, इसलिए privacy के लिए flip किया गया switch आपके द्वारा उपयोग किए जाने वाले feature को बंद कर सकता है, बिना किसी error message के जो दोनों को आपस में जोड़ता हो। केवल flag का नाम न पढ़ें, बल्कि flag के बगल में लिखे वाक्य को भी पढ़ें।

चरण 2: वास्तव में कौन सा कॉन्फ़िगरेशन लागू हुआ?

आपके द्वारा लिखी गई सेटिंग जरूरी नहीं कि वही हो जो लागू हुई है। एजेंट्स कई फाइलों से कॉन्फ़िगरेशन को मर्ज करते हैं, और उनमें से एक उस रिपॉजिटरी के अंदर होती है जिसे आपने अभी किसी और से क्लोन किया है। अपने शेल के एनवायरनमेंट से शुरुआत करें।

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

इसके बाद उन सभी सेटिंग्स फाइलों को प्रिंट करें जिन्हें टूल पढ़ता है, उसी क्रम में जैसा कि डॉक्यूमेंटेशन में दिया गया है। Claude Code के लिए, अगस्त 2026 तक, यह यूजर फाइल, दो प्रोजेक्ट फाइलें और 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

git clone के साथ आई प्रोजेक्ट फाइल किसी अनजान व्यक्ति द्वारा लिखा गया कॉन्फ़िगरेशन है, और यह उन सेटिंग्स को फिर से इनेबल कर सकती है जिन्हें आपकी यूजर फाइल ने बंद कर दिया था। यदि एजेंट के पास कोई स्टेटस कमांड है जो यह सूचीबद्ध करता है कि उसने कौन से स्रोत लोड किए हैं, तो वह सबसे तेज़ और सटीक तरीका है: Claude Code लोड किए गए सेटिंग्स स्रोतों को /status में प्रिंट करता है।

सबसे मजबूत जांच किसी भी फाइल के बजाय चल रही प्रोसेस को पढ़ना है। एजेंट को पहले अपना स्वयं का Linux यूजर अकाउंट दें, जिससे इस पोस्ट की हर कमांड छोटी हो जाएगी, फिर उस एनवायरनमेंट को पढ़ें जिसके साथ प्रोसेस शुरू की गई थी।

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

/proc/<pid>/environ उन वेरिएबल्स को दिखाता है जो प्रोसेस के पास exec समय पर थे, इसलिए यह उस स्थिति को पकड़ लेता है जहाँ आपका .bashrc एक्सपोर्ट systemd द्वारा शुरू की गई सर्विस तक कभी नहीं पहुँचा। यदि आपके द्वारा सेट किया गया कोई वेरिएबल यहाँ मौजूद नहीं है, तो वह कभी भी प्रभावी नहीं था, चाहे आपकी डॉटफाइल्स कुछ भी कहें।

चरण 3: यह किन hosts से connect करता है?

उन open sockets से शुरुआत करें, जिन्हें उस account द्वारा filter किया गया है जिस पर agent चलता है।

sudo ss -tnpe state established

-e प्रत्येक line में एक uid: field जोड़ता है, ताकि आप process names को पढ़े बिना agent के connections को अपने browser से अलग कर सकें। remote addresses को note करें, फिर उनके पीछे के names प्राप्त करें। names का सबसे स्पष्ट स्रोत TLS (transport layer security) handshake है, क्योंकि प्रत्येक नया connection एक ClientHello के साथ शुरू होता है जिसमें SNI (server name indication) field होता है, जो वह hostname है जिसे 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

आपको प्रत्येक नए connection के लिए एक line मिलती है, जो बिल्कुल वही inventory है जिसकी आपको आवश्यकता है: model API, update server, analytics host, error tracker, और कोई भी ऐसी चीज़ जिसे integration ने जोड़ा है। एक खाली name column का मतलब है कि client ने ECH (encrypted client hello) का उपयोग किया है, इसलिए hostname wire पर दिखाई नहीं दे रहा है, और आप destination IP address, reverse lookup, या चरण 4 में proxy पर वापस आ जाते हैं।

DNS (domain name system) view एक उपयोगी cross-check है, क्योंकि यह उन names को दिखाता है जिन्हें agent ने उन connections के लिए भी lookup किया जिन्हें उसने पूरा नहीं किया।

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

प्रत्येक query line record type और name के साथ समाप्त होती है, जो A? host.example.net. (39) के रूप में होती है। बाहरी interface के बजाय any पर capture करें, क्योंकि systemd-resolved के साथ application 127.0.0.53 पर एक local stub listener से बात करती है और केवल stub ही बाहर से बात करता है। यदि आपको DNS traffic बिल्कुल नहीं दिखता है जबकि agent स्पष्ट रूप से काम कर रहा है, तो वह runtime स्वयं DNS over HTTPS कर रहा है, और केवल चरण 4 ही आपको names देगा।

जब agent वास्तविक काम कर रहा हो, तब capture करें। एक session शुरू करें, उससे एक file पढ़वाएं, उससे एक command चलवाएं, उससे किसी चीज़ में fail करवाएं। जो traffic startup पर एक बार fire होता है, या केवल तब जब कोई exception throw होता है, वह कभी भी idle capture में दिखाई नहीं देता है, और एक idle capture वह सबसे आम तरीका है जिससे audit एक आरामदायक गलत उत्तर तक पहुँचता है।

चरण 4: requests के अंदर क्या है?

Hostnames आपको यह बताते हैं कि कौन है। यह देखने के लिए कि क्या है, agent के सामने अपना एक proxy रखें और उस runtime के लिए उसके certificate authority (CA) पर भरोसा करें। mitmproxy इसके लिए सबसे आम tool है। यह project mitmproxy.org से standalone binaries का उपयोग करने की सलाह देता है, और uv tool install mitmproxy को Python package के रूप में उपयोग करने का तरीका बताता है।

mitmdump -w /tmp/agent-flows.mitm

पहली बार चलाने पर यह एक CA को ~/.mitmproxy/ में लिखता है, जहाँ mitmproxy-ca-cert.pem स्वयं certificate है। जिस shell से आप agent को launch करेंगे, उसमें client को proxy और उस certificate की ओर point करें।

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 CLIs Node programs होते हैं, और process शुरू होने पर Node NODE_EXTRA_CA_CERTS को पढ़ता है, इसलिए agent को launch करने से पहले इसे export करें, न कि बाद में किसी अन्य terminal में। Python clients REQUESTS_CA_BUNDLE या SSL_CERT_FILE को पढ़ते हैं, और Linux पर standard library का उपयोग करने वाली Go binary SSL_CERT_FILE को पढ़ती है। agent को दोष देने से पहले curl के साथ यह सुनिश्चित करें कि path काम कर रहा है।

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

एक कार्यशील proxy 200 print करता है और request mitmdump के output में दिखाई देती है। एक untrusted CA curl: (60) SSL certificate problem: self-signed certificate in certificate chain देता है, और Node agent से इसका समकक्ष परिणाम SELF_SIGNED_CERT_IN_CHAIN code वाला एक error होता है। बाद में console viewer के साथ saved flows को पढ़ें, जहाँ आप एक request को खोलकर उसके headers और body को पढ़ सकते हैं।

mitmproxy -r /tmp/agent-flows.mitm

चार परिणाम उल्लेखनीय हैं। आप requests देखते हैं, ऐसी स्थिति में उन्हें पढ़ें और निर्णय लें। agent certificate error के साथ शुरू होने से मना कर देता है, जो उस runtime में trust की समस्या है न कि vendor के बारे में कोई निष्कर्ष। आप केवल model API देखते हैं, जिसका अर्थ है कि अन्य categories बंद हैं, या वे किसी ऐसी घटना पर सक्रिय होती हैं जिसे आपने trigger नहीं किया है। या फिर आप कुछ भी नहीं देखते जबकि agent स्पष्ट रूप से काम कर रहा है, जिसका अर्थ है कि client proxy environment variables को ignore कर रहा है या अपने certificates को pin कर चुका है, और किसी भी application setting पर भरोसा नहीं किया जा सकता कि वह आपको सच बताएगी। वह अंतिम परिणाम सबसे महत्वपूर्ण है, और यह आपको चरण 3 पर वापस भेजता है, क्योंकि packet capture को connection देखने से रोका नहीं जा सकता।

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

Opt-out सेटिंग्स। यह सबसे सस्ता और सबसे कमजोर तरीका है, क्योंकि यह इस पर निर्भर करता है कि वेंडर इनका सम्मान करे और यह उस श्रेणी को कवर करे जो पहले से मौजूद है। इन्हें वहां सेट करें जहाँ ये रीबूट और नए टर्मिनल के बाद भी बने रहें, जैसे कि यूजर सेटिंग्स फाइल या आपके शेल प्रोफाइल में। ऐसा करते समय DO_NOT_TRACK=1 को भी जोड़ें: यह एक ऐसा कन्वेंशन है जिसका कई कमांड लाइन टूल्स सम्मान करते हैं, जिनमें कुछ एजेंट्स भी शामिल हैं, और इसे लागू करने में कोई अतिरिक्त लागत नहीं आती। फिर अगले अपडेट के बाद स्टेप 3 को दोबारा चलाएं, क्योंकि उसी समय कवरेज में बदलाव होता है।

Egress प्रतिबंध। यहाँ आप अनुरोध करना बंद करते हैं और लागू करना शुरू करते हैं। एजेंट को उसके अपने यूजर के रूप में चलाएं, फिर उस यूजर को लूपबैक और DNS की अनुमति दें और बाकी को ड्रॉप कर दें। यह अपनी खुद की टेबल जोड़ता है, इसलिए यह किसी भी मौजूदा फायरवॉल नियमों को प्रभावित नहीं करता है।

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 के साथ काउंटर पर नजर रखें, और sudo journalctl -k -g agent-egress-drop के साथ ड्रॉप्स को पढ़ें। एक बढ़ता हुआ ड्रॉप काउंटर, जिसमें ऐसा होस्टनेम हो जिसकी आपको उम्मीद नहीं थी, यही इस अभ्यास का मुख्य उद्देश्य है। दो ईमानदार सीमाएं। meta skuid उस यूजर से मेल खाता है जिसके पास सॉकेट है, इसलिए यह तभी तक प्रभावी है जब तक वह अकाउंट किसी अन्य यूजर में न बदल सके: एजेंट के लिए पासवर्ड रहित sudo इस नियम को केवल एक सुझाव बना देता है। और UDP 53 को किसी भी सर्वर के लिए खुला छोड़ने से एक ऐसा चैनल बना रहता है जो क्वेरी नामों में डेटा बाहर भेज सकता है, इसलिए यदि आपका थ्रेट मॉडल इसकी मांग करता है तो इसे भी बंद कर दें, इसके लिए एजेंट के रिजॉल्वर को उस होस्ट पर पॉइंट करें जिसे आप चलाते हैं। होस्टनेम अलाउलिस्ट nftables के बजाय प्रॉक्सी में होनी चाहिए, क्योंकि API एंडपॉइंट्स कंटेंट डिलीवरी नेटवर्क्स के पीछे होते हैं जिनके IP एड्रेस बदलते रहते हैं। इस नियंत्रण की कीमत है रुकावटें और रखरखाव: पैकेज इंस्टॉलेशन, SSH पर git और एजेंट का अपना अपडेट चेक, ये सभी तब तक विफल रहेंगे जब तक आप उन्हें अनुमति नहीं देते, और अब उस लिस्ट को बनाए रखने की जिम्मेदारी आपकी है। यदि आप इसे लैपटॉप के बजाय सर्वर पर सेट कर रहे हैं, तो वही अकाउंट और फायरवॉल लेआउट VPS पर सुरक्षित रूप से Claude Code चलाने का आधार है।

एक डिस्पोजेबल मशीन। एजेंट को एक वर्चुअल मशीन (VM) दें जिसमें आपके काम के कोई क्रेडेंशियल्स न हों और जो कार्य के अंत में नष्ट हो जाए। यह एजेंट द्वारा भेजे जाने वाले डेटा को कम नहीं करता, बल्कि यह उस डेटा को कम करता है जिसे भेजने की एजेंट के पास पहुंच है, जो आमतौर पर वही जोखिम है जिसकी आपको वास्तव में चिंता होती है। इसे ऊपर दिए गए Egress नियमों के साथ मिलाएं, क्योंकि बिना किसी प्रतिबंध के इंटरनेट एक्सेस वाली एक नई VM भी आपके कैप्चर में मौजूद हर होस्ट तक पहुंच सकती है। यह विधि, और वह स्टेट जिसे आपको हर बार फिर से बनाना पड़ता है, डिस्पोजेबल VM में कोडिंग एजेंट्स चलाने में कवर की गई है, और साइजिंग का प्रश्न VPS पर कोडिंग एजेंट चलाने में दिया गया है।

मॉडल को सेल्फ-होस्ट करना। यह एकमात्र नियंत्रण है जो इन्फरेंस फ्लो को हटा देता है, क्योंकि प्रॉम्प्ट कभी भी आपके हार्डवेयर से बाहर नहीं जाता। इसकी कीमत वास्तविक है: आप एक क्लोज्ड मॉडल को सेल्फ-होस्ट नहीं कर सकते, इसलिए इसका मतलब है ओपन वेट्स को चुनना और कठिन कार्यों पर क्षमता के अंतर को स्वीकार करना, साथ ही उन्हें सर्व करने के लिए हार्डवेयर का खर्च उठाना। इस ट्रेड-ऑफ पर क्या आप Claude को सेल्फ-होस्ट कर सकते हैं में विस्तार से चर्चा की गई है, और मुख्य एजेंट्स के बीच क्षमता के अंतर Claude Code, Cursor, Codex और Copilot में क्या अंतर है में बताए गए हैं।

इनमें से कोई भी चार नियंत्रण यह नहीं बदलते कि एजेंट को डिस्क पर क्या पढ़ने की अनुमति है, और इन्फरेंस ट्रैफिक वह सब कुछ ले जाता है जिसे वह पढ़ता है। यदि कोई .env फाइल वर्किंग डायरेक्टरी में है, तो जैसे ही एजेंट किसी वेरिएबल नाम के लिए grep करता है, वह मॉडल के पास चली जाती है। उस सामग्री को पहुंच से दूर रखना एक अलग कार्य है, जो AI एजेंट के कॉन्टेक्स्ट से सीक्रेट्स को दूर रखने में कवर किया गया है।

हर अपडेट के बाद क्या जाँचें

1. वेंडर के settings और data usage पेजों की तुलना पिछली बार रिकॉर्ड किए गए डेटा से करें, और नए switches तथा नई named services को देखें।
2. चल रही process पर आपके opt-outs अभी भी लागू हैं या नहीं, यह पुष्टि करने के लिए /proc/<pid>/environ से process environment को दोबारा पढ़ें।
3. project settings फाइलों को फिर से प्रिंट करें, क्योंकि git pull के कारण ऐसी config फाइल आ सकती है जिसे किसी सहकर्मी ने बदल दिया हो।
4. वास्तविक काम के एक पूरे session के लिए SNI capture चलाएं और hostname सूची की तुलना अपनी पिछली सूची से करें।
5. firewall drop counter की जाँच करें, क्योंकि कोई भी नया destination आमतौर पर कहीं और दिखने से पहले वहीं दिखाई देता है।

इसमें लगभग दस मिनट लगते हैं और यह प्रक्रिया का एकमात्र हिस्सा है जो पुराना नहीं होता। अगस्त 2026 में सत्यापित किया गया कोई default केवल अगस्त 2026 के बारे में एक तथ्य है। जबकि capture आज के बारे में एक तथ्य है।

FAQ

क्या मैं अपने कोडिंग एजेंट को मेरा कोड मॉडल पर भेजने से रोक सकता हूँ?

नहीं, और जो भी सेटिंग ऐसा करने का दावा करती है, वह वास्तव में कुछ और ही कर रही होती है। आपका प्रॉम्प्ट, एजेंट द्वारा पढ़ी गई फाइलें और उसके द्वारा चलाए गए कमांड्स का आउटपुट मॉडल एंडपॉइंट पर भेजना ही इन्फरेंस (inference) का कार्य करने का तरीका है, इसलिए एकमात्र अंतर यह है कि इसे प्राप्त कौन कर रहा है। आप एजेंट को किसी कंपनी क्लाउड अकाउंट या स्वयं द्वारा होस्ट किए गए मॉडल की ओर निर्देशित करके रिसीवर बदल सकते हैं, और आप एजेंट को पढ़ने की अनुमति सीमित करके यह कम कर सकते हैं कि वह क्या भेजता है। एनालिटिक्स और एरर रिपोर्टिंग को बंद करने से इस प्रक्रिया पर कोई प्रभाव नहीं पड़ता है।

मैं यह कैसे देखूँ कि मेरा कोडिंग एजेंट किन होस्ट्स से कनेक्ट होता है?

एजेंट को उसके अपने Linux यूजर के रूप में चलाएँ, फिर जब आप इसका उपयोग कर रहे हों तो हर नए कनेक्शन के TLS ClientHello को कैप्चर करें: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name। प्रत्येक कनेक्शन के लिए एक लाइन दिखाई देगी, जिसमें डेस्टिनेशन एड्रेस और अनुरोधित होस्टनेम होगा। sudo tcpdump -ni any 'udp port 53' के साथ नामों की क्रॉस-चेक करें, और any पर कैप्चर करें क्योंकि 127.0.0.53 पर एक लोकल रिजॉल्वर स्टब सबसे पहले क्वेरी को हैंडल करता है। कैप्चर तब करें जब एजेंट वास्तविक काम कर रहा हो, क्योंकि स्टार्टअप पिंग्स और क्रैश रिपोर्ट्स कभी भी आइडल कैप्चर में दिखाई नहीं देते हैं।

जब एजेंट काम करता है तो मेरा प्रॉक्सी कोई ट्रैफिक नहीं दिखाता। क्या गलत हुआ?

या तो क्लाइंट HTTP_PROXY और HTTPS_PROXY को अनदेखा कर रहा है, या यह अपने सर्टिफिकेट्स को पिन (pin) कर रहा है और आपके CA को अस्वीकार कर रहा है। पहले curl के साथ पाथ का परीक्षण करें: यदि curl प्रॉक्सी के माध्यम से इंटरनेट तक पहुँचता है और एजेंट फ्लो लिस्ट में दिखाई नहीं देता है, तो एजेंट प्रॉक्सी एनवायरनमेंट वेरिएबल्स का उपयोग नहीं कर रहा है। कुछ रनटाइम्स को CA को एक विशिष्ट तरीके से सप्लाई करने की आवश्यकता होती है, और विशेष रूप से Node केवल प्रोसेस शुरू होने पर ही NODE_EXTRA_CA_CERTS को पढ़ता है, इसलिए एजेंट को लॉन्च करने के बाद इसे एक्सपोर्ट करने का कोई लाभ नहीं होता है। जब प्रॉक्सी ट्रैफिक नहीं देख पाता है, तो पैकेट कैप्चर का उपयोग करें, जिसे कोई भी एप्लिकेशन सेटिंग बायपास नहीं कर सकती है।

क्या टेलीमेट्री बंद करने से मेरा कोड ट्रेनिंग के लिए उपयोग होने से रुक जाता है?

नहीं। एनालिटिक्स और क्रैश रिपोर्टिंग इन्फरेंस से अलग फ्लो हैं, इसलिए उन्हें डिसेबल करने से केवल यूसेज काउंटर्स और स्टैक ट्रेसेस हटते हैं, जबकि हर प्रॉम्प्ट पहले की तरह ही मॉडल पर जाता रहता है। क्या उन प्रॉम्प्ट्स को रिटेन (retain) किया जाता है, और क्या वे भविष्य के मॉडल को ट्रेन करते हैं, यह आपके प्लान की शर्तों द्वारा निर्धारित होता है, और कंज्यूमर प्लान तथा कमर्शियल प्लान आमतौर पर अलग होते हैं। यह एक ऐसा अनुबंध है जिसे पढ़ने की आवश्यकता है, न कि कैप्चर करने के लिए कोई पैकेट, इसलिए अपने प्लान के लिए डेटा यूसेज पेज देखें और जहाँ आवश्यक हो, पहले सेशन से पहले एक कमर्शियल या जीरो-रिटेंशन एग्रीमेंट सुनिश्चित करें।