Coding agent telemetry ఏ data పంపుతుంది?

కోడింగ్ agent telemetry వాస్తవంగా ఏ డేటాను కలిగి ఉంటుంది

Coding agent telemetry అనేది ఒకే పదంతో సూచించే నాలుగు వేర్వేరు data flows. ప్రతి flow కు ప్రత్యేక నియంత్రణ ఉంటుంది. Model inference సమయంలో మీ prompts మరియు code ను model ను అందించే సంస్థకు పంపిస్తారు. ఏ setting కూడా దీన్ని నిలిపివేయదు. Product analytics మరియు crash reports vendor కు, అలాగే తరచుగా vendor చెల్లించే logging company కు పంపబడతాయి. Training కోసం data retention అనేది network సమస్య కంటే contract కు సంబంధించిన ప్రశ్న. చాలామంది గమనించని నాలుగో flow ఇది: మీరు జోడించే ప్రతి integration, మీరు ఎన్నడూ ఎంచుకోని host కు connection ను తెరవవచ్చు.

ప్రస్తుత vendor defaults జాబితా ఈ అంశంలో వేగంగా పాతబడే భాగం. ఒక release default ను మార్చవచ్చు. కొత్త feature ఇప్పటికే ఉన్న switch ఏదీ నియంత్రించని destination ను జోడించవచ్చు. అందువల్ల ఎలాంటి agent పైనైనా పునరావృతం చేయగల audit నేర్చుకోవాల్సిన స్థిరమైన నైపుణ్యం. Vendor documentation ఏమి చెబుతుందో చదవండి. ఈ machine పై వాస్తవంగా ఏ config అమలైందో తనిఖీ చేయండి. Machine నుంచే process ను monitor చేయండి. తరువాత మీరు స్వీకరించడానికి సిద్ధంగా ఉన్న controls ను ఎంచుకోండి. దిగువనున్న ప్రతి command ను మీ స్వంత machine పై, మీ స్వంత traffic కు వర్తింపజేసి నడపాలి.

నాలుగు వర్గాలు, వాటికి వేర్వేరు నియంత్రణలు ఎందుకు అవసరం

Model inference traffic తప్పనిసరి. Agent మీ prompt, అది చదివిన files, అది అమలు చేసిన commands output, అలాగే అది స్వయంగా రూపొందించిన text ను model endpoint కు పంపుతుంది. Product పనిచేసే విధానం ఇదే. దీన్ని ఎవరు స్వీకరిస్తారు అనేదే అసలు నిర్ణయం: మరొకరు నిర్వహించే APIనా, లేదా మీరు స్వయంగా నడిపే modelనా? కంపెనీ cloud account (Bedrock, Vertex, Foundry) స్వీకర్తను మారుస్తుంది; ఈ data flow ను తొలగించదు. ఈ post లోని మిగతా అంశాల్లో ఏదీ 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"గా document చేస్తారు. ప్రతి వర్గానికి సాధారణంగా ఒక environment variable ఇస్తారు. ఈ traffic పరిమాణం చాలా తక్కువగా ఉంటుంది. అందువల్ల byte counts తో దీన్ని ఎప్పటికీ గుర్తించలేరు. మీరు bandwidth ను కాదు, hostnames ను పరిశీలించాలి.

Retention మరియు training అనేవి policyకి సంబంధించినవి, packets కు సంబంధించినవి కావు. 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. ఆశ్చర్యాలు ఎక్కువగా ఇక్కడే ఉంటాయి. మీరు local గా జరుగుతుందని భావించిన పనిని harness తన సొంత service ద్వారా route చేయవచ్చు. మీ config లో ఒక్క line కూడా మారకుండానే release ఈ విధంగా పనిచేయడం ప్రారంభించవచ్చు. మీరు జోడించే ప్రతి tool ను wire పై దాని traffic ను పరిశీలించే వరకు కొత్త destination గా పరిగణించండి.

దశ 1: vendor ఏమి document చేసింది?

మీ agent కోసం settings reference మరియు data usage page తెరిచి, word list చేతిలో ఉంచుకుని వాటిని చదవండి: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. సాధారణంగా వీటిలో ప్రతి పదానికి వేరు switch ఉంటుంది. ఖచ్చితమైన variable names ను రాసి పెట్టండి, ఎందుకంటే దశ 2 వాటితో grep చేస్తుంది.

ఒక పదం మిమ్మల్ని తప్పుదారి పట్టించవచ్చు. అనేక agents లో docs లోని "telemetry" అంటే మీరు నడుపుతున్న collector కు metrics పంపేలా configure చేసే OpenTelemetry export అని అర్థం. అంటే data vendor వద్దకు వెళ్లడమే కాదు, దానికి విరుద్ధమైన దిశ. Claude Code అందులో ఒకటి: CLAUDE_CODE_ENABLE_TELEMETRY=1 ను సెట్ చేస్తే, OTEL_EXPORTER_OTLP_ENDPOINT లో మీరు పేర్కొన్న endpoint కు export ప్రారంభమవుతుంది. దీనికి vendor యొక్క స్వంత analytics తో సంబంధం లేదు; వాటికి వేరే opt-out ఉంటుంది. ఏ setting అమలు చేయాలో నిర్ణయించే ముందు data ఏ దిశలో ప్రవహిస్తుందో నిర్ధారించండి.

ఒక master switch ఉంటుందని, దానిలో కొన్ని మినహాయింపులు ఉంటాయని ఊహించండి. August 2026 నాటికి, Claude Code లోని CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC metrics, error reports, feedback command మరియు session surveys ను ఒకేసారి నిలిపివేస్తుంది. అయితే WebFetch domain safety check దాని పరిధిలోకి రాదని అదే documentation చెబుతుంది. మీరు fetch చేయబోయే hostname ను ఈ check vendor API కు పంపుతుంది, దీనికి వేరే setting ఉంటుంది. ఇది ఒకే product పై చేసిన ఫిర్యాదు కాదు. ప్రతిచోటా సమస్య స్వరూపం ఇదే: master switch రాసిన సమయంలో ఇప్పటికే ఉన్న categories ను మాత్రమే కవర్ చేస్తుంది.

Opt-out కు కూడా కొంత ఖర్చు ఉంటుందని గుర్తుంచుకోండి. అదే docs ప్రకారం, telemetry ని disable చేస్తే కొన్ని features ఆధారపడే feature-flag evaluation కూడా disable అవుతుంది. అందువల్ల privacy కోసం మార్చిన switch, మీరు ఉపయోగించే ఒక feature ను కూడా నిలిపివేయవచ్చు. ఈ రెండింటి మధ్య సంబంధాన్ని చూపించే error message ఉండకపోవచ్చు. Flag name మాత్రమే కాకుండా, దాని పక్కన ఉన్న sentence ను కూడా చదవండి.

దశ 2: వాస్తవంగా ఏ configuration వర్తించింది?

మీరు రాసిన setting, వర్తించిన setting అని అర్థం కాదు. Agents అనేక files నుంచి configuration ను merge చేస్తాయి. వాటిలో ఒకటి మీరు మరొకరి repository నుంచి ఇప్పుడే clone చేసిన repository లో ఉంటుంది. ముందుగా మీ స్వంత shell యొక్క environment తో ప్రారంభించండి.

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

తర్వాత tool చదివే ప్రతి settings file ను, documentation ఇచ్చిన క్రమంలో 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, వేరొకరు రాసిన configuration. అది మీ user fileలో నిలిపివేసిన setting ను మళ్లీ enable చేయగలదు. Agent load చేసిన sources ఏవో చూపించే status command కలిగి ఉంటే, అదే అత్యంత వేగవంతమైన ground truth. Claude Code load చేసిన 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 exec సమయంలో కలిగి ఉన్న variables. అందువల్ల మీ .bashrc export systemd ద్వారా ప్రారంభమైన service కు చేరని సందర్భాన్ని ఇది గుర్తిస్తుంది. మీరు set చేసిన variable ఇక్కడ కనిపించకపోతే, అది ఎప్పుడూ అమలులో లేదు. మీ dotfiles ఏం చెబుతున్నా ఇదే నిజం.

దశ 3: ఇది ఏ hosts కు కనెక్ట్ అవుతుంది?

ముందుగా open sockets ను పరిశీలించండి. Agent ఏ account గా నడుస్తుందో దాని ఆధారంగా వాటిని filter చేయండి.

sudo ss -tnpe state established

-e ప్రతి line కు uid: field ను జోడిస్తుంది. అందువల్ల process names చదవకుండానే agent connections ను browser connections నుంచి వేరు చేయవచ్చు. Remote addresses ను నమోదు చేసి, వాటి వెనుక ఉన్న names ను కనుగొనండి. Names పొందడానికి అత్యంత నమ్మదగిన source TLS (transport layer security) handshake. ప్రతి కొత్త connection, SNI (server name indication) field కలిగిన ClientHello తో ప్రారంభమవుతుంది. Client కోరిన hostname అదే field లో ఉంటుంది.

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 జోడించిన ఇతర endpoints. Name column ఖాళీగా ఉంటే, ఆ client ECH (encrypted client hello) ను ఉపయోగించిందని అర్థం. కాబట్టి hostname network లో కనిపించదు. అప్పుడు destination IP address, reverse lookup లేదా దశ 4లోని proxy ను ఉపయోగించాలి.

DNS (domain name system) view ఉపయోగకరమైన cross-check. Connection పూర్తికాకపోయినా agent lookup చేసిన names ఇందులో కనిపిస్తాయి.

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

ప్రతి query line, A? host.example.net. (39) రూపంలో record type మరియు name తో ముగుస్తుంది. External interface పై కాకుండా any పై capture చేయండి. systemd-resolved ఉన్నప్పుడు application, 127.0.0.53 లోని local stub listener తో మాట్లాడుతుంది. బయటికి మాట్లాడేది ఆ stub మాత్రమే. Agent స్పష్టంగా పనిచేస్తున్నప్పటికీ DNS traffic ఏదీ కనిపించకపోతే, ఆ runtime స్వయంగా DNS over HTTPS చేస్తోంది. అలాంటప్పుడు names పొందడానికి దశ 4 మాత్రమే ఉపయోగపడుతుంది.

Agent నిజమైన పనిని చేస్తున్న సమయంలో capture చేయండి. ఒక session ప్రారంభించండి. దానితో ఒక file చదివించండి. ఒక command అమలు చేయించండి. ఏదైనా దశలో అది fail అయ్యేలా చేయండి. Startup సమయంలో ఒక్కసారి మాత్రమే లేదా exception వచ్చినప్పుడు మాత్రమే ఏర్పడే traffic, idle capture లో ఎప్పుడూ కనిపించదు. Audit లో సౌకర్యవంతమైన కానీ తప్పు నిర్ణయానికి దారితీసే అత్యంత సాధారణ కారణం idle capture.

దశ 4: అభ్యర్థనల్లో ఏముంది?

Hostnameలు ఎవరో తెలియజేస్తాయి. అభ్యర్థనల్లో ఏముందో చూడాలంటే, agent ముందు మీరు నియంత్రించే proxyని ఉంచి, ఆ runtimeకు మాత్రమే దాని certificate authority (CA)పై నమ్మకం ఉంచండి. సాధారణంగా ఉపయోగించే సాధనం mitmproxy. standalone binaries కోసం mitmproxy.orgను, Python package మార్గం కోసం uv tool install mitmproxyను project సిఫార్సు చేసి, దాని గురించి documentation అందిస్తుంది.

mitmdump -w /tmp/agent-flows.mitm

మొదటి runలో CAని ~/.mitmproxy/లో రాస్తుంది. అందులో mitmproxy-ca-cert.pem certificate మాత్రమే ఉంటుంది. మీరు agentను ప్రారంభించే shellలో 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 CLIలు Node programsగా ఉంటాయి. Process ప్రారంభమైనప్పుడు Node NODE_EXTRA_CA_CERTSను చదువుతుంది. అందువల్ల agentను launch చేయడానికి ముందే దాన్ని 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ను print చేస్తుంది. Request mitmdump outputలో కనిపిస్తుంది. నమ్మని CA వల్ల curl: (60) SSL certificate problem: self-signed certificate in certificate chain వస్తుంది. Node agentలో దీనికి సమానమైన లోపం SELF_SIGNED_CERT_IN_CHAIN codeను కలిగి ఉంటుంది. తరువాత saved flowsను console viewerతో చదవండి. అందులో ఒక requestను తెరిచి, దాని headers మరియు bodyని చదవవచ్చు.

mitmproxy -r /tmp/agent-flows.mitm

నాలుగు ఫలితాలను ప్రత్యేకంగా గుర్తించాలి. Requests కనిపిస్తే, వాటిని చదివి నిర్ణయం తీసుకోండి. Certificate errorతో agent ప్రారంభం కావడానికి నిరాకరిస్తే, అది ఆ runtimeలోని trust సమస్య. అది vendor గురించి నిర్ధారణ కాదు. Model API మాత్రమే కనిపిస్తే, ఇతర categories offలో ఉన్నాయని లేదా మీరు trigger చేయని eventపై అవి పనిచేస్తున్నాయని అర్థం. Agent స్పష్టంగా పనిచేస్తున్నప్పటికీ ఏమీ కనిపించకపోతే, client proxy environment variablesను పట్టించుకోవడం లేదని లేదా certificatesను pin చేస్తోందని అర్థం. అలాంటప్పుడు నిజం చెప్పడానికి ఏ application settingనూ నమ్మలేరు. చివరి ఫలితమే అత్యంత ముఖ్యమైనది. అది మిమ్మల్ని దశ 3కి తిరిగి పంపుతుంది. ఎందుకంటే packet capture connectionను చూడకుండా దాన్ని ఒప్పించలేరు.

బలహీనమైనది నుంచి బలమైనదివరకు నియంత్రణలు

Opt-out settings. ఇవి తక్కువ ఖర్చుతో కూడుకున్నవి, కానీ బలహీనమైనవి. ఎందుకంటే ఇవి vendor వాటిని గౌరవించడంపై, అలాగే ఇప్పటికే ఉన్న ఒక category ను కవర్ చేయడంపై ఆధారపడతాయి. Reboot మరియు కొత్త terminal తర్వాత కూడా అవి కొనసాగేందుకు వీలుగా user settings file లేదా మీ shell profile లో వాటిని సెట్ చేయండి. అక్కడే DO_NOT_TRACK=1 ను కూడా జోడించండి. ఇది కొంతమంది agents సహా అనేక command line tools పాటించే convention, దీనికి ఎలాంటి ఖర్చు ఉండదు. తరువాతి update తర్వాత step 3 ను మళ్లీ అమలు చేయండి. ఎందుకంటే coverage మారేది అదే సమయంలో.

Egress restriction. ఇక్కడ మీరు అభ్యర్థించడం ఆపి, అమలు చేయడం ప్రారంభిస్తారు. Agent ను ప్రత్యేక user గా run చేయండి. ఆ 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 ను monitor చేయండి. sudo journalctl -k -g agent-egress-drop తో drops ను చదవండి. మీరు ఊహించని hostname తో drop counter పెరగడం ఈ విధానం లక్ష్యం. ఇక్కడ రెండు ముఖ్యమైన పరిమితులు ఉన్నాయి. meta skuid socket ను కలిగి ఉన్న user తో సరిపోలుతుంది. కాబట్టి ఆ account మరో user గా మారలేనంతకాలం మాత్రమే ఇది పనిచేస్తుంది. Agent కోసం passwordless sudo ఉంటే, ఈ rule కేవలం సూచనగా మిగులుతుంది. అలాగే ఏ server కైనా UDP 53 ను తెరిచి ఉంచడం వల్ల query names లో data ను బయటకు పంపగల channel మిగులుతుంది. మీ threat model కు అవసరమైతే దీన్ని కూడా మూసివేయండి. ఇందుకోసం agent యొక్క resolver ను మీరు నిర్వహించే host కు point చేయండి. Hostname allowlists ను nftables లో కాకుండా proxy లో ఉంచాలి. ఎందుకంటే API endpoints content delivery networks వెనుక ఉంటాయి, వాటి IP addresses మీ నియంత్రణ లేకుండా మారుతుంటాయి. ఈ నియంత్రణకు అయ్యే ఖర్చు breakage మరియు upkeep. Package installs, SSH మీద git, అలాగే agent యొక్క స్వంత update check — వీటన్నింటినీ అనుమతించే వరకు విఫలమవుతాయి. ఆ allowlist ను ఇక మీరు నిర్వహించాలి. Laptop బదులుగా server పై దీన్ని ఏర్పాటు చేస్తుంటే, ఇదే account మరియు firewall layout VPS పై Claude Code ను సురక్షితంగా నడపడానికి ప్రాథమిక ఆధారం.

A disposable machine. మీకు అవసరమైన credentials ఏవీ లేని virtual machine (VM) ను agent కు ఇవ్వండి. Task ముగిసినప్పుడు దాన్ని destroy చేయండి. ఇది agent పంపే సమాచారాన్ని తగ్గించదు. Agent పంపగలిగే సమాచారానికి దాని access ను తగ్గిస్తుంది. సాధారణంగా మీరు నిజంగా శ్రద్ధ వహించేది ఇదే risk. పైన పేర్కొన్న egress rules తో దీన్ని కలిపి ఉపయోగించండి. Unrestricted internet access ఉన్న fresh VM మీ capture లోని ప్రతి host ను ఇప్పటికీ చేరుకోగలదు. ఈ పద్ధతి, అలాగే ప్రతి సారి తిరిగి నిర్మించాల్సిన state, disposable VM లో coding agents ను నడపడం లో వివరించబడ్డాయి. Sizing ప్రశ్నకు VPS పై coding agent ను నడపడం చూడండి.

Self-hosting the model. Inference flow ను తొలగించే ఏకైక నియంత్రణ ఇది. ఎందుకంటే prompt మీ hardware ను ఎప్పటికీ విడిచిపెట్టదు. దీని ఖర్చు నిజమైనదే. Closed model ను self-host చేయలేరు. అందువల్ల open weights ను ఎంచుకోవాలి, కఠినమైన tasks లో capability gap ను అంగీకరించాలి, అలాగే వాటిని serve చేయడానికి అవసరమైన hardware ను సమకూర్చాలి. ఈ trade-off ను మీరు Claude ను self-host చేయగలరా లో వివరించారు. ప్రధాన agents మధ్య capability differences ను Claude Code, Cursor, Codex మరియు Copilot ఎలా భిన్నంగా ఉంటాయి లో వివరించారు.

ఈ నాలుగు నియంత్రణల్లో ఏదీ agent disk పై చదవగలిగే సమాచారాన్ని మార్చదు. Inference traffic అది చదివిన దేనినైనా తీసుకెళ్తుంది. .env file working directory లో ఉంటే, agent variable name కోసం grep చేసిన క్షణంలో అది model కు పంపబడుతుంది. ఆ సమాచారాన్ని agent చేరుకోలేని విధంగా ఉంచడం వేరే పని. అది AI agent యొక్క context లోకి secrets చేరకుండా ఉంచడం లో వివరించబడింది.

ప్రతి update తర్వాత పరిశీలించాల్సినవి

1. Vendor అందించే settings మరియు data usage పేజీలను మీరు చివరిసారి నమోదు చేసిన వివరాలతో diff చేసి, కొత్త switches మరియు పేరుతో పేర్కొన్న services కోసం చూడండి.
2. నడుస్తున్న process కు మీ opt-outs ఇప్పటికీ వర్తిస్తున్నాయో నిర్ధారించడానికి /proc/<pid>/environ నుంచి process environment ను మళ్లీ చదవండి.
3. Project settings files ను మళ్లీ print చేయండి, ఎందుకంటే git pull ద్వారా సహోద్యోగి మార్చిన config file లోడ్ కావచ్చు.
4. వాస్తవ పనిలో ఒక పూర్తి session కోసం SNI capture ను అమలు చేసి, hostname జాబితాను చివరిసారి పొందిన జాబితాతో పోల్చండి.
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 కు pointing చేయడం ద్వారా receiver ను మార్చవచ్చు. Agent చదవడానికి అనుమతించిన పరిధిని పరిమితం చేయడం ద్వారా అది పంపే డేటాను తగ్గించవచ్చు. Analytics మరియు error reporting ను ఆపడం వల్ల ఈ data flow పై ఎలాంటి ప్రభావం ఉండదు.

నా coding agent ఏ hosts కు connect అవుతుందో ఎలా చూడాలి?

Agent ను ప్రత్యేక Linux user గా run చేయండి. తరువాత దాన్ని ఉపయోగిస్తున్నప్పుడు ప్రతి కొత్త 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 కు ఒక line కనిపిస్తుంది. అందులో destination address మరియు అభ్యర్థించిన hostname ఉంటాయి. sudo tcpdump -ni any 'udp port 53' తో names ను cross-check చేయండి. Capture ను any పై చేయాలి, ఎందుకంటే 127.0.0.53 లోని local resolver stub ముందుగా query ను handle చేస్తుంది. Agent వాస్తవ పనిని చేస్తున్నప్పుడు capture చేయండి. Startup pings మరియు crash reports idle capture లో ఎప్పుడూ కనిపించకపోవచ్చు.

Agent పనిచేస్తున్నప్పుడు నా proxy traffic చూపించడం లేదు. ఏమి తప్పు జరిగింది?

Client HTTP_PROXY మరియు HTTPS_PROXY ను పట్టించుకోకపోవచ్చు. లేదా అది certificates ను pin చేసి మీ CA ను తిరస్కరిస్తుండవచ్చు. ముందుగా curl తో path ను test చేయండి. curl proxy ద్వారా internet కు చేరి, agent flow list లో కనిపించకపోతే, agent proxy environment variables ను ఉపయోగించడం లేదు. కొన్ని runtimes కు CA ను నిర్దిష్ట విధానంలో అందించాలి. ముఖ్యంగా Node, NODE_EXTRA_CA_CERTS ను process start సమయంలో మాత్రమే చదువుతుంది. అందువల్ల agent launch చేసిన తరువాత దాన్ని export చేయడం వల్ల ప్రయోజనం ఉండదు. Proxy traffic ను చూడలేకపోతే packet capture కు మారండి. ఏ application setting కూడా packet capture ను bypass చేయలేదు.

Telemetry ను ఆపితే నా code training కోసం ఉపయోగించబడటం ఆగుతుందా?

లేదు. Analytics మరియు crash reporting, inference కు భిన్నమైన data flow. వాటిని disable చేస్తే usage counters మరియు stack traces తొలగుతాయి. కానీ ప్రతి prompt మునుపటిలాగే model కు వెళ్తుంది. ఆ prompts నిల్వ చేయబడతాయా, భవిష్యత్ model training కు ఉపయోగిస్తారా అనే విషయం మీ plan నిబంధనలపై ఆధారపడి ఉంటుంది. Consumer plans మరియు commercial plans సాధారణంగా వేర్వేరు నిబంధనలు కలిగి ఉంటాయి. ఇది capture చేయాల్సిన packet కాదు; చదవాల్సిన contract. అందువల్ల మీ plan కు సంబంధించిన data usage page ను పరిశీలించండి. అవసరమైతే మొదటి session కు ముందే commercial లేదా zero-retention agreement ఏర్పాటు చేయండి.