Codex CLI: установка, настройка и первая задача из терминала

Codex CLI запускается в терминале и работает внутри выбранной папки проекта. Он может читать файлы, предлагать изменения и запускать установленные на компьютере инструменты. Это удобнее обычного чата, когда задача зависит от структуры репозитория и реального результата команд.

Такая близость к проекту требует аккуратного старта. Для первой сессии не нужен автономный режим. Достаточно установить CLI, открыть правильную директорию, попросить объяснить проект и сделать одно небольшое изменение под контролем Git.

Подготовьте:

• терминал;

• папку конкретного проекта;

• Git, если вы собираетесь менять файлы;

• учетную запись, доступную для входа в Codex.

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

В актуальном официальном quickstart для macOS и Linux первым показан standalone installer:

На той же странице доступны отдельные варианты для Windows, npm и Homebrew. Выберите вкладку своей системы и используйте команду оттуда: способы установки могут обновляться.

После установки проверьте, что команда доступна:

Команда для этого шага: codex --version.

Если терминал отвечает command not found, не переходите к запуску проекта. Сначала перечитайте сообщение установщика, откройте новый терминал и проверьте, добавлен ли каталог с программой в PATH.

Сначала найдите проект и перейдите в него. Например:

Команды по порядку: cd ~/Projects/my-app, pwd и ls.

pwd должен показать каталог проекта, а ls его знакомые файлы: например, package.json, README.md, src или .git.

Теперь проверьте состояние Git:

Команда для этого шага: git status.

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

Если git status показывает чужие незавершенные изменения, не просите Codex их «почистить». Это может быть ваша прошлая работа. Сохраните ее осознанно или выберите отдельную тестовую копию проекта.

В папке проекта выполните:

Команда для этого шага: codex.

При первом запуске интерфейс предложит доступный способ входа, в том числе Sign in with ChatGPT. Завершите авторизацию в браузере и вернитесь в терминал.

После входа проверьте текущую сессию командой:

В интерфейсе используется команда /status.

В интерактивном интерфейсе также доступны /model для выбора доступной модели и /permissions для управления границами выполнения. Названия и набор вариантов могут меняться, поэтому ориентируйтесь на подсказки текущей версии.

Не начинайте с «перепиши приложение». Попросите Codex сориентироваться и ничего не менять:

Сверьте ответ с README и файлами конфигурации. Если агент назвал несуществующую команду или неверный стек, попросите показать файл, на котором основан вывод.

Этот шаг проверяет сразу две вещи: вы действительно открыли нужную папку, а агент видит структуру проекта.

Перед изменением снова выполните git status. Если рабочее дерево чистое, запомните текущий коммит:

Команда для этого шага: git rev-parse --short HEAD.

Для учебного проекта без коммитов сначала создайте исходную рабочую версию вручную. Проверьте, что приложение запускается, затем добавьте только нужные файлы и сделайте коммит. Если Git просит user.name и user.email, настройте их по инструкции Git перед повтором.

Не передавайте Codex команду «закоммить все», пока не посмотрели список файлов. В папке могут оказаться .env, ключи или временные данные.

Хорошая первая правка имеет видимый результат и узкую область. Например:

Прочитайте план. Если затронуты неожиданные файлы, спросите почему. Только затем разрешайте изменение.

Codex может запросить выполнение команды. Смотрите не только на саму команду, но и на рабочую директорию и цель. Не повышайте разрешения по привычке. Особенно осторожно относитесь к установке пакетов, сетевым запросам и операциям удаления.

После изменения не ограничивайтесь сообщением агента. В другом окне терминала выполните:

Команды по порядку: git status и git diff.

Убедитесь, что изменены только согласованные файлы. Затем запустите команду, которую проект уже использует для тестов, линтера или сборки. Не копируйте случайную команду из статьи: точное имя зависит от репозитория.

В интерфейсе Codex можно запросить отдельное ревью через:

В интерфейсе используется команда /review.

Попросите проверить именно текущий diff на ошибки, регрессии и несоответствие исходной задаче. Ревью дополняет тесты, но не заменяет ручной просмотр.

Если результат плохой, не удаляйте всю папку. Укажите конкретное расхождение или верните только текущую правку средствами Git после проверки списка файлов.

/init помогает создать AGENTS.md с инструкциями проекта. Заполняйте его реальными командами и правилами, а не общими пожеланиями.

codex resume возвращает к сохраненной сессии. Это полезно, когда работа продолжается в том же проекте.

codex exec предназначен для неинтерактивных сценариев и автоматизации. Не начинайте с него: сначала отработайте задачу вручную и поймите необходимые разрешения.

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

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

Если проект уже имеет коммиты, воспроизводимая исходная точка проста:

Команды по порядку: git status и git rev-parse --short HEAD.

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

Если репозиторий новый и коммитов нет, сначала запустите проект вручную и убедитесь, что исходная версия работает. Проверьте .gitignore, особенно .env, ключи, зависимости и сборочные каталоги. Затем добавьте только ожидаемые исходники, посмотрите git status и создайте первый коммит. Не используйте слепое git add ., пока не прочитали список.

После изменения ссылки откройте страницу вручную. Проверьте текст, адрес, работу перехода и отсутствие неожиданных изменений рядом. Затем запустите существующую команду теста или сборки. Если ссылка ведет не туда, дайте узкую обратную связь: «Текст правильный, но href должен быть /docs, а сейчас /documentation. Исправь только href и повтори прежнюю проверку».

Снова выполните:

Команды по порядку: git status и git diff.

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

Если codex --version не работает после установки, откройте новый терминал и посмотрите финальное сообщение установщика. Проверьте, где находится бинарный файл и входит ли этот каталог в PATH. Не скачивайте случайный пакет с похожим именем из неофициальной инструкции.

Если Codex открыл не тот проект, завершите сессию, выполните pwd, перейдите в нужную директорию и запустите снова. Не пытайтесь исправить ошибочную рабочую папку промптом: граница должна задаваться окружением.

Если агент предлагает слишком много файлов, не подтверждайте план частично молча. Попросите сократить решение до одного пользовательского результата и объяснить каждый дополнительный файл. Если задача действительно требует рефакторинга, вынесите его в отдельную сессию после первой рабочей версии.

Если тест не запускается, отделите ошибку окружения от ошибки кода. Зафиксируйте точную команду и первые значимые строки вывода. Попросите объяснить причину без новых изменений. Только после согласованного диагноза разрешайте исправление.

Если появился неожиданный секрет или .env в diff, остановитесь и удалите его из набора изменений до коммита. Считайте опубликованный ключ скомпрометированным и замените его у провайдера; простого удаления из последнего файла недостаточно, если секрет уже попал в историю или внешний сервис.

После первой успешной правки сохраните короткую памятку проекта: команда запуска, тест, сборка и каталоги, которые нельзя менять без согласования. Ее можно оформить в AGENTS.md через /init, но содержание нужно проверить вручную. Такая инструкция уменьшит число уточнений в следующих сессиях и не даст агенту угадывать базовые команды заново.

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

CLI сам по себе не учит работать с Git, окружением, базой данных и деплоем. Если вам нужен полный маршрут от первой программы до сервера, на курсе «Вайбкодинг на максималках» отдельно разбираются Git и GitHub, настройка Codex и VS Code, permissions, rules, базовый цикл фичи, Docker, база данных и защита проекта.

После этого гайда у вас должен получиться короткий воспроизводимый цикл:

1. Открыть конкретный репозиторий.

2. Проверить git status.

3. Попросить Codex сначала объяснить проект.

4. Согласовать одну маленькую правку.

5. Посмотреть git diff.

6. Запустить проверку и /review.

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

Сохраните этот цикл как привычку для каждой новой задачи.