تله‌متری در دستیارهای برنامه‌نویسی چه داده‌هایی می‌فرستد؟

تله‌متری در دستیارهای برنامه‌نویسی دقیقاً شامل چه مواردی است

تله‌متری در دستیارهای برنامه‌نویسی از چهار جریان دادهٔ مجزا تشکیل شده است که همگی با یک نام واحد شناخته می‌شوند، اما هر کدام کنترل‌های خاص خود را دارند. استنتاج مدل (Model inference)، پرامپت‌ها و کدهای شما را به سرویس‌دهندهٔ مدل ارسال می‌کند و هیچ تنظیمی برای غیرفعال کردن آن وجود ندارد. تحلیل‌های محصول و گزارش‌های خرابی (Crash reports) برای فروشنده و اغلب برای یک شرکت ارائه‌دهندهٔ خدمات لاگ که طرف قرارداد فروشنده است، ارسال می‌شوند. نگهداری داده‌ها برای آموزش مدل، بیش از آنکه یک مسئلهٔ شبکه‌ای باشد، یک موضوع قراردادی است. جریان چهارم همان موردی است که معمولاً نادیده گرفته می‌شود: هر افزونه‌ای که نصب می‌کنید، می‌تواند اتصالی به یک میزبان (host) برقرار کند که شما هرگز آن را انتخاب نکرده‌اید.

فهرست تنظیمات پیش‌فرض فروشندگان، بخشی از این موضوع است که به‌سرعت قدیمی می‌شود. یک نسخهٔ جدید (release) می‌تواند تنظیمات پیش‌فرض را تغییر دهد و یک قابلیت جدید ممکن است مقصدی را اضافه کند که هیچ‌کدام از سوییچ‌های موجود آن را پوشش نمی‌دهند. بنابراین، مهارت پایدار در این زمینه، انجام یک ممیزی قابل‌تکرار برای هر دستیار است: مستندات فروشنده را بخوانید، بررسی کنید که کدام پیکربندی واقعاً روی این دستگاه اعمال شده است، فرآیند را از داخل خود دستگاه زیر نظر بگیرید و سپس کنترل‌هایی را انتخاب کنید که مایل به پذیرش هزینه‌های آن هستید. تمام دستورات زیر، دستوراتی هستند که شما روی دستگاه خود و برای بررسی ترافیک خود اجرا می‌کنید.

چهار دسته‌بندی و دلیل نیاز آن‌ها به کنترل‌های متفاوت

ترافیک استنتاج مدل (Model inference) اجتناب‌ناپذیر است. عامل (agent)، پرامپت شما، فایل‌هایی که خوانده، خروجی دستوراتی که اجرا کرده و متن تولیدشده توسط خودش را به یک endpoint مدل ارسال می‌کند. این ماهیت عملکرد محصول است. تنها تصمیم واقعی این است که چه کسی آن را دریافت می‌کند: یک API که توسط شخص دیگری اجرا می‌شود، یا مدلی که خودتان اجرا می‌کنید. یک حساب ابری شرکتی (مانند Bedrock، Vertex یا Foundry) فقط دریافت‌کننده را تغییر می‌دهد، نه جریان داده را. هیچ‌کدام از موارد باقی‌مانده در این مطلب، ترافیک استنتاج را کاهش نمی‌دهند، بنابراین آن را در ذهن خود از سه دسته دیگر جدا نگه دارید.

تحلیل محصول و گزارش خرابی، جریانی متفاوت به میزبان‌های متفاوت هستند. شمارنده‌های استفاده، اعداد مربوط به تأخیر (latency)، جستجوی feature-flag و stack traceها معمولاً به نام‌های میزبانی ارسال می‌شوند که هیچ ارتباطی با API مدل ندارند و اغلب به یک سرویس ردیابی خطای شخص ثالث ارسال می‌شوند. فروشندگان معمولاً این موارد را به عنوان "معیارها" (metrics) و "گزارش‌های خطا" مستند می‌کنند و معمولاً برای هر دسته یک متغیر محیطی (environment variable) در اختیار شما قرار می‌دهند. حجم این داده‌ها بسیار ناچیز است، بنابراین شمارش بایت‌ها هرگز آن‌ها را شناسایی نخواهد کرد. شما باید به دنبال نام‌های میزبان باشید، نه پهنای باند.

نگهداری و آموزش، سیاست هستند، نه بسته (packet). اینکه فروشنده پرامپت‌های شما را نگه می‌دارد یا خیر، چه مدت نگه می‌دارد و آیا از آن‌ها برای آموزش مدل‌های آینده استفاده می‌کند یا نه، در شرایط پیوست‌شده به طرح (plan) شما نوشته شده است. طرح‌های مصرف‌کننده و طرح‌های تجاری معمولاً متفاوت هستند و توافق‌نامه عدم نگهداری (zero-retention) معمولاً یک توافق جداگانه است. شما نمی‌توانید هیچ‌کدام از این موارد را با tcpdump تأیید کنید، زیرا بسته (packet) در هر دو حالت یکسان به نظر می‌رسد. شرایط را بخوانید و اگر این موضوع برای کارفرمای شما اهمیت دارد، آن را به صورت کتبی دریافت کنید.

یکپارچه‌سازی‌ها (Integrations) بی‌سروصدا یک گام اضافه می‌کنند. یک سرور MCP (پروتکل زمینه مدل)، بازارچه افزونه‌ها، بررسی به‌روزرسانی خودکار، ابزار جستجوی وب، یا بررسی امنیتی که پیش از دریافت یک URL آن را resolve می‌کند: هر کدام از این‌ها یک درخواست به میزبانی هستند که endpoint مدل نیست. اینجاست که غافلگیری‌ها رخ می‌دهند، زیرا یک harness می‌تواند کاری را که تصور می‌کردید محلی است، از طریق سرویس خودش هدایت کند و یک نسخه جدید (release) می‌تواند بدون تغییر حتی یک خط از پیکربندی شما، شروع به انجام این کار کند. هر ابزاری که اضافه می‌کنید را تا زمانی که آن را روی شبکه (wire) مشاهده نکرده‌اید، به عنوان یک مقصد جدید در نظر بگیرید.

گام 1: مستندات فروشنده چه می‌گویند؟

مرجع تنظیمات و صفحه استفاده از داده‌ها برای agent خود را باز کنید و آن‌ها را با در دست داشتن فهرستی از کلمات کلیدی مطالعه کنید: metrics، analytics، error reporting، crash، feedback، survey، update check، safety check، marketplace. هر یک از این کلمات معمولاً یک سوئیچ جداگانه هستند. نام دقیق متغیرها را یادداشت کنید، زیرا در گام 2 از آن‌ها برای grep استفاده خواهید کرد.

یک کلمه ممکن است شما را گمراه کند. در چندین agent، واژه "telemetry" در مستندات به معنای خروجی OpenTelemetry است که شما آن را پیکربندی می‌کنید تا معیارها را به collectorای که خودتان اجرا می‌کنید بفرستد؛ این دقیقاً برعکس ارسال داده به فروشنده است. Claude Code یکی از این موارد است: تنظیم CLAUDE_CODE_ENABLE_TELEMETRY=1 باعث شروع ارسال داده به endpointای می‌شود که در OTEL_EXPORTER_OTLP_ENDPOINT نام می‌برید و این موضوع با analytics خودِ فروشنده که opt-out متفاوتی دارد، بی‌ارتباط است. پیش از تنظیم هر چیزی، مشخص کنید که جریان داده به کدام سمت است.

انتظار یک سوئیچ اصلی (master switch) را داشته باشید و انتظار داشته باشید که این سوئیچ دارای حفره‌هایی باشد. تا آگوست 2026، تنظیم CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC در Claude Code، معیارها، گزارش‌های خطا، دستور feedback و نظرسنجی‌های نشست را با هم غیرفعال می‌کند. همان مستندات می‌گوید که این تنظیم شامل بررسی ایمنی دامنه WebFetch نمی‌شود؛ فرآیندی که نام میزبانی (hostname) که قصد واکشی آن را دارید به API فروشنده می‌فرستد و تنظیمات جداگانه خود را دارد. این شکایتی از یک محصول خاص نیست؛ بلکه ماهیت مشکل در همه جاست: یک سوئیچ اصلی تنها دسته‌هایی را پوشش می‌دهد که در زمان نگارش آن وجود داشته‌اند.

انتظار داشته باشید که opt-out برای شما هزینه‌ای هم داشته باشد. همان مستندات اشاره می‌کنند که غیرفعال کردن telemetry، ارزیابی feature-flag که برخی قابلیت‌ها به آن وابسته‌اند را نیز غیرفعال می‌کند. بنابراین سوئیچی که برای حفظ حریم خصوصی تغییر می‌دهید، می‌تواند قابلیتی که از آن استفاده می‌کنید را بدون هیچ پیام خطایی که این دو را به هم مرتبط کند، از کار بیندازد. جمله کنار پرچم (flag) را بخوانید، نه فقط نام آن را.

گام 2: کدام پیکربندی واقعاً اعمال شده است؟

تنظیمی که نوشته‌اید لزوماً تنظیمی نیست که اعمال شده است. عامل‌ها (Agents) پیکربندی را از چندین فایل ادغام می‌کنند و یکی از آن‌ها درون مخزنی است که به‌تازگی از شخص دیگری کلون کرده‌اید. با محیط shell خودتان شروع کنید.

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

سپس تمام فایل‌های تنظیماتی که ابزار می‌خواند را به ترتیبی که مستندات ارائه داده‌اند، چاپ کنید. برای Claude Code، تا اوت 2026، این فایل‌ها شامل فایل کاربر، دو فایل پروژه و یک دایرکتوری سیاست مدیریت‌شده در لینوکس هستند.

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 چاپ می‌کند.

مطمئن‌ترین بررسی، خواندن فرآیند در حال اجرا به‌جای هر فایلی است. ابتدا یک حساب کاربری لینوکس اختصاصی برای عامل ایجاد کنید که باعث کوتاه‌تر شدن تمام دستورات این پست می‌شود، سپس محیطی که فرآیند با آن شروع شده است را بخوانید.

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 time) داشته است؛ بنابراین این دستور حالتی را شناسایی می‌کند که در آن .bashrc export شما هرگز به سرویسی که توسط systemd شروع شده، نرسیده است. اگر متغیر تنظیم‌شده توسط شما در اینجا وجود ندارد، فارغ از آنچه در dotfileهای شما نوشته شده، آن متغیر هرگز اعمال نشده است.

گام 3: این عامل به چه میزبان‌هایی متصل می‌شود؟

با سوکت‌های باز شروع کنید و آن‌ها را بر اساس کاربری که عامل (agent) با آن اجرا می‌شود، فیلتر کنید.

sudo ss -tnpe state established

-e یک فیلد uid: به هر خط اضافه می‌کند تا بتوانید اتصالات عامل را از اتصالات مرورگر خود بدون نیاز به خواندن نام پردازش‌ها تفکیک کنید. آدرس‌های مقصد را یادداشت کنید و سپس نام‌های پشت آن‌ها را استخراج کنید. تمیزترین منبع برای یافتن نام‌ها، دست‌دادن (handshake) پروتکل TLS است؛ زیرا هر اتصال جدید با یک ClientHello شروع می‌شود که حاوی فیلد SNI (نشانگر نام سرور) است؛ این همان نام میزبانی است که کلاینت درخواست کرده است.

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

شما به ازای هر اتصال جدید، یک خط دریافت می‌کنید که دقیقاً همان فهرستی است که به آن نیاز دارید: API مدل، سرور به‌روزرسانی، میزبان تحلیل داده، ردیاب خطا و هر چیزی که یکپارچه‌سازی (integration) اضافه کرده است. خالی بودن ستون نام به این معناست که کلاینت از ECH (سلام کلاینت رمزنگاری‌شده) استفاده کرده است؛ بنابراین نام میزبان روی شبکه قابل مشاهده نیست و باید به آدرس IP مقصد، جستجوی معکوس (reverse lookup) یا پروکسی در گام 4 متوسل شوید.

نمای DNS (سامانه نام دامنه) یک بررسی متقاطع مفید است، زیرا نام‌هایی را که عامل حتی برای اتصالات ناموفق جستجو کرده است، نشان می‌دهد.

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

هر خط پرس‌وجو با نوع رکورد و نام، به فرمت A? host.example.net. (39) پایان می‌یابد. عملیات ضبط را روی any انجام دهید، نه روی رابط خارجی؛ زیرا با systemd-resolved، برنامه با یک شنونده محلی (stub) روی 127.0.0.53 صحبت می‌کند و فقط همان stub با دنیای خارج در ارتباط است. اگر در حالی که عامل به‌وضوح در حال کار است، هیچ ترافیک DNS مشاهده نمی‌کنید، یعنی آن محیط اجرا (runtime) خودش از DNS over HTTPS استفاده می‌کند و فقط گام 4 نام‌ها را در اختیار شما قرار خواهد داد.

در حالی که عامل در حال انجام کار واقعی است، عملیات ضبط را انجام دهید. یک نشست (session) را شروع کنید، از آن بخواهید فایلی را بخواند، دستوری را اجرا کند یا در انجام کاری شکست بخورد. ترافیکی که فقط یک بار در زمان راه‌اندازی یا فقط هنگام بروز خطا ارسال می‌شود، هرگز در یک ضبطِ حالتِ بیکار (idle) ظاهر نمی‌شود؛ و ضبط در حالت بیکار، رایج‌ترین راهی است که یک ممیزی را به نتیجه‌ای اشتباه اما متقاعدکننده می‌رساند.

گام 4: محتوای درخواست‌ها چیست؟

نام‌های دامنه مشخص می‌کنند که مقصد کیست. برای مشاهده محتوا، یک پراکسی تحت کنترل خود را پیش از agent قرار دهید و گواهی مرجع (CA) آن را فقط برای همان runtime معتبر بدانید. ابزار معمول برای این کار mitmproxy است. این پروژه استفاده از باینری‌های مستقل از mitmproxy.org را توصیه می‌کند و در uv tool install mitmproxy مسیر استفاده از بسته پایتون را مستند کرده است.

mitmdump -w /tmp/agent-flows.mitm

اولین اجرا، یک CA در ~/.mitmproxy/ می‌نویسد که در آن mitmproxy-ca-cert.pem گواهی اختصاصی آن است. در shellای که قصد دارید agent را از آن اجرا کنید، کلاینت را به سمت پراکسی و آن گواهی هدایت کنید.

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"

بسیاری از CLIهای agent برنامه‌های Node هستند و Node هنگام شروع پردازش، NODE_EXTRA_CA_CERTS را می‌خواند؛ بنابراین آن را پیش از اجرای agent صادر (export) کنید و نه بعد از آن در ترمینالی دیگر. کلاینت‌های پایتون REQUESTS_CA_BUNDLE یا SSL_CERT_FILE را می‌خوانند و باینری‌های Go که از کتابخانه استاندارد استفاده می‌کنند، در لینوکس SSL_CERT_FILE را می‌خوانند. پیش از آنکه agent را مقصر بدانید، با curl صحت مسیر را بررسی کنید.

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

یک پراکسی فعال، 200 را چاپ می‌کند و درخواست در خروجی mitmdump ظاهر می‌شود. یک CA غیرقابل‌اعتماد، curl: (60) SSL certificate problem: self-signed certificate in certificate chain را برمی‌گرداند و خطای معادل آن در یک agent مبتنی بر Node، خطایی با کد SELF_SIGNED_CERT_IN_CHAIN است. جریان‌های ذخیره‌شده را پس از آن با کنسول viewer بخوانید؛ جایی که می‌توانید یک درخواست را باز کرده و هدرها و بدنه آن را مشاهده کنید.

mitmproxy -r /tmp/agent-flows.mitm

چهار نتیجه ارزش بررسی دارند. شما درخواست‌ها را می‌بینید که در این صورت آن‌ها را بخوانید و تصمیم بگیرید. agent با خطای گواهی از شروع امتناع می‌کند که یک مشکل اعتماد در آن runtime است و نه یافته‌ای درباره فروشنده. شما فقط API مدل را می‌بینید که به این معنی است که دسته‌های دیگر غیرفعال هستند یا در رویدادی که شما فعال نکرده‌اید، اجرا می‌شوند. یا اینکه با وجود عملکرد صحیح agent، هیچ چیزی نمی‌بینید که به این معنی است که کلاینت متغیرهای محیطی پراکسی را نادیده می‌گیرد یا گواهی‌های خود را اصطلاحاً pin کرده است و هیچ تنظیمات برنامه‌ای نمی‌تواند حقیقت را به شما بگوید. نتیجه آخر مهم‌ترین مورد است و شما را به گام 3 بازمی‌گرداند، زیرا packet capture را نمی‌توان از دیدن یک اتصال منصرف کرد.

کنترل‌ها، از ضعیف‌ترین تا قوی‌ترین

تنظیمات Opt-out. ارزان‌ترین و ضعیف‌ترین روش است، زیرا کارکرد آن به پایبندی فروشنده به این تنظیمات و پوشش دسته‌ای بستگی دارد که از قبل وجود داشته است. این تنظیمات را در فایل تنظیمات کاربر یا در shell profile خود اعمال کنید تا پس از reboot و باز کردن terminal جدید باقی بمانند. در حین انجام این کار، DO_NOT_TRACK=1 را نیز اضافه کنید: این یک قرارداد است که بسیاری از ابزارهای خط فرمان، از جمله برخی agentها، به آن احترام می‌گذارند و هیچ هزینه‌ای ندارد. سپس پس از به‌روزرسانی بعدی، مرحله 3 را دوباره اجرا کنید، زیرا در آن لحظه است که پوشش تغییر می‌کند.

محدودیت خروجی (Egress restriction). در اینجا دیگر درخواست نمی‌کنید، بلکه اعمال قانون می‌کنید. agent را با کاربر اختصاصی خودش اجرا کنید، سپس به آن کاربر اجازه دسترسی به loopback و DNS را بدهید و بقیه ترافیک را مسدود کنید. این روش جدول مخصوص به خود را اضافه می‌کند، بنابراین قوانین firewall موجود را دست‌نخورده باقی می‌گذارد.

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 با کاربری که مالک socket است مطابقت دارد، بنابراین تنها زمانی معتبر است که آن حساب کاربری نتواند به کاربر دیگری تبدیل شود: استفاده از sudo بدون رمز عبور برای agent، این قانون را به یک پیشنهاد تبدیل می‌کند. همچنین باز گذاشتن پورت UDP 53 برای هر سروری، کانالی ایجاد می‌کند که می‌تواند داده‌ها را در query nameها خارج کند؛ بنابراین اگر مدل تهدید شما ایجاب می‌کند، آن را نیز ببندید و resolver مربوط به agent را به سمت hostای که خودتان مدیریت می‌کنید، هدایت کنید. لیست‌های مجاز (allowlist) نام دامنه باید در یک proxy قرار بگیرند نه در nftables، زیرا endpointهای API پشت شبکه‌های توزیع محتوا (CDN) قرار دارند که آدرس‌های IP آن‌ها مدام تغییر می‌کند. هزینه این کنترل، خرابی و نگهداری است: نصب بسته‌ها، git از طریق SSH و بررسی به‌روزرسانی خودِ agent، همگی تا زمانی که اجازه دسترسی به آن‌ها را ندهید با شکست مواجه می‌شوند و اکنون مسئولیت نگهداری این لیست با شماست. اگر این تنظیمات را روی سرور انجام می‌دهید و نه لپ‌تاپ، همان حساب کاربری و ساختار firewall، پایه اجرای ایمن Claude Code روی یک VPS است.

ماشین یک‌بارمصرف (Disposable machine). به agent یک ماشین مجازی (VM) بدهید که هیچ اعتبارنامه‌ای (credential) که برایتان مهم است در آن نباشد و در پایان کار نابود شود. این کار آنچه agent ارسال می‌کند را کاهش نمی‌دهد، بلکه دسترسی agent برای ارسال داده را محدود می‌کند که معمولاً همان ریسکی است که واقعاً برایتان اهمیت دارد. آن را با قوانین egress بالا ترکیب کنید، زیرا یک VM تازه با دسترسی نامحدود به اینترنت، همچنان به هر hostای در محدوده دید شما دسترسی دارد. این روش و وضعیتی که باید هر بار بازسازی کنید، در اجرای agentهای کدنویسی در یک VM یک‌بارمصرف و مسئله ابعاد آن در اجرای یک agent کدنویسی روی یک VPS پوشش داده شده است.

میزبانی مدل (Self-hosting). تنها کنترلی که جریان استنتاج (inference) را حذف می‌کند، زیرا prompt هرگز از سخت‌افزار شما خارج نمی‌شود. هزینه آن واقعی است: شما نمی‌توانید یک مدل بسته را self-host کنید، بنابراین این به معنای انتخاب وزن‌های متن‌باز (open weights) و پذیرش شکاف توانایی در کارهای دشوار، به علاوه تأمین سخت‌افزار برای اجرای آن‌هاست. این بده‌بستان در آیا می‌توانید Claude را self-host کنید و تفاوت‌های توانایی بین agentهای اصلی در تفاوت Claude Code، Cursor، Codex و Copilot بررسی شده است.

هیچ‌کدام از این چهار کنترل، آنچه agent اجازه خواندنش را از روی دیسک دارد تغییر نمی‌دهند و ترافیک استنتاج، هر آنچه را که می‌خواند با خود حمل می‌کند. اگر یک فایل .env در دایرکتوری کاری باشد، لحظه‌ای که agent برای یک نام متغیر grep می‌کند، آن فایل به مدل ارسال می‌شود. دور نگه داشتن این مطالب، یک وظیفه جداگانه است که در دور نگه داشتن اسرار از context یک agent هوش مصنوعی به آن پرداخته شده است.

مواردی که باید پس از هر به‌روزرسانی بررسی شوند

1. تفاوت بین صفحات تنظیمات و میزان مصرف دادهٔ ارائه‌دهنده را با آنچه قبلاً ثبت کرده‌اید مقایسه کنید و به دنبال سوییچ‌ها و سرویس‌های نام‌گذاری‌شدهٔ جدید باشید.
2. محیط پردازش را از /proc/<pid>/environ دوباره بخوانید تا مطمئن شوید که انصراف‌های (opt-outs) شما همچنان روی پردازش در حال اجرا اعمال می‌شوند.
3. فایل‌های تنظیمات پروژه را دوباره چاپ کنید، زیرا یک git pull می‌تواند فایل پیکربندی جدیدی را وارد کند که توسط یکی از همکاران تغییر یافته است.
4. عملیات SNI capture را برای یک نشست کامل از کار واقعی اجرا کنید و لیست نام‌های میزبان (hostname) را با لیست قبلی خود مقایسه کنید.
5. شمارندهٔ drop فایروال را بررسی کنید، زیرا مقصد جدید معمولاً پیش از آنکه در جای دیگری متوجه آن شوید، در آنجا ظاهر می‌شود.

این کار حدود 10 دقیقه زمان می‌برد و تنها بخشی از فرآیند است که قدیمی نمی‌شود. یک پیش‌فرض که در اوت 2026 تأیید کرده‌اید، حقیقتی دربارهٔ اوت 2026 است. اما capture، حقیقتی دربارهٔ امروز است.

FAQ

آیا می‌توانم از ارسال کدهایم توسط coding agent به مدل جلوگیری کنم؟

خیر، و هر تنظیماتی که ادعای انجام این کار را دارد، در واقع به موضوع دیگری اشاره می‌کند. ارسال پرامپت، فایل‌هایی که agent خوانده است و خروجی دستوراتی که اجرا کرده به endpoint مدل، ماهیت اصلی فرآیند inference است؛ بنابراین تنها متغیر موجود، گیرندهٔ این داده‌هاست. شما می‌توانید با تنظیم agent روی یک حساب ابری شرکتی یا مدلی که خودتان میزبانی می‌کنید، گیرنده را تغییر دهید و با محدود کردن فایل‌هایی که agent اجازهٔ خواندن آن‌ها را دارد، حجم داده‌های ارسالی را کاهش دهید. خاموش کردن قابلیت‌های analytics و error reporting هیچ تأثیری بر این جریان ندارد.

چگونه ببینم coding agent من به چه میزبان‌هایی متصل می‌شود؟

agent را با یک کاربر لینوکسی مجزا اجرا کنید و سپس هنگام استفاده از آن، 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 ضبط کنید. برای هر اتصال یک خط نمایش داده می‌شود که شامل آدرس مقصد و hostname درخواستی است. نام‌ها را با sudo tcpdump -ni any 'udp port 53' تطبیق دهید و عملیات capture را روی any انجام دهید، زیرا یک local resolver stub روی 127.0.0.53 ابتدا پرس‌وجو را مدیریت می‌کند. این کار را زمانی انجام دهید که agent در حال انجام کار واقعی است، چرا که پینگ‌های زمان راه‌اندازی و گزارش‌های خرابی در حالت idle نمایش داده نمی‌شوند.

پروکسی من هنگام کار agent هیچ ترافیکی نشان نمی‌دهد. چه مشکلی پیش آمده است؟

یا کلاینت HTTP_PROXY و HTTPS_PROXY را نادیده می‌گیرد، یا گواهی‌های خود را اصطلاحاً pin کرده و CA شما را نمی‌پذیرد. ابتدا مسیر را با curl تست کنید: اگر curl از طریق پروکسی به اینترنت متصل می‌شود اما agent در لیست ترافیک دیده نمی‌شود، یعنی agent از متغیرهای محیطی پروکسی استفاده نمی‌کند. برخی runtimeها نیاز دارند که CA به روش خاصی ارائه شود؛ به‌ویژه Node که NODE_EXTRA_CA_CERTS را فقط در زمان شروع فرآیند می‌خواند، بنابراین export کردن آن پس از اجرای agent بی‌فایده است. زمانی که پروکسی قادر به مشاهده ترافیک نیست، از packet capture استفاده کنید که هیچ تنظیمات نرم‌افزاری نمی‌تواند آن را دور بزند.

آیا خاموش کردن telemetry مانع از استفاده کدهای من برای آموزش مدل می‌شود؟

خیر. قابلیت‌های analytics و crash reporting جریانی متفاوت از inference دارند؛ بنابراین غیرفعال کردن آن‌ها فقط شمارنده‌های استفاده و stack traceها را حذف می‌کند و تمامی پرامپت‌ها دقیقاً مانند قبل به مدل ارسال می‌شوند. اینکه آیا این پرامپت‌ها ذخیره می‌شوند و آیا برای آموزش مدل‌های آینده به کار می‌روند یا خیر، توسط شرایط طرح (plan) شما تعیین می‌شود و طرح‌های مصرف‌کننده (consumer) با طرح‌های تجاری معمولاً متفاوت هستند. این موضوع یک قرارداد حقوقی است که باید مطالعه شود، نه بسته‌ای که بتوان آن را capture کرد؛ بنابراین صفحهٔ استفاده از داده‌ها (data usage) مربوط به طرح خود را بررسی کنید و در صورت اهمیت، پیش از شروع اولین نشست، یک توافق‌نامه تجاری یا zero-retention تنظیم کنید.