Телеметрія coding agent: що саме надсилається

Що насправді охоплює телеметрія coding agent

Телеметрія coding agent — це чотири окремі потоки даних, об’єднані одним терміном, і кожен потік має власний механізм керування. Під час інференсу моделі ваші запити та код передаються тому, хто обслуговує модель; жодне налаштування не вимикає цей процес. Продуктова аналітика та звіти про аварійне завершення роботи надходять постачальнику, а часто також компанії, що веде журналювання для цього постачальника. Зберігання даних для навчання — це питання договору, а не мережевих налаштувань. Четвертий потік часто не враховують: кожна додана інтеграція може відкрити з’єднання з вузлом, який ви не вибирали.

Перелік поточних значень за замовчуванням у постачальників — найменш стабільна частина цієї теми. Новий реліз може змінити значення за замовчуванням, а нова функція — додати призначення, на яке не поширюється жоден наявний перемикач. Тому довготривала навичка — це аудит, який можна повторити для будь-якого агента: прочитати документацію постачальника, перевірити, які налаштування фактично застосовано на цій машині, спостерігати за процесом безпосередньо з машини, а потім вибрати засоби контролю, за які ви готові платити. Кожну наведену нижче команду потрібно виконувати на власній машині та для власного трафіку.

Чотири категорії та чому для них потрібні різні засоби контролю

Трафік інференсу моделі неминучий. Агент надсилає ваш промпт, прочитані ним файли, результати виконаних команд і власний згенерований текст на endpoint моделі. Так працює продукт. Єдине реальне рішення — визначити, хто отримує ці дані: API, яким керує інша сторона, чи модель, яку ви запускаєте самостійно. Корпоративний хмарний обліковий запис (Bedrock, Vertex, Foundry) змінює отримувача, але не усуває цей потік. Ніщо в решті цієї статті не зменшує трафік інференсу, тому не змішуйте його подумки з трьома іншими категоріями.

Продуктова аналітика та звіти про аварійне завершення — це інший потік до інших хостів. Лічильники використання, показники затримки, запити до feature flags і stack traces зазвичай надсилаються на доменні імена, які не мають стосунку до API моделі, а часто — до стороннього сервісу відстеження помилок. Постачальники зазвичай описують це як "metrics" і "error reports" та зазвичай надають по одній змінній середовища для кожної категорії. Обсяг даних дуже малий, тому підрахунок байтів ніколи цього не виявить. Шукайте хостнейми, а не пропускну здатність.

Зберігання та навчання — це політика, а не пакети. Чи зберігає постачальник ваші промпти, як довго він їх зберігає та чи навчає на них майбутню модель, визначається умовами вашого плану. Споживчі та комерційні плани зазвичай відрізняються, а умова про нульове зберігання зазвичай оформлюється окремою угодою. Ви не можете перевірити це за допомогою tcpdump, оскільки в обох випадках пакет виглядає однаково. Прочитайте умови, а якщо це важливо для вашого роботодавця, отримайте письмове підтвердження.

Інтеграції непомітно додають проміжну ланку. Сервер MCP (model context protocol), marketplace плагінів, перевірка автоматичних оновлень, інструмент вебпошуку, перевірка безпеки, яка визначає IP-адресу URL перед його отриманням, — кожен із них надсилає запит на хост, що не є endpoint моделі. Саме тут виникають несподіванки: harness може спрямувати роботу, яку ви вважали локальною, через власний сервіс, а новий реліз може почати це робити без зміни жодного рядка конфігурації. Вважайте кожен доданий інструмент новим пунктом призначення, доки не перевірите його мережевий трафік.

Крок 1: що документує постачальник?

Відкрийте довідник налаштувань і сторінку про використання даних для вашого агента та прочитайте їх зі списком ключових слів: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. Кожне з них зазвичай відповідає окремому перемикачу. Запишіть точні назви змінних, оскільки на кроці 2 виконується пошук саме за ними.

Одне слово може ввести в оману. У документації до кількох агентів слово "telemetry" означає експорт OpenTelemetry, який ви налаштовуєте для надсилання metrics до власного collector. Це протилежне надсиланню даних постачальнику. Claude Code — один із таких агентів: встановлення CLAUDE_CODE_ENABLE_TELEMETRY=1 запускає експорт до endpoint, указаного в OTEL_EXPORTER_OTLP_ENDPOINT, і не пов’язане з власною analytics постачальника, для якої передбачено інше налаштування відмови. Перш ніж щось встановлювати, визначте напрямок передавання даних.

Очікуйте наявності головного перемикача, але враховуйте його обмеження. Станом на August 2026 параметр CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC у Claude Code вимикає metrics, error reports, команду feedback і session surveys одночасно. У тій самій документації зазначено, що він не поширюється на перевірку безпеки домену WebFetch. Ця перевірка надсилає hostname, який ви збираєтеся отримати, до API постачальника та має окреме налаштування. Це не проблема лише одного продукту. Так влаштована ця категорія налаштувань: головний перемикач охоплює категорії, які існували на момент його створення.

Відмова від передавання даних також може мати наслідки. У тій самій документації зазначено, що вимкнення telemetry також вимикає оцінювання feature flags, від якого залежать деякі функції. Тому перемикач, змінений з міркувань конфіденційності, може вимкнути потрібну вам функцію без повідомлення про помилку, яке пов’язує ці події. Читайте речення поруч із параметром, а не лише його назву.

Крок 2: які налаштування фактично застосовано?

Налаштування, яке ви записали, не обов’язково застосовується. Agents об’єднують конфігурацію з кількох файлів. Один із них може міститися в repository, який ви щойно клонували з чужого джерела. Почніть із середовища власної shell-сесії.

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

Потім виведіть усі файли налаштувань, які читає tool, у порядку, наведеному в документації. Для Claude Code станом на August 2026 це user file, два project files і managed policy directory у 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

Project file, який надійшов разом із git clone, містить конфігурацію, написану іншою особою. Вона може повторно увімкнути параметр, вимкнений у user file. Якщо agent має status command, що показує завантажені джерела, це найшвидший спосіб перевірити фактичний стан: Claude Code виводить завантажені джерела налаштувань у /status.

Найнадійніша перевірка читає запущений process, а не файл. Спочатку надайте agent власний Linux user account. Це скоротить усі команди в цій публікації. Потім прочитайте середовище, з яким було запущено process.

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. Тому ця команда виявляє випадок, коли ваш .bashrc export не потрапив до service, запущеного systemd. Якщо змінної, яку ви встановили, тут немає, вона фактично не застосовувалася, незалежно від того, що зазначено у ваших dotfiles.

Крок 3: до яких хостів він підключається?

Почніть із відкритих сокетів, відфільтрованих за обліковим записом, від імені якого працює агент.

sudo ss -tnpe state established

-e додає поле uid: до кожного рядка. Це дає змогу відокремити підключення агента від підключень браузера без аналізу назв процесів. Занотуйте віддалені адреси, а потім визначте імена, що їм відповідають. Найнадійніше отримувати імена з рукостискання TLS (transport layer security), оскільки кожне нове підключення починається з ClientHello, який містить поле SNI (server name indication) — ім’я хоста, до якого звернувся клієнт.

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 моделі, сервер оновлень, хост аналітики, система відстеження помилок і все, що додала інтеграція. Порожній стовпець імені означає, що клієнт використав ECH (encrypted client hello), тому ім’я хоста не видно в мережевому трафіку. У такому разі використовуйте IP-адресу призначення, зворотне визначення імені або проксі з кроку 4.

Перегляд DNS (domain name system) корисний для перехресної перевірки, оскільки він показує імена, які агент запитував, навіть для незавершених підключень.

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

Кожен рядок запиту завершується типом запису та іменем у форматі A? host.example.net. (39). Перехоплюйте трафік на any, а не на зовнішньому інтерфейсі, оскільки за використання systemd-resolved застосунок звертається до локального stub listener на 127.0.0.53, а назовні звертається лише stub. Якщо під час очевидної роботи агента DNS-трафік взагалі відсутній, цей runtime самостійно використовує DNS over HTTPS, і лише крок 4 дасть змогу визначити імена.

Перехоплюйте трафік, поки агент виконує реальну роботу. Запустіть сеанс, попросіть його прочитати файл, виконати команду або спричинити помилку. Трафік, який виникає лише один раз під час запуску або лише під час виняткової ситуації, не з’явиться під час простою. Перехоплення в режимі простою — найпоширеніший спосіб отримати помилковий, але зручний результат аудиту.

Крок 4: що міститься в запитах?

Імена хостів показують, з ким взаємодіє агент. Щоб побачити вміст запитів, розмістіть керований вами проксі перед агентом і довірте його центру сертифікації (CA) лише для цього середовища виконання. Зазвичай для цього використовують mitmproxy. Проєкт рекомендує автономні бінарні файли з mitmproxy.org і описує uv tool install mitmproxy як варіант встановлення Python-пакета.

mitmdump -w /tmp/agent-flows.mitm

Під час першого запуску CA записується до ~/.mitmproxy/, де mitmproxy-ca-cert.pem — це сам сертифікат. У shell, з якого ви запускатимете агент, укажіть клієнту проксі та цей сертифікат.

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 агентів написано на Node. Node читає NODE_EXTRA_CA_CERTS під час запуску процесу, тому експортуйте цю змінну до запуску агента, а не в іншому терміналі після цього. Клієнти Python читають REQUESTS_CA_BUNDLE або SSL_CERT_FILE, а бінарний файл Go, який використовує стандартну бібліотеку, у Linux читає SSL_CERT_FILE. Перевірте роботу шляху за допомогою 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, а еквівалентна помилка агента Node містить код SELF_SIGNED_CERT_IN_CHAIN. Після цього прочитайте збережені потоки в консольному переглядачі. Там можна відкрити окремий запит і переглянути його заголовки та тіло.

mitmproxy -r /tmp/agent-flows.mitm

Варто розрізняти чотири результати. Ви бачите запити. У такому разі прочитайте їх і зробіть висновок. Агент відмовляється запускатися через помилку сертифіката. Це проблема довіри в конкретному середовищі виконання, а не висновок щодо постачальника. Ви бачите лише API моделі. Це означає, що інші категорії вимкнені або спрацьовують у відповідь на подію, яку ви не спричинили. Або ви взагалі нічого не бачите, хоча агент явно працює. Це означає, що клієнт ігнорує змінні середовища проксі або використовує pinning сертифікатів. У такому разі жодному налаштуванню застосунку не можна довіряти як джерелу правди. Саме останній результат має найбільше значення. Він повертає вас до кроку 3, оскільки packet capture неможливо переконати не бачити з’єднання.

Засоби контролю: від найслабших до найсильніших

Налаштування відмови. Це найдешевший і найслабший варіант, оскільки він залежить від того, чи постачальник дотримається цих налаштувань, і охоплює лише категорію, яка вже існувала. Задайте їх у місці, де вони збережуться після перезавантаження та відкриття нового термінала: у файлі налаштувань користувача або профілі оболонки. Одразу додайте DO_NOT_TRACK=1: це угода, якої дотримуються багато інструментів командного рядка, зокрема деякі агенти, і це нічого не коштує. Після наступного оновлення повторно виконайте крок 3, оскільки саме тоді змінюється охоплення.

Обмеження вихідного трафіку. Тут ви припиняєте просити й починаєте примусово застосовувати правила. Запустіть агента від його власного користувача, потім дозвольте цьому користувачу 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. Зростання лічильника блокувань разом із неочікуваним hostname — саме той результат, якого ви прагнете. Є два важливі обмеження. meta skuid зіставляє користувача, якому належить socket, тому правило діє лише доти, доки цей обліковий запис не може стати іншим користувачем: passwordless sudo для агента перетворює це правило на рекомендацію. Якщо залишити UDP 53 відкритим для будь-якого сервера, залишиться канал для виведення даних у назвах запитів, тому за потреби вашої моделі загроз його також слід закрити, вказавши агенту resolver на сервер, яким ви керуєте. Списки дозволених hostname краще налаштовувати в proxy, а не в nftables, оскільки API endpoints працюють через content delivery networks, IP-адреси яких можуть змінюватися без попередження. Вартість цього засобу контролю — збої в роботі та постійне обслуговування: інсталяція пакетів, git через SSH і власна перевірка оновлень агента не працюватимуть, доки ви не дозволите їх, а підтримувати цей список доведеться вам. Якщо ви налаштовуєте це на сервері, а не на laptop, така схема облікового запису та firewall є основою для безпечного запуску Claude Code на VPS.

Одноразова машина. Виділіть агенту virtual machine (VM), у якій немає важливих для вас облікових даних і яку буде знищено після завершення завдання. Це не зменшує обсяг даних, які агент надсилає, але зменшує обсяг даних, до яких агент має доступ для надсилання. Зазвичай саме цей ризик має для вас значення. Поєднайте цей підхід із наведеними вище правилами для вихідного трафіку, оскільки нова VM із необмеженим доступом до інтернету все одно матиме доступ до кожного host у вашому capture. Метод і стан, який потрібно щоразу відновлювати, описано в матеріалі запуск coding agents в одноразовій VM, а питання вибору ресурсів — у запуск coding agent на VPS.

Самостійне розгортання моделі. Це єдиний засіб контролю, який усуває inference flow, оскільки prompt ніколи не залишає ваше обладнання. Ціна цього підходу суттєва: закриту модель не можна розгорнути самостійно, тому доведеться вибрати open weights, прийняти відставання за можливостями на складних завданнях і забезпечити обладнання для їх обслуговування. Компроміси розглянуто в матеріалі чи можна самостійно розгорнути Claude, а відмінності за можливостями між основними агентами — у чим відрізняються Claude Code, Cursor, Codex і Copilot.

Жоден із цих чотирьох засобів контролю не змінює того, що агент може читати на диску, а inference traffic містить усе, що він прочитав. Якщо файл .env розташований у робочому каталозі, він потрапить до моделі в момент, коли агент виконає grep за назвою змінної. Окремо потрібно не допускати доступу до таких даних. Це питання розглянуто в матеріалі як не допустити потрапляння секретів у контекст AI-агента.

Що перевіряти після кожного оновлення

1. Порівняйте сторінки постачальника з описом налаштувань і використання даних із тим, що ви зафіксували минулого разу. Шукайте нові перемикачі та нові іменовані сервіси.
2. Повторно прочитайте середовище процесу з /proc/<pid>/environ, щоб підтвердити, що ваші параметри відмови від збору даних і далі застосовуються до запущеного процесу.
3. Знову виведіть файли налаштувань проєкту, оскільки git pull може підключити файл конфігурації, який змінив колега.
4. Виконайте захоплення SNI протягом одного повного сеансу реальної роботи та порівняйте список імен хостів із попереднім.
5. Перевірте лічильник відкинутих пакетів у firewall, оскільки нове призначення зазвичай з’являється там раніше, ніж ви помітите його деінде.

Це займає близько десяти хвилин і єдиний етап процесу, результати якого не втрачають актуальності. Параметр за замовчуванням, перевірений у серпні 2026 року, є фактом про серпень 2026 року. Захоплення трафіку є фактом про сьогоднішній день.

FAQ

Чи можна заборонити coding agent надсилати мій код моделі?

Ні. Будь-яке налаштування, яке стверджує протилежне, описує інший механізм. Надсилання prompt, файлів, які прочитав agent, і результатів виконаних ним команд на endpoint моделі — це спосіб, у який працює inference. Отже, змінити можна лише отримувача. Ви можете змінити отримувача, підключивши agent до корпоративного cloud account або до моделі, яку розгорнули самостійно. Також можна зменшити обсяг даних, які він надсилає, обмеживши доступні для читання файли. Вимкнення analytics і error reporting не впливає на цей потік даних.

Як дізнатися, до яких хостів підключається мій coding agent?

Запустіть agent від імені окремого користувача 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, оскільки локальна resolver stub-служба на 127.0.0.53 спочатку обробляє цей запит. Виконуйте перехоплення, коли agent справді працює, оскільки startup pings і crash reports не з’являються під час перехоплення в режимі простою.

У моєму proxy немає traffic, хоча agent працює. Що сталося?

Або клієнт ігнорує HTTP_PROXY та HTTPS_PROXY, або він закріплює сертифікати й відхиляє ваш CA. Спочатку перевірте маршрут за допомогою curl: якщо curl виходить в інтернет через proxy, а agent не з’являється у списку потоків, agent не використовує proxy environment variables. Деяким runtime потрібен CA, переданий у певний спосіб. Зокрема, Node читає NODE_EXTRA_CA_CERTS лише під час запуску процесу, тому експорт цієї змінної після запуску agent нічого не змінить. Якщо proxy не бачить traffic, використовуйте packet capture, оскільки жодне налаштування застосунку не може обійти його.

Чи припиняє вимкнення telemetry використання мого коду для training?

Ні. Analytics і crash reporting — це інший потік даних, ніж inference. Тому їх вимкнення прибирає лічильники використання та stack traces, але всі prompt і надалі надходять до моделі так само. Те, чи зберігаються ці prompt і чи використовуються вони для training майбутньої моделі, визначається умовами вашого plan. Умови consumer plans і commercial plans зазвичай відрізняються. Це питання умов договору, а не packet capture. Перевірте сторінку data usage для вашого plan і, якщо це важливо, укладіть commercial або zero-retention agreement до початку першої сесії.