Git worktree в Codex CLI: изолированные задачи без ручной рутины

Как быстро настроить git worktree

Понадобятся Codex CLI 0.154.0, локальный Git-репозиторий и включённая экспериментальная функция worktrees. Сначала проверьте версию — в более старой сборке нужного флага просто нет.

codex --version
npm install -g @openai/codex@0.154.0
codex features enable worktrees
codex features list

Команда постоянного включения сохраняет настройку функции в конфигурации Codex. Для разовой проверки конфигурацию можно не менять: просто добавьте --enable worktrees к конкретному запуску.

Теперь можно открыть новую изолированную сессию, запустить неинтерактивную задачу или ответвить уже начатый диалог:

codex --enable worktrees --worktree "Upgrade the test runner and run its suite"
codex exec --enable worktrees --worktree "Find the flaky test and propose the smallest fix"
codex fork --enable worktrees --worktree <session-id> "Try the lower-risk implementation"

Для интерактивного ответвления <session-id> — это идентификатор чата, который показывает /status. В версии 0.154.0 здесь обязательно нужно указать ID. Вариант codex fork --worktree --last не принимается.

Тот же сценарий доступен в терминальном интерфейсе. Введите /worktree, затем выберите: продолжить текущий диалог в новом рабочем дереве, начать там новый диалог или просмотреть рабочие деревья, которыми Codex уже управляет для этого репозитория.

Что создаёт Codex CLI worktree

Управляемый worktree — это вторая рабочая копия, привязанная к тому же Git-репозиторию. Представьте библиотечный каталог и два читальных зала: в каждом можно разложить свой набор страниц, но оба обращаются к одним и тем же коммитам и веткам.

Codex создаёт рабочую копию из зафиксированного HEAD исходного репозитория, переводит её в состояние detached HEAD и привязывает к новой сессии. В detached HEAD рабочая копия указывает прямо на коммит, а не перемещает именованную ветку. Исходное рабочее дерево остаётся на месте.

У такого чистого старта есть важное следствие: незакоммиченные изменения из исходной рабочей копии в новую сессию не попадут. То же относится к игнорируемым файлам — например, обычному файлу .env или каталогу node_modules. OpenAI описывает копирование через .worktreeinclude для локальных рабочих деревьев, которыми управляет Desktop, но прямо указывает, что для созданных из командной строки worktree это поведение не действует. В CLI-сценарии нужное окружение придётся подготовить самостоятельно.

Если запустить Codex из вложенного каталога репозитория, управляемая рабочая копия сохранит относительное расположение. Например, при старте из apps/web сессия окажется в соответствующем каталоге apps/web внутри нового worktree — при условии, что он существует в зафиксированной ревизии.

Практический процесс: от запуска до сохранения результата

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

1. Начните с нужного коммита

--worktree — логический переключатель, а не средство выбора ветки или базового коммита. Новая рабочая копия создаётся из HEAD указанного репозитория. Перед запуском переключитесь на нужную базовую ветку и закоммитьте изменения исходника, без которых задачу не выполнить. Указать конкретную локальную рабочую копию можно через -C <repo-path>.

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

2. До правок проверьте рабочую копию

В начале попросите Codex выполнить pwd, git status --short и git rev-parse --short HEAD. Текущий каталог должен вести в управляемый путь, статус — быть чистым, а коммит — совпадать с тем HEAD исходника, от которого вы собирались начать.

Эта проверка защищает от самой дорогой из скучных ошибок: качественно выполнить работу не на той базе.

3. Устанавливайте только необходимое для этой задачи

Worktree изолирует файлы рабочей копии. Он не создаёт контейнер, не резервирует порт, не клонирует базу данных и не устанавливает зависимости. Выполните в управляемой рабочей копии обычную для репозитория команду настройки. Если сессии работают параллельно, назначьте им отдельные порты, временные базы данных, каталоги кеша и тестовые учётные записи там, где возможны конфликты.

Это главное ограничение. Даже две рабочие копии с чистыми Git-диффами способны помешать друг другу, если обе сессии мигрируют одну и ту же базу разработки или пытаются занять один порт.

4. Проверьте diff и продолжите нужный диалог

Внутри сессии worktree команда /review может проверить незакоммиченные изменения. В другом терминале сначала введите /worktree, выберите Browse worktrees, укажите рабочую копию, затем выберите Copy working directory. После этого выполните git -C "<worktree-path>" status --short, git -C "<worktree-path>" diff --stat и git -C "<worktree-path>" diff.

Не запускайте codex review --worktree: версия 0.154.0 отклоняет такое сочетание флагов. Проверяйте активный worktree из его сессии либо направляйте обычные инструменты ревью на скопированный путь.

Чтобы продолжить работу позже, введите /worktree, выберите Browse worktrees, укажите управляемую рабочую копию, затем нажмите Resume owner thread. Не добавляйте --worktree к codex resume: возобновление должно вернуть вас в уже привязанную к сессии рабочую копию, а не создавать ещё одну.

5. Сохраните изменения до очистки рабочей копии

Если изменения нужны, запустите подходящие тесты, создайте коммит в worktree и скопируйте его SHA. Затем в исходной рабочей копии выполните git cherry-pick <sha>, чтобы перенести коммит в текущую ветку. Сделайте cherry-pick до удаления worktree — так у коммита из detached HEAD появится надёжное место назначения.

Если работа заслуживает отдельной ветки для ревью, выполните в worktree git switch -c codex/<task>, создайте коммит, отправьте ветку и откройте pull request. Git не позволит одновременно держать одну ветку открытой и в исходной рабочей копии. Отправьте её из worktree либо сначала удалите этот worktree и только потом переключайтесь на ветку в другом месте.

Созданные через CLI рабочие деревья автоматически не удаляются. Когда изменения уже надёжно закоммичены или вы сознательно от них отказались, убедитесь, что рабочая копия чистая, и выполните из исходного репозитория git worktree remove <worktree-path>. Не используйте --force. Позже команда git worktree prune может убрать устаревшие регистрации Git, но она не заменяет проверку, не владеет ли рабочей копией активная сессия.

Как git worktree влияет на бюджет

Штатная функция убирает небольшой, но постоянно повторяющийся слой shell-рутины. До версии 0.154.0 пользователю CLI приходилось создавать путь, создавать или отсоединять ветку, запускать Codex в нужном каталоге, помнить, какому чату он соответствует, а потом очищать и Git-состояние, и состояние сессии. Теперь флаг за один запуск создаёт рабочую копию и привязывает её к сессии, а /worktree предоставляет браузер рабочих деревьев репозитория и способ вернуться к работе.

Для действующего подписчика Codex отдельной опубликованной платы за рабочую копию нет. Codex Plus стоит $20 в месяц. Коммерческое пространство для агентов Unstoppable, организующее параллельные worktree, предлагает платный тариф Pro от $19 в месяц, Business — за $29 за пользователя, Enterprise — за $49 за пользователя. Теперь нативного Codex достаточно для узкой задачи создания рабочей копии и возобновления сессии в рамках уже оплачиваемой подписки.

Но весь класс платных рабочих пространств эта функция не заменяет. Панели для нескольких агентов, распределение портов, общая настройка окружений, агрегация тестов, отслеживание pull request, командные политики и отчётность по расходам остаются над уровнем обычной рабочей копии. Кроме того, параллельные сессии расходуют один и тот же лимит Codex. Поэтому корректный финансовый вывод — не «параллельная разработка стала бесплатной», а «от отдельного инструмента оркестрации можно отказаться, если он был нужен только ради изоляции».

Более широкий контекст продукта разбирает обзор Codex, включая локальный CLI и работу агента. А предыдущий разбор Codex CLI 0.152.0 объясняет, почему при автоматизации терминала важно учитывать ограничения конкретного релиза.

Семь задач для worktree — от самых выгодных

1. Рискованное обновление зависимостей

Мейнтейнер может запустить отдельный worktree для обновления фреймворка, менеджера пакетов или тест-раннера, поручить Codex изменить lock-файлы и конфигурацию и прогнать полный набор тестов, не загрязняя работу над функцией в основной рабочей копии. В результате получается отдельный, удобный для ревью поток обновления, который можно удалить без stash и без отката посторонних правок.

2. Два варианта реализации одной функции

Тимлид может разветвить один и тот же диалог о плане в два управляемых worktree: в одной сессии запросить минимальный патч, в другой — более системный подход, а затем сравнить размер diff, тесты и риск миграции. Выбор будет опираться на факты, и вторая попытка не перезапишет первую.

3. Разбор бага параллельно с разработкой продукта

Разработчик, уже наполовину реализовавший функцию, может создать из зафиксированного HEAD чистый worktree для воспроизведения бага в продакшене. В отдельном потоке Codex добавит диагностику, тесты и исправление, а незавершённая функция останется нетронутой. Это означает меньше экстренных stash и более чистый diff для хотфикса.

4. Масштабные кодмоды и рефакторинг

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

5. Отдельный поток для правок после ревью

Автор pull request может закоммитить базу ревью, запустить из этого состояния изолированную сессию Codex и исправить замечания, не прерывая работу в другой локально открытой ветке. Получится сфокусированная серия исправлений, которую при готовности можно отправить прямо из worktree.

6. Воспроизводимые задачи обслуживания

Инженер сборки может использовать codex exec --worktree для конкретной задачи — например, обновить сгенерированные файлы или исследовать нестабильный тест. Неинтерактивный запуск получит чистую рабочую копию отслеживаемых файлов и сохранённую сессию, к которой можно вернуться позже. Это снижает риск случайно захватить состояние основной рабочей копии. Но настройкой зависимостей и очисткой должна управлять сама автоматизация.

7. Безопасное знакомство с репозиторием

Новый участник команды может поручить Codex составить карту незнакомой кодовой базы и попробовать небольшое изменение документации или теста в управляемом worktree, прежде чем касаться обычной рабочей копии. Польза здесь не только техническая, но и психологическая: у исследования есть видимые границы, а результат легко отбросить.

Три продукта, которые можно построить вокруг оставшихся пробелов

1. Самая сильная идея: слой подготовки worktree

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

Спрос достаточно широк: git worktree получает около 9,900 поисковых запросов Google в США в месяц, а what is a git worktree — ещё 590. Нативная функция Codex решает задачу создания рабочей копии, но не подготавливает среду выполнения, поэтому этот вариант выглядит самым перспективным.

Минимальная версия, за которую уже можно брать деньги, должна включать манифест репозитория, команды настройки и удаления, резервирование портов, шаблоны файлов окружения и проверку состояния. Главный риск — безопасность. Инструмент, который копирует секреты или направляет двух агентов в одну базу данных, способен создать больше проблем, чем решить. Кроме того, OpenAI может добавить собственные хуки жизненного цикла и сузить этот пробел.

2. Панель потоков для разных агентов

Создайте настольную или терминальную панель, которая находит worktree в разных репозиториях и инструментах, а затем показывает связанную сессию, ветку или состояние detached HEAD, изменённые файлы, результат тестов, расход Codex, pull request, место на диске и безопасное действие для возобновления или очистки.

Запрос git worktree claude code получает около 480 поисков Google в США в месяц, а точная фраза parallel coding agents — 10. Второй показатель невелик, однако готовность платить уже видна: тариф Unstoppable начинается с $19 в месяц, и продукт включает параллельные рабочие деревья для агентов. Покупатель — разработчик, который уже переключается между Codex, Claude Code и обычными терминалами.

MVP может оставаться доступным только для чтения: перечислять рабочие деревья Git, сопоставлять известные метаданные сессий, по запросу запускать команды статуса и тестов и давать глубокие ссылки на каждого агента. Риск — конкуренция с нативными возможностями. Codex 0.154.0 уже умеет просматривать собственные управляемые worktree, поэтому продукт должен выигрывать за счёт общей картины по разным агентам, состояния среды выполнения и командной отчётности.

3. Шлюз интеграции и очистки

Создайте защитный шлюз между завершённым потоком агента и основной веткой. Он будет проверять чистоту статуса, запускать обязательный набор тестов, находить файлы, которые изменили другие активные worktree, предлагать порядок cherry-pick и запрещать опасную очистку, пока остаются неинтегрированные коммиты.

Спрос отражают уже существующие вопросы: git remove worktree получает около 390 поисковых запросов Google в США в месяц, git worktree vs branch — 320, а git worktree prune — 140. Все они относятся к моменту, когда изолированную работу пора превращать в общую.

MVP — локальная команда Git и небольшой файл политик. Польза появится даже без автоматического изменения кода. Риск связан с распространением: те же проверки могут добавить Git-клиенты и поставщики CI, поэтому самостоятельному продукту нужна превосходная поддержка разных агентов для программирования и сложных реальных репозиториев.

Ограничения для выбора подхода

Используйте нативные worktree, когда требуется изоляция файлов. Не путайте её с полной изоляцией окружения.

В этом релизе у CLI также нет аналога кнопки Handoff из приложения Desktop. Перенос кода остаётся решением на уровне Git: создать коммит и выполнить cherry-pick, отправить ветку либо отказаться от изменений и удалить рабочую копию. Такая явность полезна. Смысл изоляции как раз в том, чтобы ничего не попадало в основную рабочую копию случайно.

Задача на понедельник: выберите некритичное обновление зависимости, выполните его через codex --enable worktrees --worktree, сравните diff и результаты тестов по скопированному пути рабочей копии, перенесите через cherry-pick только принятый коммит, а затем удалите worktree. Если вам нужен надёжный процесс изолированной работы агентов с вашими репозиториями, я помогу спроектировать промышленную систему.