VS Code 1.119: playbook для безпечніших AI-агентів у команді

VS Code 1.119 вийшов 6 травня 2026 і помітно підкрутив не сам чат, а робочий контур навколо нього. AI-агент тепер краще взаємодіє з інтегрованим браузером, може віддавати OpenTelemetry-сигнали, а команди отримують точніші важелі безпеки.

Це не реліз із серії «нова кнопка, забудьте завтра». Якщо команда вже пробує agentic coding, саме такі дрібні на вигляд зміни вирішують, чи буде агент корисним інженером у парі, чи генератором хаотичних diff-ів.

Що змінилося

У релізі 1.119 Microsoft виділяє три практичні напрямки для agent workflow.

По-перше, browser tabs можна явно шарити агенту. Агент не отримує доступ до інтегрованого браузера автоматично. Сторінку треба прикріпити як контекст або перевести в sharing state через кнопку в browser tab. Це важлива межа: агент бачить саме те, що ти йому дав, а не весь твій браузерний світ.

По-друге, Copilot Chat agent sessions можуть експортувати OpenTelemetry. У трейсах видно LLM-виклики, tool calls, latency, token usage і вкладені кроки. Для довших агентних сесій це майже як лог польоту: можна зрозуміти, чому агент застряг, де витратив токени і який інструмент дав помилку.

По-третє, змінилися control-и для sandbox і підтверджень. Зʼявився режим allowNetwork для chat.agent.sandbox.enabled: file system restrictions лишаються, але network domain blocking не заважає локальній розробці. Також VS Code менше перебиває сесію через тимчасові файли в /tmp або %TEMP%, якщо ти вже дозволив команди на час сесії.

Чому це важливо

Agentic coding найчастіше ламається не через «модель погана», а через слабко налаштовану петлю зворотного звʼязку.

Типовий сценарій: агент змінює React-компонент, не бачить сторінку, вигадує результат, просить пʼять дозволів поспіль, а потім команда не може відтворити, чому він викликав саме ці інструменти. У підсумку людина витрачає більше часу на контроль агента, ніж зекономила на автоматизації.

VS Code 1.119 допомагає скласти здоровіший цикл:

1. агент отримує доступ лише до потрібної сторінки;
2. він може перевірити результат у browser tab;
3. команда бачить trace сесії;
4. sandbox зменшує ризик випадкових дій;
5. підтвердження лишаються там, де справді є ризик.

Як налаштувати це в команді

Нижче — не повний огляд релізу, а короткий operational playbook. Його можна пройти за 30–40 хвилин на одному frontend або full-stack проєкті.

Крок 1. Визнач, які сторінки агент може бачити

Не починай з «дамо агенту браузер, бо так швидше». Почни зі списку дозволених URL.

Для локальної web-розробки нормальний стартовий набір виглядає так:

http://localhost:3000/*
http://localhost:5173/*
http://127.0.0.1:*/health

Сторінки з адмінками, billing, production-даними, особистою поштою, CRM або реальними customer records не треба шарити агенту за замовчуванням. Навіть якщо агент «тільки читає», він може використати побачений контекст у наступних діях.

У VS Code перевір browser tools у chat tools picker. Для web-перевірки агенту зазвичай потрібні інструменти на кшталт navigation, screenshot, read page і click/type actions. Але важливо, що сторінки агента запускаються в приватних in-memory sessions, якщо їх відкриває сам агент. Це зменшує ризик випадково віддати йому cookies з основного браузера.

Крок 2. Шарь browser tab тільки під конкретну задачу

Правило просте: одна задача — один мінімальний browser context.

Поганий prompt:

Перевір увесь сайт і поправ дизайн.

Краще:

Я прикріпив browser tab з http://localhost:5173/pricing.
Перевір тільки layout pricing cards на mobile width.
Не переходь у billing/admin/login.
Якщо треба інший URL — спочатку поясни навіщо.

Так агент має чітку межу: що дивитися, що не чіпати, коли питати дозвіл. Це зменшує шум і робить результат перевірюваним.

Крок 3. Увімкни OpenTelemetry для довших сесій

Якщо в команди вже є OTel backend, VS Code 1.119 дає нормальний спосіб бачити agent session зсередини.

Мінімальний варіант через settings:

{
  "github.copilot.chat.otel.enabled": true,
  "github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"
}

Або через environment variables:

export COPILOT_OTEL_ENABLED=true
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
export OTEL_SERVICE_NAME=copilot-chat-dev

У trace ти шукаєш не «красивий графік», а практичні відповіді:

• який model реально викликався;
• скільки токенів зʼїла задача;
• які tools запускалися;
• де була найбільша latency;
• який tool call завершився error-ом;
• чи не було несподіваних зовнішніх звернень.

Обережно з COPILOT_OTEL_CAPTURE_CONTENT: повний контент prompt-ів і відповідей може містити секрети, фрагменти коду або customer data. Для більшості команд краще почати без capture content і збирати тільки метадані.

Крок 4. Вибери режим sandbox і network control

Тут головне не змішати два різні сценарії.

Сценарій А: строгий режим для чутливого проєкту

Вмикай sandbox і network filtering, а домени додавай явно:

{
  "chat.agent.sandbox.enabled": "on",
  "chat.agent.networkFilter": true,
  "chat.agent.allowedNetworkDomains": [
    "registry.npmjs.org",
    "api.github.com",
    "localhost"
  ]
}

Цей режим підходить для корпоративного коду, інтеграцій із production API або задач, де агент не має вільно ходити в інтернет.

Сценарій Б: швидкий локальний inner loop

Якщо агенту треба встановлювати пакети, запускати dev server, ходити до локальних API і не ламатися на кожному домені, можна використати allowNetwork:

{
  "chat.agent.sandbox.enabled": "allowNetwork"
}

У цьому режимі file system isolation лишається, але domain allowlist/denylist не контролює мережу. Це зручно для локальної розробки, але не треба вважати це «sandbox + строгий network filtering». Це інший компроміс.

Крок 5. Залиши важливі approvals живими

VS Code 1.119 зменшує approval fatigue для тимчасових файлів: якщо ти дозволив команди на час сесії, записи в /tmp або %TEMP% більше не мають постійно перебивати агентний цикл.

Але це не привід вимикати все підряд. Ручне підтвердження варто лишити для:

• команд, які пишуть поза workspace;
• доступу до production-доменів;
• операцій із секретами;
• git push, release, deploy, publish;
• масових змін у файлах конфігурації;
• запуску невідомих scripts із залежностей.

Ідея не в тому, щоб агент питав дозвіл на кожен подих. Ідея в тому, щоб він не міг непомітно зробити дорогий або небезпечний крок.

Командний workflow на кожну agent session

Ось простий шаблон, який можна додати в team README.

Перед сесією:

Task: що саме міняємо
Allowed browser tabs: список URL
Allowed network: список доменів або режим allowNetwork
Forbidden areas: production, billing, secrets, admin
Success check: як зрозуміти, що задача готова

Під час сесії:

• агент працює з одним конкретним scope;
• новий browser tab додається тільки після пояснення;
• shell commands не мають писати поза workspace без дозволу;
• якщо агент просить risky approval, людина читає команду повністю.

Після сесії:

• переглянути diff;
• прогнати тест або build;
• подивитися trace, якщо задача була довга;
• записати один висновок: що треба змінити в instructions або allowlist.

Це звучить бюрократично, але займає менше часу, ніж розбирати «чому агент видалив не той файл».

Що НЕ робити

Не шарь чутливі tabs “на хвилинку”. Якщо сторінка містить персональні дані, токени, billing або production controls — це не контекст для агента.

Не думай, що allowNetwork і domain allowlist працюють разом. У режимі allowNetwork мережеве блокування прибирається. Якщо потрібен строгий контроль доменів — використовуй інший режим.

Не збирай повний prompt content в OpenTelemetry без політики. Metadata корисна. Повні тексти можуть бути ризиком.

Не вмикай Bypass Approvals без sandbox або контейнера. Автономність без ізоляції — це швидко, поки не стане боляче.

Не оцінюй агента тільки за фінальною відповіддю. Дивись на tool calls, diff, тести й trace. Саме там видно реальну якість роботи.

Висновок

VS Code 1.119 робить AI-агентів не магічнішими, а керованішими. І це хороша новина: browser tabs дають агенту очі, OpenTelemetry дає команді памʼять, sandbox і approvals дають межі.

Швидкий план дій:

1. Створи список allowed browser tabs для локальної розробки.
2. Увімкни OTel export хоча б для довгих agent sessions.
3. Вибери один із двох режимів: строгий sandbox + network filtering або allowNetwork для локального inner loop.
4. Залиши approvals для production, secrets, deploy і записів поза workspace.
5. Після кожної складної сесії дивись не лише diff, а й trace.

Якщо команда зробить ці пʼять речей, агент перестане бути «чорною скринькою з правами на термінал» і стане нормальним інструментом у developer workflow.

Офіційні джерела:

• https://code.visualstudio.com/updates/v1_119
• https://code.visualstudio.com/docs/copilot/guides/browser-agent-testing-guide
• https://code.visualstudio.com/docs/copilot/guides/monitoring-agents
• https://code.visualstudio.com/docs/copilot/concepts/trust-and-safety#_agent-sandboxing
• https://code.visualstudio.com/docs/debugtest/integrated-browser