Как подключить Codex к GitHub и безопасно работать с private-репозиторием

Вы хотите поручить Codex небольшую правку в проекте. Но при подключении GitHub видите список репозиториев и запрос разрешений. Что выбрать, чтобы агент получил нужный код, а остальные проекты остались вне этой задачи?

Начните с отдельного учебного private-репозитория без рабочих ключей и клиентских данных. Подключите только его, попросите Codex изучить файлы без изменений и сверьте ответ с README. Затем разрешите одну небольшую правку в отдельной ветке. Результат первого запуска: понятный diff, реальный результат теста и решение человека о том, можно ли принимать изменение.

Private означает ограниченную видимость репозитория. Этот статус сам по себе не запрещает агенту менять файлы и не защищает от ошибки в коде.

Codex web, или облачный Codex, работает в удалённой среде. Для задач с GitHub вы подключаете аккаунт и настраиваете environment для выбранного репозитория. Файлы и команды выполняются в облачной среде, а результат задачи можно проверить перед созданием pull request.

Codex CLI работает на вашей машине, в выбранном каталоге. Ему достаточно локальной копии проекта для чтения и редактирования. Доступ к GitHub понадобится Git-клиенту для clone, fetch и push. Вход в Codex и авторизация GitHub решают разные задачи: успешный вход в Codex не доказывает, что Git может открыть ваш private repo.

Если проект уже лежит на компьютере, проще начать с CLI. Если хотите передавать задачи в облако, настройте Codex web. Условия доступности функций зависят от аккаунта и рабочего пространства; тарифы в этой инструкции не фиксируем. Актуальный порядок запуска есть в документации Codex CLI и Codex web.

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

До запуска агента проверьте:

• Вы знаете, какая ветка основная и какой файл хотите изменить.
• README содержит действительную команду проверки, которую вы можете запустить сами.
• В проекте нет незавершённых чужих изменений, которые легко спутать с работой Codex.
• Секреты не отслеживаются Git. Правила .gitignore не действуют задним числом на уже отслеживаемые файлы.
• Вы понимаете, кто сможет принять pull request.

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

В рабочем репозитории настройте требование pull request, одобрения и нужные проверки CI. Проверьте исключения: кто может обойти правила. Доступность защиты private-веток зависит от плана GitHub и типа аккаунта. Если нужной защиты нет, не называйте ветку защищённой: используйте учебный проект, ручную проверку и договорённость не отправлять изменения прямо в основную ветку. Возможности описаны в документации protected branches.

1. Откройте Codex под нужным аккаунтом и начните штатное подключение GitHub. Не передавайте токен в текст задачи.
2. Проверьте, для какого владельца устанавливается приложение: личного аккаунта или организации. Если организация требует одобрения, дождитесь решения администратора.
3. Когда GitHub предлагает область доступа, выберите Only select repositories и укажите учебный проект. Не выбирайте все репозитории ради одной задачи.
4. Прочитайте список permissions до подтверждения. GitHub App запрашивает определённый набор прав: пользователь не может произвольно убрать отдельное обязательное разрешение. Если права неприемлемы, остановите установку и обсудите другой способ работы.
5. Вернитесь в Codex и настройте environment для этого репозитория. Проверьте исходную ветку и команды подготовки зависимостей. Названия экранов могут меняться; ориентируйтесь на смысл настройки, а не на положение кнопки.
6. В GitHub откройте Settings → Applications → Installed GitHub Apps и проверьте итоговый Repository access. Для установки организации используйте её настройки и права администратора.

Настройка приложения действует на выбранную установку, а не только на текущую задачу. Другие установки и авторизации могут иметь отдельный доступ. Кроме того, GitHub отмечает: репозитории, которые создаёт само приложение, могут автоматически добавляться к доступным ему репозиториям. Поэтому выбор одного проекта не стоит описывать как вечную гарантию доступа ровно к одному repo. Периодически проверяйте настройки установленного GitHub App.

Сеть и секреты облачной среды

В Codex cloud setup-скрипты выполняются с доступом к интернету. Для агентной фазы интернет по умолчанию выключен; при необходимости можно настроить доступ. Разрешайте только то, что нужно задаче: внешние страницы и зависимости могут содержать вредоносные инструкции, а сетевой доступ создаёт риск передачи кода наружу.

Обычные environment variables доступны и подготовке, и агентной фазе. Поле secrets устроено иначе: значения доступны setup-скриптам и удаляются до начала агентной фазы. Это не защита от ошибок самого setup-скрипта. Не печатайте секреты в логи и не сохраняйте их в файлы, которые затем читает агент. Подробнее: cloud environments и agent internet access.

Для CLI сначала установите сам Codex по официальной инструкции и выполните штатный вход. Для private GitHub-проекта отдельно настройте Git через одобренный вашей командой SSH-ключ или менеджер учётных данных HTTPS. Не вставляйте credentials в URL репозитория, командную строку или prompt.

Клонируйте проект обычным Git-клиентом либо откройте уже существующий клон. Команду клонирования берите на странице именно вашего репозитория; не копируйте чужое имя владельца из примера. Ниже все команды выполняются в корневом каталоге локального проекта:

git status
git switch -c codex/safe-first-change

Первая команда помогает увидеть текущую ветку и состояние файлов. Если дерево не чистое, остановитесь и разберитесь, кому принадлежат изменения. Не используйте reset или очистку файлов только ради продолжения инструкции. Вторая команда создаёт новую локальную ветку и переключает на неё. Если такое имя уже занято, выберите другое осмысленное имя; не удаляйте существующую ветку вслепую.

Запустите Codex из этого каталога штатной командой «codex». Проверьте каталог работы и настройки sandbox/approval в установленной версии. Для первого чтения используйте доступный режим без записи. Сам текст «ничего не меняй» полезен как инструкция, но не является технической блокировкой записи. Не отключайте ограничения, чтобы быстрее пройти настройку.

Команды входа, запуск Codex и доступ к вашему private repo здесь не проверены от вашего имени. Ниже отдельно описан локальный тест команд Git без сети и без учётных данных.

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

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

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

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

Для локального проекта проверьте состояние и изменения самостоятельно:

git status
git diff

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

git diff --cached

Когда вы проверили нужный файл и решили включить его в будущий commit, добавляйте его по точному пути. Например, для правки документации:

git add README.md
git diff --cached

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

Для этой статьи команды Git воспроизведены в отдельном временном репозитории: создана ветка, изменён README, проверены unstaged и staged diff. Учебный Python-тест также запущен. Сетевых операций, авторизации и отправки в GitHub не было. Этот тест проверяет редакционный пример, а не ваш проект.

После проверки создайте commit и pull request принятым в вашей команде способом. В описании PR укажите задачу, что изменилось, какие проверки выполнены и что осталось непроверенным. Для облачной задачи сначала изучите показанный Codex diff, затем переходите к оформлению PR.

Перед merge уполномоченный человек проверяет актуальный diff и статусы CI. Если после одобрения появились новые изменения, нужна повторная проверка. Автоматическое ревью, в том числе от Codex, может подсказать проблемы, но не должно быть единственным основанием для принятия первого изменения.

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

Облачный Codex не видит репозиторий

Проверьте аккаунт GitHub, владельца установки, Repository access и выбранный environment. Для организации уточните, не ожидается ли одобрение администратора. Не делайте репозиторий публичным, чтобы обойти ошибку доступа. Отсутствие repo в списке не доказывает, что его удалили.

Локальный Git сообщает Repository not found или Permission denied

Сначала убедитесь, что адрес и имя владельца верны, затем проверьте доступ текущего GitHub-аккаунта. Для SSH и HTTPS используются разные способы авторизации; успешный вход в Codex их не исправляет. Если в организации действует SSO, проверьте её требования с администратором. Не публикуйте полный отладочный лог без удаления credentials и приватных данных.

Ветка уже существует или переключение не удалось

Проверьте git status. Существующее имя ветки и незавершённые локальные изменения требуют разных решений. Выберите новое имя либо осознанно продолжите нужную ветку после проверки. Не применяйте force, reset или удаление файлов по первой подсказке агента.

Diff пустой, хотя Codex написал «готово»

Проверьте каталог, git status и git diff --cached. Возможно, файл уже в staging area, новый файл ещё не отслеживается либо агент работал в другой копии проекта. Попросите точные пути и реальный результат проверки. Если изменений нет, не оформляйте пустой PR ради отчёта.

Тесты не запустились

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

В файле или логе появился секрет

Остановите commit, push и merge. Если секрет попал в доступное посторонним место, прежде всего отзовите или замените его у провайдера и проверьте использование. Удаление строки новым commit не обезвреживает старое значение. .gitignore не удаляет файл из истории. Очистку истории согласуйте отдельно: она влияет на клоны и ветки других участников. См. документацию gitignore.

Проверьте, нужен ли приложению дальнейший доступ. В настройках GitHub App можно изменить список репозиториев, приостановить или удалить установку. Личная авторизация приложения отдельна от установки: при прекращении работы проверьте и её. Удаление локального клона само по себе не отзывает GitHub-ключ или другую авторизацию Git.

Вы знаете, где работает Codex, какой репозиторий ему доступен и какие права вы выдали. Первая правка находится в отдельной ветке, её diff прочитан человеком, тесты действительно выполнены, а ограничения записаны в PR. До merge остаётся понятное решение ответственного участника команды.

Для следующего упражнения выберите маленькую задачу из своего проекта и повторите тот же цикл: чтение, план, изменение, проверка. Если нужна последовательная практика работы с Codex и Hermes Agent, посмотрите программу воркшопа Человек 2.0. А смежные инструкции можно найти в базе статей Человек 2.0. Перед выбором обучения проверьте актуальную программу и условия на странице.