Как мигрировать с Claude Code на Codex в 2026: пошаговая инструкция

Каждый день в Telegram-канале - что нового в вайб-кодинге и ИИ-агентах: инструменты, паттерны, ошибки. Подпишись, чтобы быть в курсе.

Зачем вообще нужен Codex Migration tool?

OpenAI добавил функцию в Codex в начале июня 2026. В официальном changelog формулировка короткая:

В переводе: при первом запуске Codex App или из настроек уже работающего клиента запускается мастер, который читает локальные конфиги другого агента. На сегодня поддерживаются Claude Code и Claude Cowork.

Аналитика Phemex News формулирует прицельнее: инструмент сканит файловую систему и переносит "system prompts, custom skills, chat history, MCP server settings, automated scripts". Это и есть тот самый "supported setup" из changelog.

Зачем это OpenAI - понятно. У Codex после выхода Sites и обновлений Codex App в мае-июне 2026 появилось всё, чем раньше Claude Code обыгрывал OpenAI: терминал, плагины, длинные сессии, оркестрация. Миграция убирает последний барьер для команд, которые уже встроили Claude Code в свой стек: "всё сохранится, можно пробовать без потерь".

Зачем это тебе - сложнее. Я разбирал лоб-в-лоб сравнение в гайде Codex vs Claude Code: на длинных архитектурных диалогах и Plan Mode Claude всё ещё впереди, на автономных задачах и параллельных PR Codex быстрее. Если ты решил переходить полностью - читай дальше. Если думаешь о связке - возможно, ближе паттерны совместной работы.

Что Migration tool переносит автоматически?

Разберу по группам - что именно происходит на каждом фрагменте ~/.claude.

1. Инструкции и контекст. Файлы CLAUDE.md - и глобальный из ~/.claude/, и проектные из репозиториев - переезжают в формат AGENTS.md. Глобальный осядет в ~/.codex/AGENTS.md, проектные останутся в корне репозитория и в дочерних папках. Формат AGENTS.md по своей сути такой же markdown-файл с правилами, отличия в основном косметические - имена секций и пара специфичных директив. Я разбирал, что такое AGENTS.md и зачем он нужен Codex.

2. Skills. Папка ~/.claude/skills/ сканится целиком, каждый skill адаптируется под структуру Codex и кладётся в $HOME/.agents/skills. Проектные skills из .claude/skills/ в репозитории - переезжают в .agents/skills. Формат SKILL.md с frontmatter переносится почти как есть. Если в skill использованы Claude-специфичные триггеры - они флагируются для проверки.

3. MCP-серверы. Конфиг .mcp.json (и глобальный, и проектный) импортируется в формат Codex. Имена серверов, команды запуска, пути сохраняются. Что не переезжает - токены и переменные окружения. По соображениям безопасности Codex запросит у тебя API-ключи и пароли заново, чтобы не светить их в процессе миграции. Это разовая задача - в Codex App открываешь раздел MCP и подставляешь токены, которые уже есть в твоём менеджере паролей.

4. Hooks. Сюжетная группа. Hooks с детерминированной логикой (запрет rm -rf, alert на credential-shaped пути, запись evidence) переезжают целиком. Hooks с триггерами, у которых нет аналога в Codex (например, специфичные жизненные события Claude Code), помечаются как "manual review" и не активируются автоматически. Я подробно разбирал, как устроены hooks в Claude Code, чтобы было от чего отталкиваться - в Codex их меньше типов.

5. История сессий. До 30 последних дней работы с Claude Code импортируются как референс. Это не "продолжить точно так же", но в Codex видны прошлые твои разговоры, чтобы можно было быстро вспомнить контекст проекта и не объяснять всё заново. По отчётам корейского ИИ-агентства, цитируемого в нескольких разборах миграции, на этом шаге сюрпризов нет.

По свидетельству Blake Crosley, у которого в инвентаре оказалось 744 файла конфигурации Claude Code, реальная сущность системы держалась всего на 20 файлах. Остальные - артефакты экспериментов и забытые попытки. Migration tool это не различает - он переносит всё. После переноса полезно почистить руками то, чем ты не пользовался последние полгода.

Что НЕ переносится и почему?

Разберу каждую группу с точки зрения "что делать после миграции".

MCP-токены и API-ключи. Это самое предсказуемое. После сканирования Codex покажет список всех MCP-серверов, которые он нашёл в Claude. По каждому - запросит ключи и токены. Удобнее всего иметь под рукой менеджер паролей и пройти все серверы за один присест. После этого MCP в Codex работает идентично Claude Code.

Slash-команды /имя. В Claude Code ты привык вызывать skill через /skill-name. В Codex канонический вызов другой - $skill-name. Blake Crosley специально выделяет это как самую частую ошибку миграции:

После переноса протестируй несколько ключевых skills через $skill-name в Codex. Если сработали - значит, миграция реально удалась. Не доверяй галке "skills migrated" в мастере - проверяй вызовом.

Hooks без аналога в Codex. Если у тебя был hook на специфичные события Claude Code - например, на pre-tool-use определённой комбинации инструментов - в Codex такой триггер может отсутствовать. Migration tool пометит их и не активирует. Тебе придётся решить - переписать под Codex-аналог, отказаться или держать в Claude Code (если оставляешь его параллельно). Хорошее правило, которое я взял у Blake Crosley: переносить только детерминированные хуки, всё остальное - повод не плодить копии лестницы в новом инструменте.

Командные workflow на subagent-ах. Я разбирал, что такое subagents в Claude Code и как использовать вложенные субагенты. В Codex subagent-ы устроены через профили и роли (см. ниже). Если у тебя в Claude был сложный пайплайн с несколькими subagent-ами в цепочке - его придётся переписать под концепцию профилей Codex. Migration tool помечает такие сетапы как "requires architectural rework".

Большие специфичные CLAUDE.md. Если файл вырос до 2000-3000 строк с разделами под каждый проект, Codex может его принять, но это плохой паттерн. AGENTS.md проектируется компактным и распределённым: глобальные правила в ~/.codex/AGENTS.md, проектные - в корне репозитория, узкие override - в дочерних папках. После миграции - не оставлять CLAUDE.md как "гигантскую инструкцию", а разнести по уровням. Я разбирал, как настроить CLAUDE.md правильно - тот же подход переносится на AGENTS.md.

Пошагово: 4 действия в Codex App

Конкретный чеклист, как это пройти.

1. Шаг 1: обнови Codex App до 26.608 или новее

   Migration tool появился в версии 26.608 (релиз 9 июня 2026). На macOS - открыть Codex App, проверить обновления. На Windows - то же. Если запускаешь Codex CLI - убедись, что он совместим с актуальной App. Без свежей версии в Settings не появится пункта "Import other agent setup".

2. Шаг 2: запусти импорт из настроек

   В Codex App открой Settings, найди пункт "Import other agent setup". Если ты только что установил Codex App, мастер сам предложит миграцию во время онбординга. После старта мастер сканит файловую систему: ~/.claude/ и репозитории, в которых лежат CLAUDE.md или .claude/. Сканирование занимает от 30 секунд до нескольких минут в зависимости от количества файлов.

3. Шаг 3: подтверди план переноса

   После сканирования Codex покажет инвентаризацию: сколько skills нашлось, сколько MCP-серверов, сколько CLAUDE.md найдено, какие hooks подлежат миграции, сколько дней истории сессий доступно. Для каждой группы можно снять галочку, если что-то не хочешь переносить. По умолчанию выбрано всё, что Codex считает безопасным импортировать.

4. Шаг 4: дождись завершения и подставь токены

   Импорт занимает 1-5 минут. После завершения Codex откроет follow-up окно: "вот что я не смог перенести автоматически, проверь руками". Обычно это список MCP-серверов, которым нужны токены. Открой свой менеджер паролей, подставь ключи в форму Codex. После этого основная часть миграции закрыта.

Дальше - сверка. Открой проект, который ты обычно вёл в Claude Code, проверь:

• cat ~/.codex/AGENTS.md - есть ли там твои глобальные правила.
• Запусти любой skill: $skill-name. Должен подгрузиться.
• Открой .mcp.json в проекте - проверь, что нужные серверы подняты.
• Запусти диалог, в котором ты типично работаешь. Codex покажет, какие из импортированных hooks ему недоступны - это и есть "5%", которые нужно решить руками.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 23–25 июня  ·  2 000 ₽

Записаться →

Hooks и Subagents: где аналоги в Codex и что переписывать

По хукам. В Claude Code на каждое событие жизненного цикла (pre-tool-use, post-tool-use, on-error, on-context-load и пр.) можно повесить shell-команду. В Codex набор событий компактнее - есть проверка перед выполнением, есть запись evidence, есть блокировка опасных команд. Если у тебя был hook на pre-tool-use с фильтрацией по конкретной комбинации - в Codex придётся либо завернуть это в общую проверку перед выполнением, либо отказаться. Я подробно разбирал архитектуру хуков в Claude Code, и если ты ими активно пользовался - заложи на переписывание примерно час.

По subagent-ам. В Claude Code subagent - это отдельный контекст с своим системным промптом, который запускается по /команда или из основного диалога. В Codex есть похожая концепция профилей: ты можешь задать профиль с конкретным набором skills, разрешений и approval policy. Профили решают примерно ту же задачу - изоляцию контекста под определённый класс задач - но через настройки, а не через явный вызов агента.

Что это значит на практике:

• Если у тебя был subagent "security-reviewer" с собственным промптом - в Codex заведи профиль security-review с нужными разрешениями и higher reasoning effort.
• Если у тебя был subagent "feature-developer" - это просто рабочий профиль по умолчанию, ничего особенного.
• Если ты использовал вложенные субагенты - в Codex это не сработает один-в-один, нужно переосмыслить через цепочку профилей или через явные скилы.

Migration tool попытается завести профили по именам твоих subagent-ов и пометит, какие триггеры не переехали. На практике это занимает 30-60 минут на каждый сложный subagent-пайплайн.

cc2codex: альтернатива через CLI с предпросмотром

cc2codex - бета-инструмент с GitHub, который устанавливается как плагин Codex CLI. Цикл работы:

cc2codex install-plugin     # установка плагина
cc2codex scan               # инвентаризация ~/.claude
cc2codex doctor             # отчёт о готовности к миграции
cc2codex plan               # план без записи
cc2codex apply              # применить план
cc2codex start              # управляемая миграция с пошаговым превью

Что переносит хорошо:

• CLAUDE.md инструкции
• Skills (адаптация под структуру Codex)
• Hooks с высокой степенью уверенности
• Конфигурация MCP-серверов

Что требует проверки:

• Токены MCP и API-ключи - ввести заново
• Claude-специфичные события хуков
• Командные workflow на subagent-ах
• Большие или специфичные наборы инструкций

Главная разница со встроенным мастером Codex App - в прозрачности. cc2codex plan показывает тебе, какие файлы будут изменены, какие созданы, что переименовано. Если потом cc2codex apply упадёт где-нибудь - ты увидишь точно, где. Встроенный мастер на этот уровень не пускает: показал галочки, нажал кнопку, дальше как пойдёт.

Если в ~/.claude у тебя 50+ skills и десяток MCP-серверов с разной авторизацией - я бы шёл через cc2codex. На чистой свежей ~/.claude достаточно встроенного мастера.

Когда мигрировать целиком, а когда держать оба инструмента

Простой decision-фильтр:

Полный переход на Codex оправдан, если:

• Ты в основном делаешь автономные PR и параллельные задачи.
• У тебя глубоко встроен GitHub-флоу, и Codex Cloud Agent закрывает 80% работы.
• Ты не сильно тратишь время на архитектурные обсуждения и Plan Mode.
• Тебе важно платить за один инструмент, а не за два.

Связку Claude Code + Codex стоит оставить, если:

• Ты регулярно используешь Plan Mode для длинных архитектурных решений.
• Тебе нужна параллельная работа: Codex запускается в облаке на одной задаче, Claude Code держит контекст другой.
• Ты делаешь много разовых хаков и микро-проектов, где Plan Mode избыточен.
• У тебя сложный пайплайн на subagent-ах, который не переписывается одним вечером.

Я лично работаю в связке: Claude Code держит длинный диалог, Codex запускается на "починить N багов параллельно" или "прогнать ревью PR". Подробнее, как это устроено, разбирал в гайде про совместную работу Claude Code и Codex.

Главное, что я бы сказал про миграцию: Migration tool снимает технический барьер перехода, но не отвечает за то, нужен ли тебе сам переход. Сначала реши, что у тебя за сценарий работы. Потом - инструмент.