Coding agent telemetry: کون سا data بھیجا جاتا ہے؟

Coding agent کی telemetry دراصل کیا cover کرتی ہے

Coding agent کی telemetry دراصل ایک ہی لفظ کے تحت data sharing کے چار الگ flows پر مشتمل ہوتی ہے، اور ہر flow کا اپنا control ہوتا ہے۔ Model inference آپ کے prompts اور code کو اس فریق تک پہنچاتا ہے جو model serve کرتا ہے، اور کوئی setting اسے بند نہیں کرتی۔ Product analytics اور crash reports vendor کو بھیجے جاتے ہیں، اور اکثر اس logging company کو بھی جو vendor کو خدمات فراہم کرتی ہے۔ Training کے لیے retention کا فیصلہ network کا نہیں بلکہ contract کا معاملہ ہے۔ چوتھا flow وہ ہے جسے لوگ نظر انداز کر دیتے ہیں: آپ جو بھی integration شامل کرتے ہیں، وہ ایسے host سے connection کھول سکتا ہے جسے آپ نے خود منتخب نہیں کیا۔

موجودہ vendor defaults کی فہرست اس موضوع کا سب سے تیزی سے بدلنے والا حصہ ہے۔ کوئی release default تبدیل کر سکتی ہے، اور کوئی نیا feature ایسی destination شامل کر سکتا ہے جسے کوئی موجودہ switch control نہ کرتا ہو۔ اس لیے پائیدار مہارت ایسا audit کرنا ہے جسے آپ کسی بھی agent پر دوبارہ انجام دے سکیں: vendor کی documentation پڑھیں، check کریں کہ اس machine پر واقعی کون سی config apply ہوئی، machine خود process کو monitor کریں، پھر وہ controls منتخب کریں جن کی قیمت ادا کرنے پر آپ آمادہ ہیں۔ نیچے دیا گیا ہر command آپ اپنی machine پر اپنے traffic کے خلاف چلاتے ہیں۔

چار اقسام، اور انہیں مختلف controls کی ضرورت کیوں ہوتی ہے

Model inference traffic ناگزیر ہے۔ Agent آپ کا prompt، پڑھی گئی files، چلائے گئے commands کا output، اور اپنا generated text ایک model endpoint کو بھیجتا ہے۔ یہی product کا معمول کا کام ہے۔ اصل فیصلہ صرف یہ ہے کہ اسے کون وصول کرتا ہے: کسی دوسرے فریق کی چلائی ہوئی API، یا آپ کا اپنا چلایا ہوا model۔ کمپنی کا cloud account (Bedrock، Vertex، Foundry) وصول کنندہ کو تبدیل کرتا ہے، flow کو ختم نہیں کرتا۔ اس پوسٹ کے باقی حصوں میں کوئی چیز inference traffic کم نہیں کرتی، اس لیے اسے ذہن میں باقی تین اقسام سے الگ رکھیں۔

Product analytics اور crash reporting مختلف hosts کو جانے والا الگ flow ہے۔ Usage counters، latency numbers، feature-flag lookups اور stack traces عموماً ایسے hostnames کو بھیجے جاتے ہیں جن کا model API سے کوئی تعلق نہیں ہوتا، اور اکثر یہ کسی third-party error tracker کو بھیجے جاتے ہیں۔ Vendors عموماً انہیں "metrics" اور "error reports" کے طور پر document کرتے ہیں اور عموماً ہر category کے لیے ایک environment variable فراہم کرتے ہیں۔ Volume بہت کم ہوتا ہے، اس لیے byte counts اسے کبھی تلاش نہیں کر سکتے۔ آپ bandwidth نہیں بلکہ hostnames تلاش کر رہے ہیں۔

Retention اور training packets نہیں بلکہ policy ہیں۔ Vendor آپ کے prompts محفوظ رکھتا ہے یا نہیں، کتنی مدت تک رکھتا ہے، اور ان پر future model کو train کرتا ہے یا نہیں، یہ سب آپ کے 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، یا کوئی safety check جو fetch کرنے سے پہلے URL resolve کرتا ہے: ہر ایک ایسی host کو request بھیجتا ہے جو model endpoint نہیں ہوتی۔ حیرت انگیز صورتیں عموماً یہیں پیدا ہوتی ہیں، کیونکہ harness آپ کے خیال میں local کام کو اپنی service کے ذریعے route کر سکتا ہے، اور کوئی release آپ کی config کی ایک بھی line بدلے بغیر یہ عمل شروع کر سکتی ہے۔ ہر شامل کیے گئے tool کو ایک نئی destination سمجھیں، جب تک آپ نے اسے network traffic میں observe نہ کر لیا ہو۔

مرحلہ 1: vendor کیا دستاویز کرتا ہے؟

اپنے agent کے لیے settings reference اور data usage صفحہ کھولیں، اور انہیں الفاظ کی فہرست ساتھ رکھ کر پڑھیں: metrics، analytics، error reporting، crash، feedback، survey، update check، safety check، marketplace۔ عموماً ان میں سے ہر لفظ کے لیے الگ switch ہوتا ہے۔ متغیر کے درست نام لکھ لیں، کیونکہ step 2 ان ناموں کے لیے grep کرتا ہے۔

ایک لفظ آپ کو گمراہ کر سکتا ہے۔ کئی agents میں docs میں "telemetry" سے مراد OpenTelemetry export ہوتا ہے، جسے آپ اپنے چلائے ہوئے collector کو metrics بھیجنے کے لیے configure کرتے ہیں۔ یہ اس کے برعکس ہے کہ data vendor کو بھیجا جائے۔ Claude Code ان میں سے ایک ہے: CLAUDE_CODE_ENABLE_TELEMETRY=1 set کرنے سے OTEL_EXPORTER_OTLP_ENDPOINT میں بتائے گئے endpoint کو export شروع ہو جاتا ہے، اور اس کا vendor کی اپنی analytics سے کوئی تعلق نہیں ہوتا، جن کے لیے الگ opt-out موجود ہے۔ کچھ set کرنے سے پہلے معلوم کریں کہ data کس سمت میں جا رہا ہے۔

ایک master switch کی توقع رکھیں، مگر یہ بھی توقع رکھیں کہ اس میں کچھ استثنا ہوں گے۔ August 2026 تک، Claude Code کا CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC metrics، error reports، feedback command اور session surveys کو ایک ساتھ بند کر دیتا ہے۔ اسی documentation کے مطابق یہ WebFetch domain safety check پر لاگو نہیں ہوتا۔ یہ check آپ جس hostname کو fetch کرنے والے ہوتے ہیں اسے vendor API کو بھیجتا ہے اور اس کی اپنی الگ setting ہے۔ یہ صرف ایک product کے بارے میں شکایت نہیں ہے۔ مسئلے کی عمومی صورت یہی ہے: master switch صرف ان categories کا احاطہ کرتا ہے جو اسے لکھے جانے کے وقت موجود تھیں۔

یہ بھی توقع رکھیں کہ opt-out کی کچھ قیمت ہو سکتی ہے۔ انہی docs میں بتایا گیا ہے کہ telemetry غیر فعال کرنے سے feature-flag evaluation بھی غیر فعال ہو جاتی ہے، جس پر کچھ features منحصر ہوتے ہیں۔ اس لیے privacy کے لیے بدلا گیا switch آپ کے زیرِ استعمال feature کو بند کر سکتا ہے، اور کوئی error message دونوں باتوں کے درمیان تعلق نہیں بتائے گا۔ صرف flag کا نام نہ پڑھیں؛ اس کے ساتھ والا جملہ بھی پڑھیں۔

مرحلہ 2: کون سی configuration واقعی لاگو ہوئی؟

آپ نے جو setting لکھی ہے، ضروری نہیں کہ وہ لاگو بھی ہوئی ہو۔ Agents متعدد files سے configuration merge کرتے ہیں، اور ان میں سے ایک file اس repository کے اندر ہو سکتی ہے جسے آپ نے ابھی کسی دوسرے شخص سے clone کیا ہے۔ ابتدا اپنے shell کے environment سے کریں۔

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

پھر tool کے ذریعے پڑھی جانے والی تمام settings files کو اسی ترتیب سے print کریں جو documentation میں دی گئی ہے۔ Claude Code کے لیے، August 2026 تک، یہ 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 ہوتی ہے، اور یہ وہ setting دوبارہ enable کر سکتی ہے جسے آپ کی user file نے disable کیا تھا۔ اگر agent کے پاس loaded sources کی فہرست دکھانے والی status command ہو تو یہی سب سے تیز اور قابلِ اعتماد تصدیق ہے: Claude Code loaded settings sources کو /status میں print کرتا ہے۔

سب سے مضبوط جانچ کسی file کے بجائے چلنے والے process کو پڑھتی ہے۔ پہلے agent کے لیے اپنا Linux user account بنائیں۔ اس سے اس post کی ہر command مختصر ہو جائے گی۔ پھر process کے start ہونے کے وقت موجود 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 ان variables کو دکھاتا ہے جو process کے exec وقت موجود تھیں۔ اس سے وہ صورتِ حال سامنے آ جاتی ہے جس میں آپ کا .bashrc export، systemd کے ذریعے شروع کی گئی service تک نہیں پہنچا۔ اگر آپ کی set کی ہوئی variable یہاں موجود نہیں ہے تو وہ کبھی لاگو نہیں ہوئی، چاہے آپ کی dotfiles کچھ بھی کہتی ہوں۔

مرحلہ 3: یہ کن hosts سے connect ہوتا ہے؟

open sockets سے آغاز کریں اور انہیں اس account کے مطابق filter کریں جس کے تحت agent چل رہا ہے۔

sudo ss -tnpe state established

-e ہر line میں uid: field شامل کرتا ہے۔ اس سے process names پڑھے بغیر agent کے connections کو browser کے connections سے الگ کیا جا سکتا ہے۔ remote addresses نوٹ کریں، پھر ان کے پیچھے موجود names معلوم کریں۔ names حاصل کرنے کا سب سے صاف ذریعہ TLS (transport layer security) handshake ہے، کیونکہ ہر نیا connection ایک ClientHello سے شروع ہوتا ہے۔ اس میں SNI (server name indication) field ہوتی ہے، جو وہ hostname ہے جس کے لیے 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

ہر نئے connection کے لیے ایک line ملتی ہے۔ یہی وہ inventory ہے جس کی آپ کو ضرورت ہے: model API، update server، analytics host، error tracker، اور integration کی جانب سے شامل کیا گیا کوئی بھی endpoint۔ اگر name column خالی ہو تو اس کا مطلب ہے کہ client نے ECH (encrypted client hello) استعمال کیا۔ اس صورت میں hostname network پر نظر نہیں آتا، لہذا destination IP address، reverse lookup، یا step 4 میں موجود proxy سے مدد لیں۔

DNS (domain name system) view مفید cross-check فراہم کرتا ہے، کیونکہ یہ ان names کو بھی دکھاتا ہے جنہیں agent نے lookup کیا، خواہ وہ connections مکمل نہ ہوئے ہوں۔

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 ہی باہر سے بات کرتا ہے۔ اگر agent کے واضح طور پر کام کرنے کے دوران DNS traffic بالکل نظر نہ آئے تو runtime خود DNS over HTTPS کر رہا ہے۔ ایسی صورت میں names صرف step 4 سے ملیں گے۔

agent کے حقیقی کام کے دوران capture کریں۔ ایک session شروع کریں، اسے file پڑھنے دیں، اسے command چلانے دیں، اور کسی کارروائی میں failure پیدا ہونے دیں۔ startup پر صرف ایک بار یا exception آنے پر فعال ہونے والا traffic idle capture میں کبھی نظر نہیں آتا۔ idle capture ہی وہ عام ترین طریقہ ہے جس سے audit ایک بظاہر مطمئن مگر غلط نتیجے تک پہنچتا ہے۔

مرحلہ 4: درخواستوں کے اندر کیا ہے؟

Hostnames یہ بتاتے ہیں کہ درخواستیں کس سے متعلق ہیں۔ یہ دیکھنے کے لیے کہ ان کے اندر کیا ہے، agent کے سامنے ایسا proxy رکھیں جسے آپ کنٹرول کرتے ہوں، اور صرف اسی runtime کے لیے اس کی certificate authority (CA) پر اعتماد کریں۔ معمول کا tool mitmproxy ہے۔ project کی سفارش ہے کہ mitmproxy.org سے standalone binaries استعمال کی جائیں، اور Python package کے راستے کی دستاویز uv tool install mitmproxy میں موجود ہے۔

mitmdump -w /tmp/agent-flows.mitm

پہلی بار چلانے پر CA، ~/.mitmproxy/ میں لکھی جاتی ہے، جہاں mitmproxy-ca-cert.pem خود certificate ہے۔ جس shell سے آپ agent شروع کریں گے، اسی میں client کو proxy اور اس 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"

بہت سے agent CLIs، Node programs ہوتے ہیں، اور Node process شروع ہوتے وقت 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 میں اس کے مساوی error code SELF_SIGNED_CERT_IN_CHAIN کے ساتھ آتا ہے۔ بعد میں محفوظ شدہ flows کو console viewer سے پڑھیں۔ وہاں آپ ایک درخواست کھول کر اس کے headers اور body پڑھ سکتے ہیں۔

mitmproxy -r /tmp/agent-flows.mitm

چار نتائج اہم ہیں۔ آپ کو درخواستیں نظر آتی ہیں، ایسی صورت میں انہیں پڑھیں اور فیصلہ کریں۔ Agent certificate error کے ساتھ شروع ہونے سے انکار کرتا ہے، جو اس runtime میں trust کا مسئلہ ہے، vendor کے بارے میں کوئی finding نہیں۔ آپ کو صرف model API نظر آتی ہے، جس کا مطلب ہے کہ دوسری categories فعال نہیں ہیں، یا وہ ایسے event پر چلتی ہیں جسے آپ نے trigger نہیں کیا۔ یا agent بظاہر درست کام کرتا ہے مگر آپ کو کچھ بھی نظر نہیں آتا۔ اس کا مطلب ہے کہ client proxy environment variables نظرانداز کرتا ہے یا اپنے certificates pin کرتا ہے، اور application setting پر اس بات کی تصدیق کے لیے اعتماد نہیں کیا جا سکتا۔ آخری صورت سب سے اہم ہے۔ یہ آپ کو دوبارہ مرحلہ 3 پر لے جاتی ہے، کیونکہ packet capture کو یہ سمجھا کر connection نہ دیکھنے پر مجبور نہیں کیا جا سکتا کہ اسے نظر نہیں آنا چاہیے۔

کنٹرولز، کمزور ترین سے مضبوط ترین تک

Opt-out ترتیبات۔ یہ سب سے سستا اور کمزور ترین طریقہ ہے، کیونکہ اس کا انحصار vendor کے ان ترتیبات کی پابندی کرنے اور پہلے سے موجود category کو cover کرنے پر ہوتا ہے۔ انہیں ایسی جگہ set کریں جہاں 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 سے apply کریں، counter کو sudo nft list table inet agentegress سے monitor کریں، اور drops کو sudo journalctl -k -g agent-egress-drop سے پڑھیں۔ اگر کسی غیر متوقع hostname کے ساتھ drop counter بڑھ رہا ہو تو یہی اس exercise کا مقصد ہے۔ دو اہم حدود ہیں۔ meta skuid اس user سے match کرتا ہے جو socket کا مالک ہو، اس لیے یہ صرف اس وقت مؤثر رہتا ہے جب وہ account کسی دوسرے user میں تبدیل نہ ہو سکے۔ agent کے لیے passwordless sudo اس rule کو محض ایک suggestion بنا دیتا ہے۔ اسی طرح UDP 53 کو کسی بھی server کے لیے کھلا چھوڑنے سے ایسا channel باقی رہتا ہے جس کے ذریعے query names میں data باہر بھیجا جا سکتا ہے۔ اگر آپ کے threat model میں یہ خطرہ شامل ہو تو اسے بھی بند کریں، اور agent کے resolver کو اپنے زیر انتظام host کی طرف point کریں۔ Hostname allowlists کو nftables کے بجائے proxy میں رکھنا چاہیے، کیونکہ API endpoints عموماً content delivery networks کے پیچھے ہوتے ہیں اور ان کے IP addresses آپ کی توقع کے بغیر بدلتے رہتے ہیں۔ اس control کی قیمت breakage اور upkeep ہے: package installs، SSH پر git، اور agent کی اپنی update check سب اس وقت تک fail ہوں گے جب تک آپ انہیں allow نہ کریں۔ اب اس فہرست کی maintenance آپ کی ذمہ داری ہے۔ اگر آپ اسے laptop کے بجائے server پر set up کر رہے ہیں تو یہی account اور firewall layout VPS پر Claude Code محفوظ طریقے سے چلانے کی بنیاد ہے۔

ایک disposable machine۔ agent کو ایک virtual machine (VM) دیں جس میں آپ کے لیے اہم credentials نہ ہوں اور task کے اختتام پر اسے destroy کر دیا جائے۔ اس سے agent کے بھیجے جانے والے data میں کمی نہیں آتی، بلکہ اس data تک رسائی کم ہوتی ہے جسے agent بھیج سکتا ہے۔ عموماً اصل خطرہ یہی ہوتا ہے۔ اسے اوپر بیان کردہ egress rules کے ساتھ استعمال کریں، کیونکہ unrestricted internet access والی نئی VM بھی آپ کے capture میں موجود ہر host تک پہنچ سکتی ہے۔ طریقہ اور وہ state جسے ہر بار دوبارہ build کرنا پڑتا ہے، disposable VM میں coding agents چلانے میں بیان کیے گئے ہیں، جبکہ sizing کا سوال VPS پر coding agent چلانے میں زیرِ بحث ہے۔

Model کو self-host کرنا۔ یہ واحد control ہے جو 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 میں فرق میں بیان کیے گئے ہیں۔

ان چاروں controls میں سے کوئی بھی یہ نہیں بدلتا کہ agent کو disk پر کیا پڑھنے کی اجازت ہے، اور inference traffic میں وہ سب کچھ شامل ہوتا ہے جو agent پڑھتا ہے۔ اگر .env file working directory میں موجود ہو تو agent کے variable name کے لیے grep کرتے ہی وہ model کو بھیج دی جاتی ہے۔ اس material کو agent کی رسائی سے باہر رکھنا ایک الگ کام ہے، جس کی وضاحت 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 شامل کر سکتا ہے جسے کسی colleague نے تبدیل کیا ہو۔
4. حقیقی کام کے ایک مکمل session کے لیے SNI capture چلائیں اور hostname list کا اپنی گزشتہ list سے موازنہ کریں۔
5. firewall drop counter چیک کریں، کیونکہ نیا destination عموماً کسی اور جگہ نظر آنے سے پہلے وہیں ظاہر ہو جاتا ہے۔

اس میں تقریباً دس منٹ لگتے ہیں، اور یہ عمل کا واحد حصہ ہے جو پرانا نہیں ہوتا۔ August 2026 میں verify کیا گیا 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 کو کیا پڑھنے کی اجازت ہے۔ Analytics اور error reporting بند کرنے سے اس flow پر کوئی اثر نہیں پڑتا۔

میں کیسے دیکھوں کہ میرا coding agent کن hosts سے connect ہوتا ہے؟

Agent کو اپنے الگ Linux user کے طور پر چلائیں، پھر اسے استعمال کرتے ہوئے ہر نئی 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 اور requested hostname شامل ہوتے ہیں۔ Names کی تصدیق sudo tcpdump -ni any 'udp port 53' کے ساتھ کریں، اور capture any پر کریں کیونکہ local resolver stub پہلے 127.0.0.53 پر query handle کرتا ہے۔ Capture اس وقت کریں جب agent حقیقی کام کر رہا ہو، کیونکہ 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 اسے bypass نہیں کر سکتی۔

کیا telemetry بند کرنے سے میرا code training میں استعمال ہونا رک جاتا ہے؟

نہیں۔ Analytics اور crash reporting، inference سے مختلف flow ہیں۔ انہیں بند کرنے سے usage counters اور stack traces ہٹ جاتے ہیں، لیکن ہر prompt پہلے کی طرح model کو بھیجا جاتا رہتا ہے۔ ان prompts کو retain کیا جائے گا یا نہیں، اور آیا انہیں future model کی training کے لیے استعمال کیا جائے گا، یہ آپ کے plan کی terms طے کرتی ہیں؛ consumer plans اور commercial plans میں عموماً فرق ہوتا ہے۔ یہ packet capture کرنے کے بجائے پڑھنے والا contract ہے، اس لیے اپنے plan کے لیے data usage page دیکھیں اور جہاں ضروری ہو، پہلی session سے پہلے commercial یا zero-retention agreement کا انتظام کریں۔