Codex worktree нужен, когда вы хотите дать агенту две задачи и не смешать их правки в одной папке. Создайте отдельную рабочую папку и ветку Git для каждой задачи, направьте туда Codex через -C, а в основной проект перенесите только проверенный результат. Ниже - ручной путь с проверкой папок и выбранного коммита.
Инструкция рассчитана на проект, который уже хранится в Git, и установленный Codex - агент OpenAI. Если пока не запускали его в проекте, начните с первого запуска Codex. Здесь разбираем разделение задач в готовом окружении, без повторной установки и настройки доступа.
Как Codex worktree разделяет файлы и где остаётся риск
Коротко: в ручном сценарии worktree даёт каждой задаче свои рабочие файлы и ветку. История Git остаётся общей, а доступы к внешним сервисам нужно проверить отдельно. Папка сама по себе не ограничивает права агента.
Допустим, одна задача меняет проверку формы, другая - текст справки. В двух worktree можно отдельно посмотреть результат каждой и решить, что забирать в основную версию.
| Что проверяем | Как устроено |
|---|---|
| Рабочие файлы, подготовленные к коммиту изменения и текущий коммит (HEAD) | Отдельные у каждой папки |
| История изменений, сохранённые данные Git и большинство ссылок на ветки | Общие для одного репозитория |
| Настройки репозитория | По умолчанию общие; не меняйте их без понимания последствий |
| Порты, процессы, внешняя база данных | Автоматически не разделяются |
| Разрешения Codex | Задаются отдельно от worktree |
Если обе задачи меняют одни строки, конфликт может появиться при объединении. Если оба приложения подключены к одной рабочей базе, отдельные папки не защитят её от изменений. Для такого проекта сначала подготовьте безопасные доступы и окружение разработки.
Шаг 1. Проверьте исходную папку и сохраните нужные правки
Откройте терминал в основной папке проекта. Сначала только чтение:
git rev-parse --show-toplevel
git branch --show-current
git status --short
git branch --list mainПервая команда показывает корень проекта, вторая - текущую ветку. Пустой вывод git status --short означает, что Git не видит обычных незакоммиченных изменений, включая новые неигнорируемые файлы. Игнорируемые локальные файлы в эту проверку не входят.
Дальше в примере исходная ветка называется main. Если последняя команда ничего не напечатала, у вас другое имя: подставьте свою исходную ветку в команды следующего шага. Она должна содержать нужную версию проекта; новая worktree возьмёт её сохранённые коммиты.
Если status показывает ваши незавершённые изменения, сначала разберитесь с ними и сохраните нужное. Не выполняйте очистку или откат ради пустого status. Ручное создание worktree из main не перенесёт туда незакоммиченные правки исходной папки.
Выберите две независимые задачи. «Поменять подпись кнопки» и «дописать справку» разделить проще, чем «переделать структуру данных» и «переписать все обращения к ней».
Шаг 2. Создайте две рабочие папки на разных ветках
Эти команды выполняются из основной папки. Имена task-a, task-b и пути - примеры. Они должны быть свободны: не подставляйте существующую папку с важными файлами.
git worktree add -b task-a ../project-task-a main
git worktree add -b task-b ../project-task-b main
git worktree list-b создаёт новую ветку. Пути с ../ создают соседние папки: project-task-a на ветке task-a и project-task-b на ветке task-b. Основная папка остаётся на своей ветке.
Теперь проверьте каждую папку отдельно. По-прежнему выполняйте команды из основной папки:
git -C ../project-task-a rev-parse --show-toplevel
git -C ../project-task-a branch --show-current
git -C ../project-task-a status --short
git -C ../project-task-b rev-parse --show-toplevel
git -C ../project-task-b branch --show-current
git -C ../project-task-b status --shortВ этом ручном примере корни должны различаться, ветки - называться task-a и task-b, а status новой папки - быть пустым. Если Git сообщил, что ветка уже используется другой worktree, посмотрите git worktree list и выберите новое имя. Не добавляйте --force, чтобы обойти отказ.
Шаг 3. Запустите Codex с отдельным заданием в каждой папке
Откройте два окна терминала, оба в основной папке проекта. В первом запустите:
codex -C ../project-task-aВо втором:
codex -C ../project-task-bПараметр -C указывает рабочую папку запускаемой сессии. Он не создаёт worktree и не переносит в неё уже открытый разговор. Если терминал находится в другом месте, используйте полный путь к нужной папке.
Вместо общего «сделай лучше» дайте каждой сессии границы. Например, для первой задачи:
Работай только в этой папке и сначала покажи её корень и текущую ветку.
Найди проверку формы и исправь обработку пустого обязательного поля.
Не меняй соседние рабочие папки и общие настройки репозитория.
Перед правкой назови файлы, которые собираешься менять.
После правки покажи diff и результат подходящих тестов.
Не создавай коммиты, не отправляй изменения и не выполняй выкат.Это пример задания, а не уже выполненная проверка формы. Во второй сессии задайте другую конкретную работу и свои разрешённые файлы.
Если проекту нужны зависимости, установите их в новой папке по его инструкции. Не переносите целиком кэши, виртуальные окружения и боевые секреты. Для двух запущенных приложений могут понадобиться разные порты и отдельные данные разработки. Универсальной команды настройки для всех проектов нет.
Для повторяемого процесса можно посмотреть Superpowers и его скилл using-git-worktrees: он сначала проверяет, не дала ли среда уже отдельную папку, и смотрит исходные тесты проекта. Установка пакета не заменяет проверку папки, доступов и результата.
Хотите закрепить такие правила до следующей задачи? В ClaudeBase есть шаблоны AGENTS.md и уроки о постановке задач агенту и проверке его работы. Откройте описание подписки ClaudeBase и выберите, что применить в своём проекте. Описание подписки открыто всем, материалы базы доступны после оплаты. Подписки Anthropic и OpenAI оплачиваются отдельно.
Шаг 4. Проверьте изменения до переноса
Остановите работу агента над принимаемой задачей. Из основной папки посмотрите:
git -C ../project-task-a status --short
git -C ../project-task-a diff
git status --shortПервый status перечислит изменённые и новые файлы задачи. git diff покажет незаписанные в индекс изменения отслеживаемых файлов. Новые файлы с ?? просмотрите отдельно: обычный diff их содержимое не показывает.
Если агент уже подготовил изменения к коммиту, проверьте и их:
git -C ../project-task-a diff --cachedПоследний status основной папки помогает заметить правки вне задачи. Обращения к внешним сервисам и игнорируемым файлам он не показывает.
Запустите тесты и проверку сборки, предусмотренные именно вашим проектом. Для формы отдельно проверьте поведение с пустым полем и нормальными данными. Ответ агента «готово» без результата проверки не повод переносить правку.
Как понять, что можно переносить. В папке задачи видны только ожидаемые файлы, новые файлы просмотрены, проверка проекта прошла. Основная папка и вторая задача сохранили своё состояние. После переноса проверку нужно повторить: две исправные по отдельности задачи могут конфликтовать вместе.
Шаг 5. Перенесите только проверенный коммит
В папке первой задачи выберите нужные изменения. Например, git add -p позволяет отобрать части правок в отслеживаемых файлах:
cd ../project-task-a
git add -p
git diff --cachedНовые файлы эта команда не добавляет: после просмотра добавьте каждый нужный файл явно через git add -- путь-к-файлу, заменив пример пути настоящим. Не включайте в коммит секреты и посторонние изменения. После добавления файлов ещё раз выполните git diff --cached. Когда там ровно принятая правка, сохраните её:
git commit -m "Fix form validation"
git rev-parse HEADПоследняя команда напечатает хеш коммита. Скопируйте его. Затем откройте отдельное окно терминала в основной папке проекта, путь к которой показала первая команда шага 1. Не переключайте туда ветку task-a: она уже открыта в папке задачи. Проверьте текущую целевую ветку и чистый status:
git branch --show-current
git status --shortВ нашем примере целевая ветка - main. При другом имени или незавершённой работе остановитесь: сначала выберите нужную ветку и сохраните изменения. Не запускайте перенос в случайно открытой папке.
Просмотрите выбранный коммит через git show, затем перенесите его. В трёх командах ниже замените ХЕШ_КОММИТА скопированным значением:
git show --stat ХЕШ_КОММИТА
git show ХЕШ_КОММИТА
git cherry-pick ХЕШ_КОММИТАЭто перенос изменения из конкретного коммита, без копирования всей папки поверх проекта. Если в задаче несколько взаимозависимых коммитов, одного последнего может не хватить. Сначала разберите их порядок и зависимости; этот пример рассчитан на одну самостоятельную правку.
При конфликте Git остановится. Посмотрите git status и конфликтующие строки. Продолжать через git cherry-pick --continue можно после осознанного исправления конфликта, добавления проверенных файлов и повторных тестов. Если решили отказаться от текущего переноса, git cherry-pick --abort возвращает состояние до его начала; не используйте команду как очистку произвольных правок.
После успешного переноса снова проверьте приложение и тесты в основной папке. Вторую задачу принимайте отдельно. Папки с незавершённой работой пока сохраните.
Что проверено для этой инструкции. 30 октября 2026 года ручные команды шагов 1-5 прогнаны на учебном текстовом проекте под macOS 26.6, Git 2.39.5: из main созданы две worktree, правка файла в task-a не появилась ни в основной папке, ни в task-b; после cherry-pick выбранного коммита основная папка получила правку, task-b сохранила исходный текст, status всех трёх папок остался чистым. Попытку открыть ветку task-a во второй папке Git отклонил. Модель Codex и приложение в этой проверке не запускались.
Как запустить Codex worktree в приложении
Порядок сверен с документацией OpenAI 30 октября 2026 года:
- Откройте новый чат проекта Git и под полем задания выберите Worktree.
- Выберите исходную ветку и отправьте задачу. Codex создаст отдельную папку. По умолчанию она работает в detached HEAD, без имени ветки.
- Проверьте изменения и тесты в этой папке. Чтобы продолжать на своей ветке, нажмите Create branch here. Чтобы перенести чат и код в основную папку, выберите Hand off, затем Local.
Ручные команды выше берут сохранённый main. Приложение также умеет брать текущую ветку с незакоммиченными правками. Проверьте выбранную основу до отправки задания.
Зависимости в управляемой папке можно ставить автоматически: при выборе Worktree укажите локальное окружение со скриптом подготовки. Файлы, которые Git игнорирует, например .env, в новую папку сами не попадут. Если они нужны, перечислите их в файле .worktreeinclude в корне репозитория - Codex скопирует совпавшие игнорируемые файлы.
Это копирование работает только для локальных папок, которые создаёт приложение. Ручной git worktree add его не выполняет. Перечисляйте настройки разработки; боевые ключи не копируйте.
| Что видите | Что это значит и что делать |
|---|---|
git branch --show-current ничего не вывел |
В управляемой папке возможен detached HEAD. Проверьте путь и git status; для продолжения на ветке есть Create branch here |
| Git пишет, что ветка уже используется другой worktree | Одна ветка уже открыта в другой папке. Для переноса чата используйте Hand off; для независимой задачи создайте другую ветку |
| В папке нет зависимостей или локальных настроек | Подключите локальное окружение со скриптом подготовки или перечислите нужные игнорируемые файлы в .worktreeinclude; внешние доступы проверьте отдельно |
А если нужен автоматический worktree в CLI
В справке CLI описан --worktree. На 30.10.2026 флаг есть и в локальной справке Codex CLI 0.165.0:
codex --worktreeЭто отдельный вариант вместо ручного создания папки. codex -C ПУТЬ открывает уже выбранную папку. Вызов codex --help покажет, какие флаги доступны в вашей версии. Выполнение автоматического запуска здесь не проверялось.
Когда результат готов к проверке через pull request, переходите к Codex и GitHub. Эта инструкция заканчивается локальным переносом правки; доступ GitHub-приложения и запрос ревью разобраны отдельно.
Источники
Документация OpenAI и Git, а также локальная справка Codex CLI 0.165.0 сверены 30 октября 2026 года. Ручные команды Git проверены на учебном проекте в тот же день. Запуск модели и действия в приложении при этой сверке не выполнялись.