Coding agent telemetry-তে কী কী তথ্য পাঠানো হয়

Coding agent telemetry আসলে কী কী তথ্য কাভার করে

Coding agent telemetry হলো একই শব্দের অধীনে থাকা চারটি পৃথক data flow, এবং প্রতিটি flow-এর নিজস্ব control আছে। Model inference-এর সময় আপনার prompt ও code সেই পক্ষের কাছে যায়, যে model পরিবেশন করে; কোনো setting এটি বন্ধ করতে পারে না। Product analytics ও crash report vendor-এর কাছে যায়, এবং প্রায়ই vendor যে logging company-কে অর্থ দেয়, তাদের কাছেও যায়। Training-এর জন্য data retention নেটওয়ার্ক-সংক্রান্ত বিষয় নয়; এটি চুক্তি-সংক্রান্ত বিষয়। চতুর্থ flow-টিই মানুষ প্রায়ই উপেক্ষা করে: আপনি যে প্রতিটি integration যোগ করেন, সেটি এমন একটি host-এর সঙ্গে connection খুলতে পারে, যেটি আপনি কখনো বাছাই করেননি।

বর্তমান vendor default-এর তালিকাই এই বিষয়ের সবচেয়ে দ্রুত পুরোনো হয়ে যাওয়া অংশ। একটি release কোনো default পরিবর্তন করতে পারে, এবং নতুন কোনো feature এমন destination যোগ করতে পারে, যেটি কোনো বিদ্যমান switch নিয়ন্ত্রণ করে না। তাই দীর্ঘমেয়াদে কার্যকর দক্ষতা হলো এমন একটি audit পদ্ধতি, যা যেকোনো agent-এর ক্ষেত্রে পুনরাবৃত্তি করা যায়: vendor কী document করেছে তা পড়ুন, এই machine-এ বাস্তবে কোন config প্রয়োগ হয়েছে তা যাচাই করুন, machine থেকেই process monitor করুন, তারপর কোন control ব্যবহারের খরচ আপনি গ্রহণ করতে প্রস্তুত তা নির্ধারণ করুন। নিচের প্রতিটি command আপনি নিজের machine-এ, নিজের traffic-এর ওপর চালাবেন।

চারটি শ্রেণি এবং কেন প্রতিটির জন্য ভিন্ন নিয়ন্ত্রণ প্রয়োজন

মডেল inference traffic এড়ানো যায় না। Agent আপনার prompt, এটি পড়া file-গুলো, চালানো command-গুলোর output এবং নিজস্ব generated text একটি model endpoint-এ পাঠায়। এটাই product-এর স্বাভাবিক কাজ। একমাত্র প্রকৃত সিদ্ধান্ত হলো এটি কে গ্রহণ করবে: অন্য কারও পরিচালিত API, নাকি আপনি নিজে পরিচালনা করা model। কোনো company cloud account (Bedrock, Vertex, Foundry) গ্রহণকারীকে পরিবর্তন করে, flow-টি বন্ধ করে না। এই post-এর বাকি কোনো অংশ inference traffic কমায় না। তাই এটিকে অন্য তিনটি বিষয় থেকে আলাদা করে বিবেচনা করুন।

Product analytics এবং crash reporting ভিন্ন host-এ যাওয়া আলাদা flow। Usage counter, latency number, feature-flag lookup এবং stack trace সাধারণত এমন hostname-এ যায়, যেগুলোর model API-এর সঙ্গে কোনো সম্পর্ক নেই। এগুলো প্রায়ই third-party error tracker-এও পাঠানো হয়। Vendor-রা সাধারণত এগুলোকে "metrics" এবং "error reports" হিসেবে নথিভুক্ত করে এবং প্রতিটি category-এর জন্য সাধারণত একটি করে environment variable দেয়। Volume খুব কম, তাই byte count দিয়ে এগুলো কখনো শনাক্ত করা যাবে না। আপনার অনুসন্ধানের লক্ষ্য bandwidth নয়, hostname।

Retention এবং training packet নয়, policy-এর বিষয়। Vendor আপনার prompt সংরক্ষণ করবে কি না, করলে কত দিন রাখবে, এবং সেগুলো ব্যবহার করে ভবিষ্যতের কোনো model train করবে কি না—এসব আপনার plan-এর সঙ্গে যুক্ত terms-এ লেখা থাকে। Consumer plan এবং commercial plan-এ সাধারণত পার্থক্য থাকে। Zero-retention arrangement সাধারণত আলাদা agreement হিসেবে করা হয়। tcpdump ব্যবহার করে এর কোনোটি যাচাই করতে পারবেন না, কারণ উভয় ক্ষেত্রেই packet একই রকম দেখায়। Terms পড়ুন। বিষয়টি আপনার employer-এর জন্য গুরুত্বপূর্ণ হলে লিখিত নিশ্চয়তা নিন।

Integration নিঃশব্দে অতিরিক্ত একটি hop যোগ করে। MCP (model context protocol) server, plugin marketplace, auto-update check, web search tool, অথবা fetch করার আগে URL resolve করা safety check—প্রতিটিই model endpoint নয়, এমন কোনো host-এ পাঠানো request। অপ্রত্যাশিত বিষয়গুলো এখানেই থাকে। কারণ harness আপনার স্থানীয় বলে ধরে নেওয়া কাজ নিজস্ব কোনো service-এর মাধ্যমে route করতে পারে। কোনো release আপনার config-এর একটি line-ও পরিবর্তন না করেও এমন আচরণ শুরু করতে পারে। আপনি wire-এ এর traffic পর্যবেক্ষণ না করা পর্যন্ত প্রতিটি নতুন tool-কে একটি নতুন destination হিসেবে বিবেচনা করুন।

ধাপ 1: vendor কী নথিভুক্ত করেছে?

আপনার agent-এর settings reference এবং data usage page খুলুন। হাতে একটি শব্দের তালিকা রাখুন এবং সেগুলো পড়ুন: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace। সাধারণত প্রতিটি শব্দের জন্য আলাদা switch থাকে। সঠিক variable name লিখে রাখুন, কারণ ধাপ 2-এ সেগুলো দিয়ে grep করা হবে।

একটি শব্দ আপনাকে বিভ্রান্ত করতে পারে। বেশ কয়েকটি agent-এর documentation-এ "telemetry" বলতে OpenTelemetry export বোঝায়। এটি এমন একটি export, যা আপনি আপনার পরিচালিত collector-এ metrics পাঠানোর জন্য configure করেন। অর্থাৎ data vendor-এর কাছে যাওয়ার বিপরীত ব্যবস্থা। Claude Code এর একটি উদাহরণ: CLAUDE_CODE_ENABLE_TELEMETRY=1 সেট করলে OTEL_EXPORTER_OTLP_ENDPOINT-এ নির্দিষ্ট endpoint-এ export শুরু হয়। এটি vendor-এর নিজস্ব analytics-এর সঙ্গে সম্পর্কিত নয়; সেগুলোর opt-out setting আলাদা। কোনো setting পরিবর্তনের আগে 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 লেখার সময় বিদ্যমান category-গুলোকে কভার করে।

Opt-out করার বিনিময়ে কিছু সুবিধা হারাতে পারেন। একই documentation-এ বলা হয়েছে, telemetry বন্ধ করলে কিছু feature-এর নির্ভরশীল feature-flag evaluation-ও বন্ধ হয়ে যায়। ফলে privacy রক্ষার জন্য কোনো switch পরিবর্তন করলে আপনি ব্যবহার করা একটি feature বন্ধ হয়ে যেতে পারে, অথচ এই দুই ঘটনার মধ্যে সম্পর্ক দেখানো কোনো error message নাও থাকতে পারে। শুধু flag-এর name নয়, flag-এর পাশের বাক্যটিও পড়ুন।

ধাপ 2: আসলে কোন configuration প্রয়োগ হয়েছে?

আপনি যে setting লিখেছেন, সেটি প্রয়োগ হয়েছে—এমন নয়। Agent একাধিক file থেকে configuration একত্র করে। এর মধ্যে একটি file আপনি অন্য কারও repository clone করার সময় সেটির ভিতরে এসেছে। প্রথমে নিজের 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 file এবং 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 আবার চালু করতে পারে। Agent-এর status command যদি লোড করা source-গুলোর তালিকা দেখায়, সেটিই দ্রুততম নির্ভরযোগ্য যাচাই। Claude Code লোড করা settings source-গুলো /status-এ print করে।

সবচেয়ে নির্ভরযোগ্য পরীক্ষা কোনো file না পড়ে চলমান 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 দেখায় exec সময় process-এর কাছে কোন variables ছিল। তাই আপনার .bashrc export systemd দিয়ে শুরু করা service-এ পৌঁছায়নি—এই ঘটনাও এটি শনাক্ত করে। এখানে আপনার সেট করা কোনো variable না থাকলে সেটি কখনো কার্যকর ছিল না, আপনার dotfiles যা-ই বলুক।

ধাপ 3: এটি কোন কোন host-এ সংযোগ করে?

এজেন্ট যে account-এ চলে, সেই account অনুযায়ী filter করে open socket দিয়ে শুরু করুন।

sudo ss -tnpe state established

-e প্রতিটি line-এ একটি uid: field যোগ করে। ফলে process name না পড়েই এজেন্টের connection-গুলো browser-এর connection থেকে আলাদা করতে পারবেন। Remote address-গুলো নোট করুন, তারপর সেগুলোর পেছনের name বের করুন। Name পাওয়ার সবচেয়ে নির্ভরযোগ্য উৎস হলো TLS (transport layer security) handshake। কারণ প্রতিটি নতুন connection একটি ClientHello দিয়ে শুরু হয়। এতে একটি SNI (server name indication) field থাকে। এই 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-এর জন্য একটি করে line পাবেন। আপনার প্রয়োজনীয় inventory-তে ঠিক এগুলোই থাকবে: model API, update server, analytics host, error tracker এবং কোনো integration যোগ করা অন্য যেকোনো host। Name column খালি থাকলে বুঝবেন client ECH (encrypted client hello) ব্যবহার করেছে। তাই network-এ hostname দেখা যাচ্ছে না। সে ক্ষেত্রে destination IP address, reverse lookup অথবা ধাপ 4-এর proxy ব্যবহার করুন।

DNS (domain name system) view দিয়ে ফলাফল cross-check করা যায়। কারণ connection সম্পূর্ণ না হলেও agent যে name-গুলো lookup করেছে, এটি সেগুলো দেখায়।

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

প্রতিটি query line record type এবং name দিয়ে শেষ হয়। Format হলো A? host.example.net. (39)। External interface-এর বদলে any-এ capture করুন। কারণ systemd-resolved থাকলে application একটি local stub listener-এর সঙ্গে 127.0.0.53-এ কথা বলে, এবং শুধু stub-ই বাইরের network-এর সঙ্গে কথা বলে। Agent স্পষ্টভাবে কাজ করা সত্ত্বেও যদি কোনো DNS traffic না দেখেন, তাহলে সেই runtime নিজেই DNS over HTTPS করছে। সে ক্ষেত্রে শুধু ধাপ 4-এই name পাওয়া যাবে।

Agent বাস্তব কাজ করার সময় capture করুন। একটি session শুরু করুন, তাকে কোনো file পড়ান, কোনো command চালাতে দিন এবং কোনো কাজে ব্যর্থ হতে দিন। Startup-এর সময় একবার হওয়া traffic বা শুধু exception ছোড়ার সময় হওয়া traffic idle capture-এ কখনো দেখা যায় না। কোনো audit ভুল হলেও স্বস্তিদায়ক সিদ্ধান্তে পৌঁছানোর সবচেয়ে সাধারণ কারণ হলো idle capture।

ধাপ 4: অনুরোধগুলোর ভেতরে কী আছে?

Hostname আপনাকে জানায় অনুরোধটি কার জন্য। অনুরোধে কী আছে তা দেখতে agent-এর সামনে আপনার নিয়ন্ত্রণাধীন একটি proxy বসান এবং শুধু ওই runtime-এর জন্য তার certificate authority (CA)-কে trust করুন। সাধারণত এই কাজের জন্য mitmproxy ব্যবহার করা হয়। প্রকল্পটি mitmproxy.org থেকে standalone binary ব্যবহারের পরামর্শ দেয় এবং uv tool install mitmproxy-কে Python package ব্যবহারের পদ্ধতি হিসেবে নথিবদ্ধ করেছে।

mitmdump -w /tmp/agent-flows.mitm

প্রথমবার চালালে ~/.mitmproxy/-এ একটি CA লেখা হয়। সেখানে 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 CLI Node program, এবং process শুরু হওয়ার সময় Node NODE_EXTRA_CA_CERTS পড়ে। তাই agent চালু করার আগে এটি export করুন; পরে অন্য terminal-এ export করবেন না। Python client 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 দেখাবে এবং request mitmdump-এর output-এ দেখা যাবে। CA trust না করলে curl: (60) SSL certificate problem: self-signed certificate in certificate chain দেখা যায়; Node agent-এর সমতুল্য error-এ SELF_SIGNED_CERT_IN_CHAIN code থাকে। পরে console viewer দিয়ে সংরক্ষিত flow পড়ুন। সেখানে একটি request খুলে তার header ও body পড়তে পারবেন।

mitmproxy -r /tmp/agent-flows.mitm

চারটি ফলাফল আলাদা করে দেখা দরকার। আপনি request দেখতে পাচ্ছেন। সে ক্ষেত্রে request পড়ে সিদ্ধান্ত নিন। Certificate error-এর কারণে agent শুরু হচ্ছে না। এটি ওই runtime-এর trust সমস্যা; vendor সম্পর্কে কোনো প্রমাণ নয়। আপনি শুধু model API দেখতে পাচ্ছেন। এর অর্থ অন্য category-গুলো বন্ধ আছে, অথবা এমন কোনো event ঘটলে সেগুলো চালু হয় যা আপনি trigger করেননি। অথবা agent স্পষ্টভাবে কাজ করলেও কিছুই দেখা যাচ্ছে না। এর অর্থ client proxy environment variable উপেক্ষা করছে, অথবা certificate pinning ব্যবহার করছে। তাই কোনো application setting আপনাকে সত্যতা জানাচ্ছে বলে ধরে নেওয়া যাবে না। শেষের ফলাফলটিই সবচেয়ে গুরুত্বপূর্ণ। এটি আপনাকে ধাপ 3-এ ফিরিয়ে নিয়ে যায়, কারণ packet capture কোনো connection দেখেছে কি না তা যুক্তি দিয়ে বদলানো যায় না।

নিয়ন্ত্রণব্যবস্থা: দুর্বল থেকে শক্তিশালী

Opt-out settings। সবচেয়ে সস্তা এবং সবচেয়ে দুর্বল পদ্ধতি। কারণ এগুলো vendor-এর সেগুলো মেনে চলার ওপর নির্ভর করে এবং আগে থেকেই বিদ্যমান একটি category-র ওপর প্রযোজ্য হয়। এমন জায়গায় এগুলো সেট করুন, যাতে reboot এবং নতুন terminal চালুর পরও কার্যকর থাকে—user settings file বা shell profile-এ। সেখানে DO_NOT_TRACK=1-ও যোগ করুন। এটি অনেক command line tool, এমনকি কিছু agent-ও, অনুসরণ করে এবং এর কোনো খরচ নেই। এরপর পরবর্তী update-এর পরে step 3 আবার চালান। কারণ তখনই coverage পরিবর্তিত হয়।

Egress restriction। এখানে আপনি অনুমতি চাওয়া বন্ধ করে enforcement শুরু করেন। agent-কে নিজস্ব user হিসেবে চালান। এরপর সেই user-এর জন্য loopback এবং DNS অনুমোদন করুন এবং বাকি সব traffic drop করুন। এতে আলাদা table যোগ হয়। তাই বিদ্যমান 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
  }
}

sudo nft -f /etc/nftables.d/agent.nft দিয়ে এটি প্রয়োগ করুন, sudo nft list table inet agentegress দিয়ে counter পর্যবেক্ষণ করুন এবং sudo journalctl -k -g agent-egress-drop দিয়ে drop হওয়া traffic পড়ুন। প্রত্যাশিত নয় এমন কোনো hostname-এর ক্ষেত্রে drop counter বাড়তে থাকা—এই ব্যবস্থার মূল উদ্দেশ্য। এখানে দুটি গুরুত্বপূর্ণ সীমাবদ্ধতা আছে। meta skuid socket-এর মালিক user-কে শনাক্ত করে। তাই ওই account অন্য user-এ পরিণত হতে না পারলেই এটি কার্যকর থাকে। agent-এর জন্য passwordless sudo অনুমোদিত থাকলে এই rule কেবল একটি পরামর্শে পরিণত হয়। আবার যেকোনো server-এর জন্য UDP 53 খোলা রাখলে query name-এর মধ্যে data বাইরে পাঠানোর একটি channel থেকে যায়। আপনার threat model-এ প্রয়োজন হলে এটিও বন্ধ করুন। সে জন্য agent-এর resolver আপনার পরিচালিত একটি host-এর দিকে নির্দেশ করুন। Hostname allowlist nftables-এর পরিবর্তে proxy-তে রাখা উচিত। কারণ API endpoint-গুলো এমন content delivery network-এর পেছনে থাকে, যাদের IP address পরিবর্তিত হয়। এই নিয়ন্ত্রণের মূল্য হলো service ব্যাহত হওয়া এবং রক্ষণাবেক্ষণের প্রয়োজন। Package install, SSH-এর মাধ্যমে git এবং agent-এর নিজস্ব update check—সবই অনুমতি না দেওয়া পর্যন্ত ব্যর্থ হবে। এখন সেই allowlist রক্ষণাবেক্ষণের দায়িত্ব আপনার। Laptop-এর পরিবর্তে server-এ এটি সেট আপ করলে একই account এবং firewall layout VPS-এ Claude Code নিরাপদে চালানোর ভিত্তি তৈরি করে।

A disposable machine। agent-কে এমন একটি virtual machine (VM) দিন, যেখানে আপনার গুরুত্বপূর্ণ কোনো credential নেই এবং task শেষ হলে সেটি ধ্বংস করা হয়। এতে agent কী পাঠায় তা কমে না। বরং agent যে resource থেকে data পাঠাতে পারে, তার access কমে। সাধারণত প্রকৃত ঝুঁকিটিই এটি। উপরের egress rule-এর সঙ্গে এটি ব্যবহার করুন। কারণ unrestricted internet access-সহ একটি নতুন VM-ও আপনার capture-এ থাকা প্রতিটি host-এ পৌঁছাতে পারে। এই পদ্ধতি এবং প্রতিবার পুনর্নির্মাণ করতে হওয়া state disposable VM-এ coding agent চালানোর নির্দেশিকায় বর্ণনা করা হয়েছে। Sizing-সংক্রান্ত প্রশ্নের উত্তর আছে VPS-এ coding agent চালানোর নির্দেশিকায়।

Self-hosting the model। এটিই একমাত্র নিয়ন্ত্রণব্যবস্থা, যা inference flow সরিয়ে দেয়। কারণ prompt আপনার hardware ছেড়ে বাইরে যায় না। এর খরচ বাস্তব। Closed model self-host করা যায় না। তাই open weights বেছে নিতে হবে, কঠিন task-এ capability gap মেনে নিতে হবে এবং model serve করার জন্য প্রয়োজনীয় hardware দিতে হবে। এই trade-off আপনি Claude self-host করতে পারবেন কি না-এ বিশ্লেষণ করা হয়েছে। প্রধান agent-গুলোর capability difference ব্যাখ্যা করা হয়েছে Claude Code, Cursor, Codex এবং Copilot-এর পার্থক্য-এ।

এই চারটি নিয়ন্ত্রণব্যবস্থার কোনোটিই agent disk থেকে কী পড়তে পারবে তা পরিবর্তন করে না। Inference traffic-এর মাধ্যমে agent যা পড়ে, তা-ই পাঠানো হয়। Working directory-তে কোনো .env file থাকলে agent variable name-এর জন্য grep চালানোর মুহূর্তেই সেটি model-এর কাছে চলে যায়। এই material agent-এর নাগালের বাইরে রাখা আলাদা কাজ। এটি AI agent-এর context থেকে secret দূরে রাখার নির্দেশিকায় ব্যাখ্যা করা হয়েছে।

প্রতিটি update-এর পরে যা পরীক্ষা করবেন

1. Vendor-এর settings এবং data usage page-কে গতবার নথিবদ্ধ করা তথ্যের সঙ্গে diff করুন। নতুন switch এবং নতুন নামে উল্লেখ করা service খুঁজুন।
2. /proc/<pid>/environ থেকে process environment আবার পড়ুন। এতে running process-এ আপনার opt-out এখনও প্রয়োগ করা আছে কি না নিশ্চিত করা যাবে।
3. Project settings file আবার 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 যে file পড়েছে এবং চালানো command-এর output model endpoint-এ পাঠানোই inference-এর কাজের পদ্ধতি। তাই একমাত্র পরিবর্তনশীল হলো কে এগুলো পায়। আপনি agent-কে কোনো company cloud account অথবা নিজে host করা model ব্যবহার করিয়ে receiver পরিবর্তন করতে পারেন। agent কী পড়তে পারবে তা সীমিত করে পাঠানো data-এর পরিমাণও কমাতে পারেন। Analytics এবং error reporting বন্ধ করলেও এই data flow-তে কোনো প্রভাব পড়ে না।

আমার coding agent কোন host-এ সংযোগ করছে তা কীভাবে দেখব?

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-এর জন্য একটি করে line দেখা যাবে। সেখানে destination address এবং requested hostname থাকবে। sudo tcpdump -ni any 'udp port 53' দিয়ে name যাচাই করুন। Capture করুন any-এ, কারণ 127.0.0.53-এ থাকা local resolver stub প্রথমে query পরিচালনা করে। Agent বাস্তব কাজ করার সময় capture করুন। কারণ startup ping এবং crash report idle capture-এ কখনো দেখা যায় না।

Agent কাজ করার সময় আমার proxy কোনো traffic দেখাচ্ছে না। কী সমস্যা হয়েছে?

হয় client HTTP_PROXY এবং HTTPS_PROXY উপেক্ষা করছে, অথবা certificate pinning ব্যবহার করে আপনার CA প্রত্যাখ্যান করছে। প্রথমে curl দিয়ে path পরীক্ষা করুন। যদি curl proxy ব্যবহার করে Internet-এ পৌঁছায়, কিন্তু flow list-এ agent দেখা না যায়, তাহলে agent proxy environment variable ব্যবহার করছে না। কিছু runtime-এ নির্দিষ্ট পদ্ধতিতে CA দিতে হয়। বিশেষ করে Node process শুরু হওয়ার সময় শুধু NODE_EXTRA_CA_CERTS পড়ে। তাই agent চালু করার পরে এটি export করলে কোনো ফল হবে না। Proxy traffic দেখতে না পারলে packet capture ব্যবহার করুন। কোনো application setting এটি bypass করতে পারে না।

Telemetry বন্ধ করলে কি আমার code training-এ ব্যবহার হওয়া বন্ধ হবে?

না। Analytics এবং crash reporting inference থেকে আলাদা data flow। তাই এগুলো বন্ধ করলে usage counter এবং stack trace পাঠানো বন্ধ হবে, কিন্তু প্রতিটি prompt আগের মতোই model-এ যাবে। সেই prompt সংরক্ষণ করা হবে কি না এবং ভবিষ্যৎ model training-এ ব্যবহার করা হবে কি না, তা আপনার plan-এর শর্তে নির্ধারিত হয়। Consumer plan এবং commercial plan-এর শর্ত সাধারণত আলাদা। এটি packet capture করে যাচাই করার বিষয় নয়; contract পড়ে যাচাই করতে হয়। তাই আপনার plan-এর data usage page পরীক্ষা করুন। গুরুত্বপূর্ণ হলে প্রথম session-এর আগেই commercial অথবা zero-retention agreement করুন।