Переезд в Codex: как перенести правила, навыки и инструменты без хаоса

Когда команда переходит с одного агентного инструмента на Codex, главный риск не в том, что что-то не импортируется. Главный риск в другом: старые правила, команды, навыки и подключения переедут как будто автоматически, а люди начнут пользоваться ими без проверки.

Переезд в Codex лучше понимать не как кнопку «перенести всё», а как ревизию рабочего контура. Что у нас было? Что действительно нужно? Какие настройки относятся к человеку, а какие к проекту? Какие инструменты могут менять внешние системы? Какие инструкции устарели? Где нужен отдельный follow-up thread, потому что прямого соответствия нет?

Почему импорт не равен готовому рабочему процессу

Старый агентный setup обычно растет кусками. В одном месте лежат инструкции. В другом — настройки модели и разрешений. В третьем — навыки, slash commands, MCP-серверы, hooks, subagents и старые сессии. Часть этого помогала реальной работе. Часть появилась как временный костыль. Часть уже опасна, потому что проект изменился.

Если перенести всё без разбора, Codex получит не порядок, а наследство. Например, команда может случайно сохранить слишком широкие разрешения, старый prompt с небезопасными shell-подстановками, MCP-сервер с кастомной авторизацией или hook, который в новой среде ведет себя иначе.

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

Что документация говорит о миграции в Codex

Официальная документация OpenAI описывает import flow для переноса настройки из другого агента в Codex. Запускается он в Codex app: Settings, General, Import other agent setup. После этого пользователь выбирает, что Codex нашел и что нужно импортировать.

Codex проверяет два уровня. User-level setup берется из файлов на машине пользователя. Project-level setup берется из репозитория, который открыт сейчас. Это важное разделение: личные привычки не должны автоматически становиться правилами проекта, а проектные ограничения не должны растворяться в личной настройке.

Документация перечисляет, что Codex может импортировать. Instruction files переходят в AGENTS.md. settings.json переходит в config.toml. Skills становятся Codex skills. Recent sessions за последние 30 дней становятся Codex threads и projects. MCP server configuration переходит в Codex MCP configuration. Hooks переходят в Codex hooks. Slash commands могут стать skills. Subagents становятся Codex agents.

После импорта Codex проверяет setup снова и может предложить продолжить оставшуюся миграцию в новом thread. Это нужно для элементов, у которых нет чистого соответствия один к одному.

Отдельный блок документации говорит, что импортированную настройку нужно проверить перед использованием. Особенно права и ограничения в skills и agents, MCP-настройки с кастомной авторизацией, headers, environment variables или transports, hooks, плагины и marketplace-остатки, а также prompt templates с аргументами, shell interpolation или file-path placeholders.

Когда стоит запускать импорт

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

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

Хороший момент для миграции — когда команда может ответить на три вопроса:

Что дать Codex перед переездом

Перед импортом полезно собрать короткий migration brief. Не техническую диссертацию, а список того, что вы хотите сохранить и как будете проверять результат.

В brief стоит указать текущий проект, старый инструмент, какие файлы инструкций важны, какие настройки нельзя ослаблять, какие skills используются часто, какие MCP-серверы подключены, какие hooks критичны, какие slash commands повторяются и какие недавние сессии действительно нужны.

Отдельно укажите стоп-лист. Например: не переносить экспериментальные команды, не включать доступы без review, не сохранять секреты в prompt templates, не превращать личные настройки владельца в командный стандарт.

Тогда Codex будет помогать не «перетащить всё», а собрать управляемую карту переезда.

Как разделить личные и проектные настройки

User-level setup — это то, что относится к человеку: личные предпочтения, привычные команды, собственные навыки, недавние сессии. Project-level setup — это то, что относится к рабочему контексту: правила репозитория, инструкции команды, проверки, ограничения, проектные tools, hooks и MCP.

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

Практическое правило простое: всё, что должно применяться ко всем в проекте, живет рядом с проектом. Всё, что является личной привычкой, остается личным. Всё, что влияет на доступы, публикацию, платежи, production или внешние системы, проходит отдельный review.

Как должен выглядеть результат миграции

Хороший результат импорта — это не просто список созданных файлов. Это карта приемки.

В ней должно быть видно:

• что импортировано напрямую;
• что не импортировано и почему;
• какие элементы требуют follow-up thread;
• какие настройки относятся к user-level;
• какие настройки относятся к project-level;
• какие MCP-серверы и hooks могут иметь внешний эффект;
• какие prompt templates используют аргументы, пути или shell-подстановки;
• какие правила нужно протестировать на маленькой задаче.

После этого можно открыть один migrated project и выполнить пробную задачу. Не production-изменение, не публикацию, не массовую миграцию, а безопасный smoke test: попросить Codex прочитать проектные правила, объяснить доступы, выполнить маленькую проверку и вернуть отчет.

Как проверить импорт без программирования

Непрограммисту не нужно читать весь config.toml построчно. Но нужно проверить смысл.

Первое: видны ли проектные правила? Codex должен понимать, что можно менять, что можно только предлагать, где нужна проверка человека.

Второе: какие tools подключены? Если среди них есть MCP-серверы с кастомной авторизацией, headers, environment variables или нестандартным transport, это зона review.

Третье: что делают hooks? Если hook запускает проверку, это хорошо. Если hook может менять файлы, отправлять данные или ломать workflow, его нужно смотреть отдельно.

Четвертое: что случилось со slash commands и prompt templates? Если они зависят от аргументов, shell interpolation или file-path placeholders, после переезда они могут вести себя иначе.

Пятое: не перенеслись ли старые ошибки? Импорт сохраняет рабочую память, но не гарантирует, что эта память была правильной.

Где остается человеческое решение

Codex может найти setup, импортировать часть элементов и предложить продолжить миграцию в новом thread. Но человек решает, чему доверять.

Человек решает, какие старые навыки оставить. Человек решает, какие MCP-подключения допустимы. Человек решает, какие hooks нужны проекту. Человек решает, какие prompt templates безопасны. Человек решает, можно ли использовать migrated project для реальной работы или сначала нужен тест.

Переезд в Codex хорош тогда, когда он делает старый контур видимым. Не «мы всё перенесли», а «мы знаем, что перенесли, что проверили, что оставили вручную и где еще нужен follow-up».

Шаблон запроса

Можно дать Codex такой запрос:

Помоги принять миграцию старого агентного setup в Codex.

Старый контур:
[какой агент или инструмент использовался]

Проект:
[папка/репозиторий/тип работы]

Что нужно сохранить:
- instruction files;
- settings;
- skills;
- MCP servers;
- hooks;
- slash commands;
- subagents;
- recent sessions.

Границы:
- что относится к user-level setup;
- что относится к project-level setup;
- какие доступы нельзя включать без review;
- какие команды или prompts считаем устаревшими.

Проверь:
1. что импортируется напрямую;
2. что требует follow-up thread;
3. где есть риск permissions, MCP auth, hooks или prompt placeholders;
4. какие файлы и настройки нужно открыть человеку;
5. какую маленькую smoke-test задачу выполнить перед реальной работой.

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