Две Claude Code сессии на одном ПК могут остановить друг друга

Самостоятельная реакция Claude Code не равна согласованной работе

На одном ПК были запущены 2 разные CLI-сессии Claude Code. Они столкнулись с взаимной блокировкой. Важная деталь в том, что отдельной команды разбираться с этим конфликтом не было: каждая сессия сама обнаружила проблему, сама написала необходимое и сама пыталась принять решение.

Это выглядит как сильный сдвиг в поведении инструмента. Claude Code может применить подходящую функцию по ситуации, а не только после прямого указания. Но здесь же виден предел: сессии не смогли договориться друг с другом.

Автономность без общих правил быстро превращается в спор двух исполнителей за один ресурс.

Не стоит читать этот случай как подтверждение встроенного общения между разными CLI-сессиями. Наблюдение другое: движок самостоятельно начал использовать доступную функцию в возникшей ситуации. Сама эта функция не новая. Новым и неожиданным оказалось её самостоятельное применение.

Блокировка защищает ресурс, но создаёт конфликт без контекста

Блокировки нужны не для красоты. Они не дают двум параллельным процессам одновременно менять один и тот же ресурс. Но 2 сессии, работающие на одном компьютере, могут увидеть этот защитный механизм с разных сторон: одна ждёт освобождения ресурса, другая делает то же самое или пытается решить проблему своим способом.

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

Польза от такого разбора практическая. Он помогает заранее увидеть источник простоя: проблема может быть не в качестве задачи и не в ошибке модели. Иногда она в том, что несколько агентов получили доступ к пересекающейся работе, но не получили общего правила приоритета и границ.

Здесь легко обжечься на неверном ожидании: если сессия нашла блокировку и попыталась с ней работать, это ещё не значит, что ей можно поручить координацию всех остальных сессий. Она умеет реагировать на локальную ситуацию. Кто владеет ресурсом, кто ждёт, кому уступать и когда прекращать попытки - такие правила должны быть определены до запуска.

Локальная работа требует отдельного правила блокировки

Намеченное решение - добавить правило в репозиторий. Помимо блокировки на продакшене, в нём предполагается использовать блокировку потока на локальном ПК. Локальная блокировка здесь нужна для того, чтобы несколько сессий не входили в конфликт при работе в одном окружении.

Это полезно именно потому, что продакшен и локальная машина - разные контексты. Наличие защиты на продакшене не означает, что 2 локальных процесса уже не пересекутся. Если разработчик запускает несколько CLI-сессий, локальный конфликт появляется раньше, чем изменения попадут дальше.

Запись в правилах должна быть короткой и однозначной. Сессиям нельзя оставлять простор для трактовки того, что считать общим ресурсом и что делать при занятом ресурсе. Например:

Это не универсальная техническая инструкция для любой среды. В исходной ситуации сказано только о намерении добавить тред-лок на локальном ПК наряду с локом на продакшене. Конкретный механизм, область блокировки и способ его настройки нужно сверять с тем, как устроен ваш репозиторий и запуск Claude Code.

Человек остаётся оператором параллельной работы

Самый ценный сигнал в этом случае не в том, что Claude Code нашёл проблему. Он в том, что без вмешательства 2 самостоятельные сессии не пришли к общей договорённости. Человеку пришлось вручную развести их, чтобы они перестали конфликтовать.

Для небольшой команды это означает простое правило: прежде чем увеличивать число параллельных сессий, надо описать их границы. Какие файлы, процессы или задачи может брать каждая? Что считается занятым ресурсом? Что делать при блокировке? Когда сессия должна остановиться, а не продолжать искать обходной путь?

Одна сессия на ресурс - самый понятный режим для задач с пересечением.

Явное разделение зон - разным сессиям заранее назначают непересекающиеся части работы.

Правило остановки - при занятом ресурсе сессия ждёт или завершает попытку, а не начинает параллельные действия.

Для фиксации таких правил в рабочем контуре можно использовать ATLAS PANEL: главное, чтобы правило было видно всем, кто запускает параллельную работу.