Як запускати кілька агентів Claude Code одночасно й не ловити конфлікти файлів

Коротко (TL;DR)

Коли ви запускаєте двох ШІ-агентів на одному проєкті, вони працюють в одній теці й починають затирати правки одне одного. git worktree розв’язує цю проблему на рівні файлів: кожен агент отримує окрему робочу копію репозиторію зі своєю гілкою, але зі спільною історією комітів. Жодного другого git clone і дублювання всієї історії.

Що важливо знати одразу:

• У Claude Code є два рівні цієї ізоляції: прапорець --worktree для цілої сесії, яку ви запускаєте руками, і поле isolation: worktree для субагента, якого Claude делегує сам. Розгалужуються вони однаково (від дефолтної гілки), а різняться зоною дії й тим, як прибираються, — і цю різницю варто розуміти, щоб не втратити роботу під час автоочищення.
• Комфортна межа — 3–5 паралельних worktree. Саме це називає «найпотужнішим апгрейдом продуктивності» один зі співтворців Claude Code Борис Черні (допис у X від 31 січня 2026).
• worktree прибирає файлові перегони на диску, але не скасовує конфлікти злиття: якщо дві гілки правили один файл, конфлікт усе одно спливе під час git merge — просто пізніше й усвідомлено.
• Що знадобиться: git версії 2.5+ (worktree в ньому з 2015 року), Claude Code з нативною підтримкою --worktree (з’явилася з початку 2026 року) і дисципліна щодо меж завдань.

Далі — як це влаштовано, точні команди, карта автоочищення й розбір ризиків (зокрема реальний кейс, де 50 worktree з’їли 10 ГБ оперативної пам’яті).

Навіщо взагалі паралельні агенти

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

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

Проблема в тому, що за замовчуванням усі вони працюють в одному каталозі. Один персональний агент (наприклад, OpenClaw) живе в одній робочій теці — і цього досить. Але щойно агентів стає двоє й більше, вони починають писати в одні й ті самі файли: поки перший зберігає package.json, другий його перезаписує. Git бачить хаос зі змішаних змін, а ви — зламану збірку.

Visa нацькувала Claude Mythos на власну платіжну мережу — і виклала обв’язку, яка це зробила

Генератор проти критика: як кілька ШІ ловлять баги, що пропускає один

«Готово» — це оцінка агента чи перевірки? TDD та eval-driven розробка зі ШІ

П’ять периметрів безпеки Claude Code: що реально налаштувати, а що вас здивує

Claude Code без інтерфейсу: headless-режим, Agent SDK і підводні камені автоматизації

Є три способи розвести агентів фізично:

1. Кілька клонів репозиторію — робоче, але важке: кожен клон тягне всю історію заново, займає диск і живе своїм життям (свої remote, свої налаштування).
2. Гілки в одній теці — не допомагає: в один момент часу в робочому каталозі може бути викачана лише одна гілка. Перемикання гілки зачіпає всіх.
3. git worktree — золота середина: окремі робочі теки з різними гілками, але одна спільна історія й один .git.

Третій варіант і став індустріальним стандартом для роботи з флотом ШІ-агентів.

Типовий розклад має такий вигляд. Ви відкриваєте три worktree: у першому агент переписує модуль авторизації, у другому — додає пошук, у третьому сидить «спостерігач», який читає логи й не має права комітити. Усі троє працюють з одним проєктом, але кожен — у своїй теці й на своїй гілці. Поки вони працюють, ви робите рев’ю готових шматків, а не чекаєте, доки один агент звільнить файл для іншого. Саме ця одночасність і дає виграш за часом — за умови, що завдання справді незалежні (до меж завдань ще повернемося, це ключовий нюанс).

Що таке git worktree простими словами

git worktree — це окрема робоча директорія зі своїми файлами та своєю гілкою, яка ділить історію комітів, об’єкти й remote з основним репозиторієм. По суті ви отримуєте другий (третій, п’ятий) «стіл» для роботи над тим самим проєктом, не копіюючи проєкт цілком.

Відмінність від git clone принципова: клон дублює весь .git (історію, об’єкти), а worktree його перевикористовує. Тому створення worktree — майже миттєве й дешеве за диском (дублюється лише робочий чекаут файлів, не історія). Є й приємний побічний ефект: коміт, зроблений в одному worktree, одразу видно рештою як частину спільної історії — не треба нічого пушити й підтягувати між локальними копіями, як було б із кількома клонами.

Що знадобиться. git із підтримкою worktree — вона вбудована починаючи з версії 2.5 (2015 рік), тож на будь-якій актуальній системі все вже є; перевірити можна командою git --version. Плюс Claude Code з нативною підтримкою прапорця --worktree (з’явилася з початку 2026 року) — якщо прапорець не спрацьовує, оновіть CLI. Усе інше — звичайні git-команди, які ви й так знаєте.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Базові команди, які варто знати:

Ці чотири команди покривають 90% щоденної роботи. Усе інше — надбудова, яку Claude Code робить за вас.

Два рівні ізоляції в Claude Code

У Claude Code worktree-ізоляція працює на двох рівнях, і їх корисно не плутати.

Рівень 1 — ціла сесія (--worktree / -w). Ви запускаєте Claude Code з прапорцем --worktree, і він створює ізольований worktree та стартує сесію просто в ньому. За замовчуванням worktree створюється в .claude/worktrees/<ім'я>/ у корені репозиторію, на новій гілці worktree-<ім'я>. Якщо ім’я не задати, генерується випадкове (на кшталт bright-running-fox). Таку сесію ви заводите й закриваєте самі — вона запускає свій екземпляр Claude Code, наприклад на моделі Claude Sonnet 5, незалежно від решти.

Рівень 2 — окремий субагент (isolation: worktree). У frontmatter кастомного субагента можна прописати поле isolation: worktree. Тоді субагента, якого Claude делегує сам під час вашої сесії, він запускає в тимчасовому worktree — ізольованій копії репозиторію. Якщо субагент не вніс змін, його worktree видаляється автоматично.

Чим ці рівні реально різняться — не базою розгалуження (вона в них спільна), а зоною дії та очищенням:

• Зона дії. --worktree — окрема сесія, яку ви запускаєте вручну під конкретне завдання. isolation: worktree — субагент, якого Claude піднімає автоматично всередині роботи.
• Очищення. worktree, створені руками через --worktree, автоприбирання не чіпає — за ними стежите ви. А worktree субагентів і фонових сесій прибираються автоматично за віком (cleanupPeriodDays), якщо в них немає незбережених змін.

А ось де рівні поводяться ОДНАКОВО — і це теж варто знати. Обидва розгалужуються від дефолтної гілки репозиторію (origin/HEAD), а не від поточного стану (HEAD) вашої сесії. Якщо хочете, щоб worktree відгалужувався від локального HEAD з усіма вашими напрацюваннями, це змінюється одним глобальним налаштуванням — worktree.baseRef: "head" — і воно діє одразу на обидва рівні.

Чому це важливо на практиці. Ви в основній сесії накидали нову функцію, але не закомітили її. Запускаєте субагента (або нову --worktree-сесію), щоб написати тести. За замовчуванням він стартує від дефолтної гілки й вашу незбережену функцію просто не побачить — тести вийдуть «у порожнечу». Рішень два: закомітити напрацювання перед запуском або виставити worktree.baseRef: "head", щоб відгалуження йшло від поточного стану. Розуміння цієї розвилки заощаджує годину спантеличеного дебагу — а більшість вторинних гайдів її взагалі не згадують.

Чотири сценарії, де це справді потрібно

worktree виправданий не завжди — накладні витрати на координацію зростають із кількістю гілок. Ось чотири ситуації, де виграш очевидний, з прив’язкою до команд:

Пара уточнень щодо сценаріїв. Міграції — найочевидніший виграш: велике оновлення легко ламає збірку на пів дня, і тримати його осторонь від основної роботи просто безпечніше. Паралельні фічі виправдані лише тоді, коли вони реально незалежні — якщо обидві чіпають один і той самий шар (спільний роутер, спільний стор), виграш від worktree з’їдається конфліктами на злитті. Аудити й A/B-підходи — недооцінені сценарії: worktree коштує майже нічого, тому «прогнати завдання двома способами й порівняти дифи» перестає бути розкішшю.

Окремо відзначимо прийом, який рідко трапляється в англомовних посібниках: тримати один worktree як аналітичний, лише для читання — агент у ньому дивиться логи й запити до бази, але не має права комітити. Так ви отримуєте «спостерігача», який не бере участі в перегонах правок, але при цьому бачить актуальний стан проєкту.

Що прибирається саме, а що ні

Фраза «worktree чистяться самі» — напівправда. Насправді є чотири різні результати, і їх корисно розрізняти:

Налаштування cleanupPeriodDays керує тим, через скільки днів автоприбирання прибирає worktree субагентів і фонових сесій (за умови, що там немає незакомічених змін, untracked-файлів і незапушених комітів). Якщо ви ганяєте багато коротких субагентів, короткий період тримає диск у чистоті; якщо worktree живуть довго і ви до них повертаєтеся — період варто збільшити, щоб система не видалила те, що вам ще потрібно. Важливий нюанс: це прибирання не чіпає worktree, які ви створили руками через --worktree, — за ними ви стежите самі.

Поки агент працює, Claude Code виконує git worktree lock на його worktree, щоб паралельне очищення не знесло активну роботу; блокування знімається після завершення агента. Забутий worktree, який прибирання «щадить», прибирається вручну: git worktree remove <шлях>, а якщо там є незбережені зміни — із прапорцем --force (він безповоротно відкидає ці зміни, тож спершу перевірте, що там).

Практика: команди, .env і типові граблі

Кілька речей, на яких спотикаються навіть досвідчені розробники.

Одна гілка = один worktree. Git не дасть викачати одну й ту саму гілку у два worktree одразу. Спроба поверне помилку fatal: '<branch>' is already checked out at <path>. Це захист від того, щоб ви випадково не розсинхронізували стан гілки.

Файл .env не переїде сам. worktree — це свіжий чекаут, тому гітігноровані файли (.env, .env.local) у ньому відсутні. Щоб Claude Code копіював їх під час створення worktree, додайте в корінь проєкту файл .worktreeinclude — синтаксис як у .gitignore. Копіюються лише ті файли, які збігаються з патерном І при цьому гітігноровані; відстежувані файли не дублюються ніколи.

node_modules не шаряться. Кожен worktree ділить package.json зі спільного репозиторію, але має свою теку node_modules. Отже, npm install (чи його аналог) треба прогнати в кожному worktree окремо. Це ж — джерело головного ризику за ресурсами, про який нижче.

Не лише git. Якщо ви на SVN, Perforce чи Mercurial, worktree-ізоляцію налаштовують через хуки WorktreeCreate і WorktreeRemove. Хук WorktreeCreate повністю замінює дефолтну git-логіку (зокрема вимикає обробку .worktreeinclude), а WorktreeRemove відповідає за очищення на завершенні сесії.

Лайфхак від команди Claude Code — короткі shell-аліаси (za, zb, zc) для миттєвого перемикання між кількома worktree. Коли їх 3–5, стрибати між повними шляхами руками втомливо.

Стратегія злиття: як не потонути в конфліктах

Коли три worktree готові й час збирати все в main, спокуса «злити все разом» закінчується кашею з конфліктів. Практика команд, що працюють із флотом агентів, — послідовне злиття з ребейзом:

1. Злийте першу гілку як завжди: git checkout main && git merge feature-auth.
2. Перед злиттям другої гілки переведіть її на свіжий main: git checkout feature-search && git rebase main. Тепер друга фіча бачить уже влиту першу, і конфлікти (якщо вони є) ви розв’язуєте тут — в ізоляції однієї гілки, а не всіх одразу.
3. Злийте другу: git checkout main && git merge feature-search. Повторіть для решти.

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

Екосистема інструментів

Навколо worktree виросла ціла обв’язка. На момент написання (липень 2026) російськомовний огляд на Habr порівнює шість інструментів-надбудов: CCManager, Claude Squad, Crystal, Auto-Claude, Conductor і Cursor 2.0. Усі вони — термінальні чи графічні обгортки поверх того самого примітиву: створюють worktree, запускають у кожному свою сесію й дають єдиний дашборд для моніторингу флоту агентів.

Різниця між ними здебільшого в інтерфейсі: одні (CCManager, Claude Squad) — термінальні й зручні тим, хто живе в консолі; інші (Crystal, Conductor) дають графічний дашборд зі списком активних агентів та їхніми статусами. Але обирати інструмент до того, як ви зрозуміли базовий механізм, — шлях до магічного мислення «воно саме розрулить».

Важливе застереження: список таких інструментів швидко застаріває, тому сприймайте його як контекст, а не як рейтинг «найкращих». Базовий механізм під усіма ними один — git worktree, і розуміння саме його переживе будь-яку конкретну обгортку.

Ризики й слабкі місця

У worktree є ціна — ось із чого вона складається.

Роздування RAM і диска. Головний практичний ризик — накопичення. Реальний кейс із соцмереж (X, 11 липня 2026): одне вікно VS Code тихо з’їдало 10 ГБ оперативної пам’яті. Причина — 50 накопичених worktree, 45 з яких мали власні node_modules, і всі вони індексувалися файловим watcher-ом редактора. Це поодинокий приклад, не статистична норма, але механізм реальний: кожен worktree зі своїми залежностями — це ще один каталог, який хтось моніторить. Звідси практичне правило: тримати не більше ніж 5 активних worktree й видаляти ті, що відпрацювали.

Конфлікти злиття не зникають, а відкладаються. Це ключове переформулювання, яке багато матеріалів проминають. worktree захищає від того, щоб два агенти одночасно топтали один файл на диску. Але якщо дві гілки правили один і той самий файл, конфлікт спливе в момент git merge — рівно так само, як за звичайної роботи з гілками. worktree лише переносить момент зіткнення на злиття, де його можна розв’язати усвідомлено. Як саме збирати гілки, щоб конфлікти не навалювалися разом, — у розділі про стратегію злиття вище.

Дисципліна завдань важливіша за інструмент. Проблеми починаються, коли обидва агенти лізуть у спільні файли — package.json, конфігурацію, shared-утиліти. worktree тут не врятує: ізоляція файлів не задає межі завдань. Їх задаєте ви — явним формулюванням, що кожному агенту можна чіпати, а що ні. На практиці це один-два рядки в завданні: «працюй лише всередині src/auth/, не міняй спільні утиліти й конфіги; якщо потрібна правка поза цією текою — спершу спитай». Така рамка коштує десяти хвилин, але заощаджує години розбору конфліктів, коли два агенти незалежно переписали один і той самий спільний модуль. Що більший проєкт і що більше в ньому shared-коду, то важливіше розводити агентів не лише за worktree, а й за зонами відповідальності.

Типові граблі, якщо зібрати в список:

1. Запуск агентів в одній директорії замість окремих worktree.
2. Спільний закомічений .env замість .env.local під кожен worktree.
3. Відсутність явних меж завдання — агент лізе у спільні утиліти й конфіги.
4. Злиття без рев’ю дифа.
5. Забуті чи конфліктні міграції бази під час паралельної зміни схеми.

Варто тримати в голові й системне обмеження, про яке говорять у спільноті: worktree ізолює лише файловий чекаут, але нічого не знає про решту контексту завдання — залежності, чекпоінти, стан рев’ю. Це не баг, а межа інструмента: він розв’язує одну проблему (файлові перегони) добре, а решту координації лишає вам.

FAQ

Скільки worktree — це нормально? Комфортна межа для більшості — 3–5 активних worktree одночасно. Далі накладні витрати на координацію й рев’ю починають з’їдати виграш у швидкості. Технічного ліміту немає, але 5 — розумна стеля і з погляду ресурсів.

Що робити із забутим worktree? Спершу подивіться список: git worktree list. Непотрібний видаліть через git worktree remove <шлях>; якщо там лишилися незбережені зміни і вони вам не потрібні — додайте --force. Якщо теку worktree ви вже знесли вручну, підчистіть записи командою git worktree prune.

А якщо в мене не git, а Mercurial чи SVN? Механізм git worktree працює лише з git. Для SVN, Perforce і Mercurial ізоляцію налаштовують через хуки Claude Code WorktreeCreate і WorktreeRemove — вони задають свою логіку створення й очищення робочих копій.

Чи потрібен worktree, якщо в мене лише один агент? Ні. Для однієї сесії досить звичайної роботи в основному каталозі — worktree розв’язує проблему саме паралельної роботи кількох агентів на одному репозиторії. Якщо паралельності немає, ви просто додасте собі зайвий шар керування теками.

Чим worktree кращий за кілька клонів репозиторію? Кілька клонів теж розводять агентів по різних теках, але кожен клон дублює всю історію комітів та об’єкти, займає більше диска й живе окремим життям — зі своїми remote й налаштуваннями, між якими доводиться пушити й підтягувати зміни. worktree перевикористовує один спільний .git, тому створюється миттєво, важить менше, а коміти одразу видно в усіх робочих копіях. Для паралельної роботи над одним проєктом це помітно зручніше.

Як зрозуміти, у якому worktree я зараз перебуваю? Команда git worktree list показує всі робочі копії, їхні шляхи й викачані гілки — поточну позначено у виводі. Це ж перший крок, коли треба навести лад: спершу дивимося список, потім видаляємо зайве через git worktree remove.

Чи правда, що worktree прибирає конфлікти? Ні, і це часта хибна думка. worktree прибирає одночасний запис в один файл на диску, але конфлікти гілок під час злиття лишаються такими самими, як завжди. worktree відкладає конфлікт до git merge, а не усуває його.