Claude Code получил локальную очередь слияний для агентов
На Show HN разработчик funador опубликовал claude-code-merge-queue, открытый (MIT) npm-пакет, который решает конкретную проблему: несколько агентов Claude Code одновременно вносят изменения, собирают и тестируют код в параллельных ветках, из-за чего возникают гонки при push, дублирующиеся тяжёлые сборки и падения тестов из-за общих ресурсов. Инструмент сериализует посадку изменений локально и бесплатно, без облачного сервиса, по словам автора, идея та же, что у GitHub Merge Queue, но выполняется на своей машине.
Установка, npm install --save-dev claude-code-merge-queue (или pnpm/yarn/bun), затем npx claude-code-merge-queue init. Инициализация сама определяет интеграционную ветку (по умолчанию main) и команду проверки (checkCommand), создаёт или дополняет файл CLAUDE.md с инструкцией для Claude Code сажать свою работу после зелёных проверок без дополнительного запроса, добавляет хук в .claude/settings.json, ставит pre-push хук Husky (или предупреждает, если Husky не установлен) и добавляет npm-скрипты land, sync, promote, preview, preview:restore. Вся конфигурация, один файл claude-code-merge-queue.config.mjs; каждой параллельной ветке (lane/1, lane/2...) присваивается своё рабочее дерево и свой порт (portBase + n).
Прямой git push в интеграционную ветку блокируется pre-push хуком, вместо него нужно вызывать land, который прогоняет checkCommand перед пропуском изменений; если команда проверки не задана, каждый push проваливается по умолчанию. Для форс-мажора предусмотрен обходной путь: переменная окружения CLAUDE_CODE_MERGE_QUEUE_EMERGENCY_PUSH=1 перед git push, без флагов и подтверждений.
Автор прямо перечисляет ограничения: инструмент не заменяет ревью человека, единственный гейт это прохождение checkCommand, и реальный тест-сьют внешне неотличим от echo ok; блокировки завязаны на живость процесса (PID), а не на таймаут, если процесс убит kill -9, следующий процесс сам заберёт освободившийся замок; очередь работает только на одной машине (локальное временное хранилище), для двух разных машин срабатывает обычный git-механизм non-fast-forward; это не средство безопасности, при наличии доступа к shell любой guardrail обходится через git push --no-verify или правку конфига; медленный checkCommand, реальный потолок пропускной способности (сьют на 3, 4 минуты держит меньше 20 посадок в час); конфликты при rebase не разрешаются автоматически, git rebase --abort прерывает операцию и оставляет рабочее дерево чистым, дальше CLAUDE.md инструктирует агента разрешить конфликт вручную и повторить land.
Ключевые факты
- npm-пакет claude-code-merge-queue (MIT) сериализует посадку изменений от параллельных агентов Claude Code, чтобы исключить гонки при push, дублирующиеся сборки и флаки из-за общих ресурсов
- Работает локально и бесплатно вместо облачного сервиса; идея повторяет GitHub Merge Queue
- init автоматически определяет интеграционную ветку и checkCommand, ставит pre-push хук, добавляет CLAUDE.md-инструкцию и npm-скрипты land/sync/promote/preview
- Единственный гейт, прохождение checkCommand, ревью человека нет; блокировки живут по PID, не по таймауту
- Ограничения: одна машина (не флот), не средство безопасности при доступе к shell, медленный checkCommand ограничивает пропускную способность до менее 20 посадок в час
Почему это важно
Когда несколько агентов Claude Code одновременно правят код в параллельных ветках, они сталкиваются с одной и той же проблемой: гонки при push в общую ветку, повторный запуск одинаковых тяжёлых сборок и падения тестов из-за конкуренции за общие ресурсы (порты, файлы блокировок и так далее). claude-code-merge-queue решает это не облачным сервисом, а локальной сериализацией, агент занимает очередь, проходит проверку и только тогда попадает в интеграционную ветку.
Кому это важно
Инструмент нацелен на разработчиков, которые запускают несколько параллельных агентов Claude Code (или похожих coding-агентов) над одной кодовой базой через git worktree, и хотят аналог GitHub Merge Queue без облачных расходов и без выноса координации на сторонний сервис.
Как это применить
Установка стандартная, npm install --save-dev claude-code-merge-queue (или pnpm/yarn/bun), затем npx claude-code-merge-queue init. Инициализация сама находит интеграционную ветку и checkCommand, дописывает CLAUDE.md с инструкцией сажать готовую работу без лишних вопросов, добавляет хук в .claude/settings.json, ставит pre-push хук Husky и npm-скрипты land, sync, promote, preview, preview:restore. Вся настройка, один конфиг-файл; для аварийного обхода блокировки есть переменная окружения CLAUDE_CODE_MERGE_QUEUE_EMERGENCY_PUSH=1.
Можно ли доверять
Материал, пост на Show HN от автора репозитория (funador), проект открыт под MIT-лицензией на GitHub. На момент публикации у поста 25 очков и 8 комментариев примерно за 5 часов, заметный, но нишевой интерес; независимой проверки надёжности или истории внедрения инструмента в статье нет.
Риски и подводные камни
Автор сам перечисляет границы инструмента: единственный гейт для посадки изменений, прохождение checkCommand, а настоящий тест-сьют внешне неотличим от заглушки вроде echo ok; блокировки основаны на живости процесса (PID), а не на таймауте; очередь работает только на одной машине, для нескольких машин срабатывает обычный git-механизм отказа при не-fast-forward push; это не средство безопасности, доступ к shell позволяет обойти любую защиту через git push --no-verify или правку конфига; медленный checkCommand (3, 4 минуты) ограничивает пропускную способность величиной меньше 20 посадок в час; конфликты при rebase не разрешаются автоматически, а прерывают операцию, оставляя рабочее дерево чистым для ручного разрешения.
«Это конвенция, а не жёсткая гарантия: она останавливает ошибки и случайные push, а не агента, который сам выставит эту переменную окружения.»
— из README проекта claude-code-merge-queue