Context isolation і worktree isolation

1. Після tools і scoped knowledge залишається питання середовища

Коли ви вперше чуєте про ізоляцію, легко вирішити, що це просто «ще одне налаштування безпеки». На практиці вона потрібна вже після того, як ви звузили агенту і права, і контур знань. Навіть ідеально обмежений за правами агент зіпсує вам роботу двома способами. Або завалить основну сесію проміжними читаннями, grep-виводом і логами. Або почне писати в те саме робоче дерево, де ви вже правите файли вручну.

Уявіть, що основна сесія — це ваш робочий стіл. Ви дали колезі завдання: «Перевір, як у Commerce OS влаштовано refund flow». Повернувся з короткою зведеною інформацією та трьома посиланнями — щастя. Притягнув на стіл весь архів відділу за три роки — уже не робочий стіл, а документальний серіал. Це проблема без context isolation.

З worktree історія інша. Агент зразково лаконічний у контексті, але пише код у тому самому checkout, де ви ведете свої зміни — і diff розпухає, незрозуміло, де ваші правки, де агентські, а git status дивиться на вас докірливо. Ізоляція захищає не думки, а файли.

Корисно тримати різницю перед очима:

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

2. Context isolation: захищаємо хід думки сесії

Ця ізоляція здається менш відчутною, ніж окрема гілка, але на практиці рятує частіше, ніж можна подумати. Щойно агент читає десятки файлів, збирає stack trace, порівнює тести й логи, ризик зміщується: не код зашкодить, а втопить основну сесію в подробицях.

Context isolation — це коли підзадача переходить в окреме контекстне вікно. Найчастіше subagent зі своєю робочою пам’яттю: читає файли, аналізує, а в основну сесію повертає лише коротку зведену інформацію. Не весь маршрут міркування, не двадцять шматків grep-виводу, не пів коду з трьох пакетів — короткий результат із опорою на evidence.

На прикладі Workflow Kit це добре видно на agents/tester.md. Іноді потрібен не основний робочий tester, який пише test-файли, а вузький read-only варіант для розвідки. Припустімо, ви розслідуєте дивну поведінку refund flow у Commerce OS: які тести є, а яких немає. Правити нічого — пройтися по support/, payments/, orders/, знайти тестові класи, подивитися прогалини в regression, повернутися з компактною зведеною інформацією. Investigation-only варіант:

---
name: tester
description: Аналізує прогалини в тестах refund flow і не змінює production-код
tools:
  - Read
  - Grep
  - Bash
# read-only investigation variant: тут tester лише збирає evidence
---

Тут важливо не лише те, що в агента немає Edit. Важливо і те, що ви використовуєте його саме як ізольованого дослідника: основна сесія не повинна бачити все, що він читав дорогою. Їй потрібен результат на кшталт «Знайшов три набори тестів, немає regression check на partial refund, імовірна точка додавання тесту — RefundPolicyServiceTest». Вивантажити в основну сесію пʼять екранів проміжних нотаток — означає зробити context isolation і тут же власноруч її скасувати.

Гарний практичний орієнтир такий: ізоляція потрібна, коли агент багато читає, порівнює і фільтрує, а ви хочете зберегти головну сесію чистою. Особливо для дослідження архітектури, пошуку прогалин у тестах, перевірки чутливих зон безпеки, аналізу логів або документації. Але не перестарайтеся: один test file і один service class окремого subagent не варті.

Є і ще одна тонка помилка: «Раз агент працював в окремому вікні, результату можна довіряти більше». Ні. Context isolation захищає чистоту основної сесії, але не коректність висновку. Агент як і раніше помиляється і пропускає файли. Ізоляція тут — хороший архіваріус: приносить документи на стіл, але не підписує за вас висновки.

3. Worktree isolation: захищаємо файли і чистоту diff

Тепер переключімося на більш відчутну річ. Буває, що проблема зовсім не в шумі контексту. Агент лаконічний і дисциплінований, але йому дозволили правити — і він пише в той самий checkout, де ви працюєте. Починаються питання «а це чиї зміни?» і «чому тестовий фікс зачепив сусідній модуль?».

Worktree isolation — ізоляція на рівні Git і файлової системи. Ви створюєте окреме робоче дерево — окремий каталог під своєю гілкою — і запускаєте там окрему сесію Claude Code. Головна думка проста: ризиковані, експериментальні або паралельні правки не повинні рости в тому самому каталозі, де ваш основний diff.

У Git це виглядає дуже приземлено:

git worktree add ../commerce-os-refund-lab -b exp/refund-rules
cd ../commerce-os-refund-lab
git status   # переконуємося, що ми в окремій гілці та робоче дерево чисте
claude       # запускаємо окрему сесію в ізольованому каталозі

Git-команди стабільні самі по собі, а опції запуску Claude Code, пов’язані з агентами або worktree-режимами, між версіями можуть відрізнятися. Принцип важливіший: окремий каталог, окрема гілка, окрема сесія.

Навіщо це потрібно на практиці? Уявіть той самий Commerce OS. Проблема, можливо, в логіці partial refund, і ви хочете спробувати два варіанти: виправити умову в RefundPolicyService або спочатку написати regression test і подивитися, на чому він падає. В основному checkout це перетвориться на загальну грудку змін. Коли кожен експеримент живе в окремому worktree, усе керовано: порівняти дифи, запустити тести окремо, викинути невдалу гілку без болю.

Це особливо корисно для agents/tester.md, коли ви дозволяєте йому правити тести. Нехай tester пише лише в tests/ — уже непогано. Але безпечніше дати йому окреме worktree: його помилкова спроба не переплутається з вашими ручними правками.

При цьому worktree isolation — не магія і не індульгенція. Окреме дерево не робить поганий diff хорошим, не замінює review, не запускає тести. Воно робить експеримент дешевшим і чистішим: правка невдала — видаляєте worktree, а основний checkout залишається в стані «нічого страшного не сталося». Але не перетворюйте його на ритуал на кожен чхі: для правки в одному файлі окремий каталог — чистий overhead. Бачите ризик наперед — окупається.

4. Вибір: context, worktree isolation або одразу обидві

Після знайомства з обома ізоляціями хочеться поставити найпрактичніше запитання: що брати в реальній задачі? Гарна новина в тому, що вибір зводиться не до абстрактної «складності», а до двох простих запитань. Агент багато читатиме без правок? Context isolation. Будуть правки, особливо експериментальні або паралельні? Worktree isolation. Часто спочатку потрібен широкий аналіз, потім акуратний експеримент: subagent в окремому вікні знаходить проблему, а окрема сесія в окремому worktree пробує правки. Захищені і голова основної сесії, і чистота файлів.

Для швидкого вибору зручно дивитися на ситуацію так:

Тут корисно пам’ятати, що ізоляція — не ознака «просунутості». Іноді найпрофесійніший вибір — не вмикати її: задача коротка, scope зрозумілий, diff маленький — один Claude в одній сесії найкраще.

5. Скрізний сценарій: Workflow Kit і Commerce OS

Щоб усе це не залишилося красивою теорією, давайте зберемо цілісну картину. У вас Workflow Kit із agents/tester.md і Commerce OS із проблемою refund flow: скарга в issue звучить так — «після partial refund система інколи рахує eligibility неправильно, а regression test цього не ловить». Завдання, де одна ізоляція неминуче тягне другу.

Спочатку ви залишаєте основну сесію в ролі координатора. Ви делегуєте tester-агенту read-only дослідження: пройти по payments/, support/ і test-пакетах, знайти перевірки, вказати прогалини, повернути коротку зведену інформацію з файлами. Це context isolation. Головна сесія не бачить шуму пошуку, але отримує висновок: regression coverage відсутнє навколо сценарію partial refund після manual approval.

Після цього стає ясно, що одного читання мало — потрібно додати regression test і подивитися, де падає логіка. Ось тут підключається worktree isolation: окреме дерево, окрема сесія, tester-агент додає test-файл, за потреби править test fixtures, запускає локальні перевірки. Основний checkout чистий. Експеримент поганий — закриваєте гілку і видаляєте worktree. Хороший — порівнюєте diff, переносите тільки потрібне.

Схема виходить дуже зрозумілою:

Основна сесія
   ├─ context isolation → агент читає код і тести, повертає коротку зведену інформацію
   └─ worktree isolation → окрема сесія пробує правки і запускає тести

Зверніть увагу, як красиво тут розподіляються ролі. Workflow Kit дає reusable artifact — agents/tester.md, Commerce OS — реальне інженерне завдання. Доросла інженерна звичка: спочатку зрозуміти, що саме ви хочете захистити, потім обрати межу.

Саме тому дві ізоляції не можна змішувати в одну абстрактну тему «про безпеку». Context isolation відповідає: як не втопити основну сесію в деталях. Worktree isolation: як не перетворити основний checkout на експериментальний полігон. Поки ви не розрізняєте ці болі, вибір ізоляції — гадання: вмикаєте «про всяк випадок» або не вмикаєте зовсім. Щойно називаєте те, що треба захистити, своїм іменем — засмічується контекст або плутається diff, — межа обирається сама, а потрібну ізоляцію ви ставите рівно там, де вона окупається.