Где запускать Codex: приложение, IDE, CLI или облако
Codex становится непонятным не тогда, когда у него мало возможностей, а когда возможностей слишком много. Есть приложение, IDE extension, CLI, cloud/web, браузер, удаленные задачи, локальные проверки. Если не разделить эти поверхности, Codex снова превращается в туманную "штуку для всего".
Практический вопрос проще: где именно запускать задачу, чтобы она была проверяемой и не мешала основной работе?
Официальная документация Codex разделяет рабочие поверхности: App, IDE extension, CLI и Cloud/Web. Это не четыре конкурирующих способа "поговорить с агентом". Это разные режимы работы. Один удобен для управления задачами и статьями, другой — для кода рядом с редактором, третий — для команд и воспроизводимых проверок, четвертый — для длинных задач, которые можно отдать в изолированную среду.
Приложение Codex: когда нужна рабочая панель
Codex App удобно воспринимать как рабочий кабинет. Здесь лучше держать задачи, где важны треды, обзор состояния, браузерная проверка, команды, автоматики, публикационный или редакционный контур.
Пример задачи:
Возьми готовый article package, проверь gates, создай визуал, опубликуй, проведи live audit и поставь Telegram/VK через ArticleFactory.
Это не маленькая правка в одном файле. Это процесс. Для него важны состояние, логи, очереди, повторный запуск и видимый маршрут. App подходит, когда работа похожа на операционную смену: нужно видеть, что уже сделано, что заблокировано и какой следующий node.
IDE extension: когда работа рядом с кодом
IDE extension подходит, когда человек уже находится в редакторе и хочет, чтобы Codex смотрел на открытые файлы, выбранный фрагмент или ближайший контекст. Это удобно для объяснения кода, локальной правки, теста рядом с функцией, ревью конкретного участка.
Пример:
Посмотри выбранную функцию и напиши тест по стилю соседних тестов. Не меняй публичный API.
Здесь не нужна большая операционная панель. Нужна близость к коду. Человек видит файл, Codex видит выбранный участок, результат можно быстро принять в diff.
CLI: когда важен протокол и команды
CLI полезен, когда задача должна оставить понятный след: команды, вывод, патчи, проверки, повторяемый transcript. Это хороший режим для отладки, миграций, проверок, локальных скриптов и задач, где нужно явно сказать: запусти это, проверь это, покажи результат.
Пример:
Воспроизведи баг по шагам, внеси минимальную правку и запусти самый маленький релевантный тест. В ответе укажи команды и результат.
CLI дисциплинирует работу. Он делает видимыми команды и границы локальной среды. Если задача должна быть проверена не глазами, а запуском, CLI часто лучше обычного чата.
Cloud/Web: когда задачу можно вынести из локального контура
Cloud/Web режим нужен, когда работа длинная, изолированная или параллельная. Например, refactor milestone, подготовка PR, большая проверка, реализация плана, который не должен блокировать локальную машину.
Но облако не значит "отдать и забыть". Перед передачей нужно сформулировать план, границы и критерий проверки. После выполнения нужно принять diff, отчет или PR.
Пример:
Реализуй первый этап плана в отдельной облачной задаче. Не меняй публичное поведение. После завершения покажи diff, риски и команды проверки.
Cloud подходит, когда локальный контекст уже достаточно понятен, а выполнение можно отделить от текущей ручной работы.
Карта выбора поверхности
| Если нужно | Запускайте |
|---|---|
| Управлять процессом, статьями, очередью, браузером, gates | Codex App |
| Править код рядом с открытым файлом | IDE extension |
| Запускать команды, тесты, воспроизводить баг | CLI |
| Отдать длинную задачу в изолированную среду | Cloud/Web |
| Проверить страницу глазами | App browser или браузерный workflow |
| Дать параллельную задачу без смешивания результата | Cloud task или worktree |
Эта карта не заменяет здравый смысл, но убирает хаос. Не каждая задача должна жить в одном и том же окне.
Самая частая ошибка
Ошибка — выбирать поверхность по привычке, а не по типу работы. Человек открывает чат и просит "сделай весь процесс", хотя нужен App-контур. Или запускает облачную задачу без критериев приемки. Или просит IDE extension решать операционную очередь. Или держит в CLI то, что проще проверить глазами в браузере.
Правильный вопрос перед запуском:
Что я хочу принять в конце: diff, отчет, проверенный экран, опубликованную статью, PR, командный лог или план?
Ответ почти всегда подсказывает поверхность.
Где остается человек
Codex может работать в разных режимах, но человек выбирает маршрут. Это важнее, чем кажется. Если поверхность выбрана неправильно, даже хорошая модель будет тратить силы на обходные действия: искать контекст, просить уточнения, смешивать задачи, терять проверку.
Хороший пользователь Codex не просто пишет сильный запрос. Он выбирает место, где этот запрос должен исполняться. App для процесса, IDE для кода рядом с редактором, CLI для командного протокола, Cloud для вынесенной длинной работы. Тогда Codex становится не набором кнопок, а рабочей системой.
