Gemini CLI: как установить агент и выбрать актуальный способ доступа

Gemini CLI - агент для разработки, который работает в терминале. Он читает файлы выбранного проекта, объясняет код, предлагает изменения и запускает команды после разрешения пользователя.

С 18 июня 2026 года Gemini CLI перестал обслуживать запросы бесплатных индивидуальных аккаунтов и подписчиков Google AI Pro и Ultra. Для них Google перенес терминальную работу в Antigravity CLI. Gemini CLI остается доступен через поддерживаемые API-ключи, Google Cloud и корпоративные лицензии Gemini Code Assist.

Ниже установим Gemini CLI, проверим окружение и выполним первую небольшую задачу под контролем Git.

На момент проверки официальный установочный гайд рекомендует Node.js 20 или новее. Также понадобятся терминал, поддерживаемый способ авторизации и отдельная папка проекта.

Проверьте Node.js и npm:

Команды по порядку: node --version и npm --version.

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

Для работы с реальным проектом установите Git:

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

Git не является частью Gemini CLI, но дает независимый способ увидеть и отменить изменения.

Официальная команда глобальной установки через npm:

npm install -g @google/gemini-cli

После завершения проверьте версию:

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

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

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

Gemini CLI получает контекст из текущего каталога. Поэтому перед запуском выполните:

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

На Windows PowerShell аналогично проверьте Get-Location и Get-ChildItem.

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

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

В папке проекта запустите:

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

Интерфейс предложит способ авторизации. Обычный вход личным Google-аккаунтом больше не является рабочим вариантом для free, Google AI Pro и Ultra. Для Gemini CLI используйте поддерживаемый API-ключ, Google Cloud или корпоративную лицензию Gemini Code Assist. Владельцам индивидуальных аккаунтов нужно перейти на Antigravity CLI по официальной инструкции Google.

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

После входа не начинайте с команды «перепиши приложение». Сначала проверьте, что агент видит нужную папку.

Дайте запрос:

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

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

До первой правки еще раз выполните:

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

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

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

Выберите изменение, которое видно вручную. Например:

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

Gemini CLI может попросить разрешение на запись или выполнение команды. Смотрите на эффект:

• чтение файлов обычно подходит для анализа;

• запись должна оставаться в согласованных файлах;

• тест должен быть известен проекту;

• установка пакета меняет зависимости и lock-файл;

• сетевой запрос отправляет или получает внешние данные;

• удаление требует отдельной проверки.

После завершения откройте второй терминал:

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

Проверьте измененные и новые файлы. Обычный git diff не показывает содержимое untracked-файлов, поэтому прочитайте их отдельно до добавления в Git.

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

Откройте приложение и проверьте пользовательский результат. Если текст появился не там, сформулируйте узкую коррекцию. После исправления повторите те же проверки.

Перед коммитом добавляйте точные пути:

Команды по порядку: git add path/to/file и git diff --cached.

Только когда staged diff соответствует задаче, создавайте коммит.

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

Gemini CLI поддерживает контекстные файлы и команды для настройки проекта. Генерируемую инструкцию нужно прочитать вручную. Удалите общие фразы и оставьте только проверяемые сведения из репозитория.

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

Стоимость и квоты зависят от способа доступа. API-ключ может оплачиваться по фактическому использованию, а Google Cloud и корпоративная лицензия имеют собственные условия. Перед первой задачей проверьте, какой проект оплачивает запросы, какие лимиты установлены и кто получит уведомление о перерасходе.

Если CLI сообщает об исчерпании лимита, не пытайтесь обходить его множеством аккаунтов. Сверьте выбранный метод авторизации, права ключа и актуальные условия. Владельцам индивидуальных free, Pro и Ultra аккаунтов нужно использовать Antigravity CLI, а не искать старый способ входа в Gemini CLI.

Отдельно следите за расходами внешних инструментов. Агент может вызвать облачный API, создать ресурс или запустить длительную команду. Доступ к модели не делает бесплатными связанные сервисы.

gemini: command not found обычно означает проблему установки или PATH. Проверьте вывод npm и откройте новый терминал.

Ошибка входа может означать, что выбран больше не поддерживаемый индивидуальный Google-аккаунт. Сначала сверьтесь с официальным объявлением от 18 июня 2026 года, затем проверьте права API-ключа, Google Cloud project или корпоративной лицензии. Не удаляйте каталоги конфигурации наугад.

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

Если после правки появился большой diff, отделите изменение кода от автоформатирования и окончаний строк. Отмените лишнее до продолжения.

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

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

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

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

Если агент хочет создать новые файлы, заранее назовите ожидаемые пути. После выполнения git status покажет их как untracked, а обычный diff не покажет содержимое. Откройте каждый файл до staging.

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

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

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

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

Перед обновлением сохраните чистое состояние проекта и проверьте текущую версию через gemini --version. Используйте официальный способ обновления для вашего метода установки.

После обновления повторите короткую приемку: вход, read-only анализ, запрос разрешения, малая правка и diff. Не начинайте сразу с критичной задачи. Если поведение изменилось, зафиксируйте версию, команду и минимальный воспроизводимый пример для обращения к документации или issue tracker.

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

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

Проверяйте ее перед каждым новым потоком.

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

Для проекта с базой, API, Docker и публикацией нужен более широкий контекст, чем установка CLI. На курсе «Вайбкодинг на максималках» агенты для кода встроены в полный цикл разработки и деплоя.

Gemini CLI настроен правильно не тогда, когда он написал много кода, а когда вы можете воспроизвести каждое изменение и знаете, как вернуться назад. Для первого дня достаточно одной проверенной правки.