Codex - это не одна терминальная команда, а семейство совместимых поверхностей с общей моделью задач, но разными границами выполнения. CLI, IDE-расширение, desktop-приложение, cloud и прямой доступ к API решают, по сути, одну и ту же задачу - провести управляемое изменение кода, - но делают это в разных средах, с разным доступом к файлам, разной моделью доверия и разным набором интеграций. Поэтому первый вопрос не "какой интерфейс приятнее", а "где именно должна выполняться эта работа и что она увидит".
Локальный CLI - это точка максимального контроля и прозрачности. Именно там доступны все флаги запуска, неинтерактивный режим, скрипты и самая честная диагностика через codex --help и /status. Цена контроля в том, что нужно понимать shell, sandbox и approvals: CLI ничего не прячет, но и не решает за вас. Это база, к которой стоит возвращаться, когда поведение на другой поверхности кажется загадочным, - в терминале видно, что происходит на самом деле.
IDE-расширение переносит тот же агент ближе к редактору. Оно приносит контекст выделения и открытых файлов, короткий цикл обратной связи и правки прямо по месту, оставаясь при этом локальным выполнением. Здесь важно держать в голове разделение: часть настроек и состояния принадлежит расширению, а поведение агента, config и AGENTS.md общие с CLI. Расширение удобно для точечной работы рядом с кодом, но политику и границы задаёт та же конфигурация, что и в терминале.
Desktop-приложение смещает акцент на параллельность и визуальный контроль: несколько чатов и задач сразу, просмотр diff, встроенный терминал, работа с проектами и цели выполнения (local, cloud). Отдельная тонкость в том, что desktop-приложение и CLI могут содержать разные версии Codex. Функция, появившаяся в одном клиенте, не обязана одновременно быть в другом, поэтому версию каждого проверяют отдельно - для CLI это codex --version.
Cloud выносит выполнение на инфраструктуру OpenAI: Codex клонирует репозиторий в свежее окружение, проходит фазу setup и работает автономно, возвращая результат через branch и PR. У этого окружения нет ваших локальных файлов и состояния shell - зависимости и доступ в сеть задаёт конфигурация окружения. Это лучший выбор для долгой задачи без открытого компьютера, но и модель доверия здесь другая: код и секреты живут в облаке, а не на вашей машине.
Полезно один раз свести поверхности в таблицу - где выполняется работа, когда её выбирать и что проверить перед стартом. Ниже такая карта. К ней возвращаются не ради красоты, а ради решения: там, где нужен полный контроль и диагностика, - CLI; где нужна правка рядом с редактором - IDE; где несколько визуально контролируемых задач - desktop; где автономность в изоляции - cloud; где программная интеграция - API и SDK. У каждой задачи есть своя естественная поверхность.
| Поверхность | Где выполняется | Когда выбирать | Что проверить |
|---|---|---|---|
| Codex CLI | Локально, в OS sandbox | Терминальный workflow, скрипты, review | /status, Git root, sandbox, approvals |
| IDE extension | Локально рядом с редактором | Правки по selection и открытым файлам | Версия расширения, общий config |
| Desktop app | Локальные и cloud-задачи | Несколько задач, визуальный diff | Версия клиента, execution target |
| Cloud | Инфраструктура OpenAI | Долгая автономная задача через PR | Окружение, setup, доступ в сеть |
| API / SDK | Ваш процесс/сервис | Встраивание в CI и автоматизацию | Auth, лимиты, structured output |
Прямой доступ через API и SDK - это уже не интерактивная оболочка, а строительный блок для собственной автоматизации. Он нужен, когда Codex встраивают в чужой процесс: CI, сервис, внутренний инструмент. Об этом отдельные главы в конце, но карту стоит держать в голове с самого начала: выбор поверхности - это выбор среды и границы доверия, а не вкуса. Правильная поверхность экономит и время, и риск, а неправильная создаёт лишнее и то, и другое.
Инженерный вывод простой: стандартизируйте контракт репозитория и политику, а не любимую оболочку. Хорошие AGENTS.md, config, тесты и skills должны работать на нескольких поверхностях одинаково, а специфичное для одного клиента - жить отдельно и не завязывать на себя весь процесс. Тогда переход между CLI, IDE, desktop и cloud остаётся свободным выбором под задачу, а не переписыванием рабочего процесса каждый раз заново.