Какой GitHub-токен нужен Codex и Hermes и где его хранить

Выберите доступ к GitHub для Codex и Hermes: когда нужен PAT, какие права дать одному репозиторию, где хранить секрет и как проверить настройку без утечки.

Агент уже умеет менять файлы, но при обращении к GitHub получает отказ. В этот момент легко выдать ему доступ ко всем репозиториям, лишь бы заработало. Начните с двух вопросов: к какому сервису он обращается и какое действие должен выполнить.

Короткий ответ: отдельного универсального «токена для Codex и Hermes» нет. Вход в модель и доступ к репозиторию на GitHub настраиваются отдельно. Для поддерживаемой интеграции используйте её штатное подключение. Если нужен персональный токен, выбирайте fine-grained PAT с нужным владельцем, выбранными репозиториями, ограниченными разрешениями и сроком действия. Долгоживущую интеграцию организации лучше строить через GitHub App. [1–5]

Codex CLI может обращаться к моделям OpenAI после входа через ChatGPT или с API-ключом. GitHub PAT не заменяет эти способы входа. У Codex cloud есть отдельное подключение GitHub: локальный токен в терминале сам по себе не настраивает облачную среду. [4, 11]

В Hermes провайдер модели тоже настраивается отдельно. Например, подключение подписки ChatGPT или Codex использует собственную авторизацию. GitHub-доступ нужен инструментам, которыми агент читает репозиторий, отправляет коммиты или создаёт pull request. [5]

GitHub Copilot является отдельным случаем: это провайдер моделей с собственными требованиями к авторизации. Токен для чтения кода не следует считать подходящим для Copilot. Настраивайте его по текущей документации Hermes, а права на репозиторий проверяйте отдельно. [5]

Создание локальной ветки, редактирование файла и локальный коммит обычно не требуют входа на GitHub. Сеть и удалённые права понадобятся при обращении к серверу. В конкретном проекте локальные hooks могут выполнять дополнительные действия, поэтому перед запуском незнакомого проекта проверьте его настройки.

Подготовьте учётную запись GitHub с доступом к нужному репозиторию, установленный Git и, если будете работать через него, GitHub CLI (gh). Определите, где работает агент: на вашем компьютере, на VPS, в контейнере или в облачной среде Codex. Авторизация одного окружения не доказывает доступ из другого.

Запишите задачу без секретов. Например: «Агент читает один приватный репозиторий, отправляет изменения в отдельную ветку и открывает pull request. Он не меняет права участников, настройки репозитория и секреты Actions».

Такой список помогает выбрать разрешения и проверить результат. Просьба «дать полный доступ для работы» не даёт проверяемой границы.

• Ситуация: Вы работаете локально через gh / С чего начать: Штатный браузерный вход GitHub CLI / Важное ограничение: OAuth-доступ может быть шире одного репозитория; это не замена узкому PAT по уровню ограничений
• Ситуация: Автоматизация обращается к выбранному репозиторию / С чего начать: Fine-grained PAT, если все нужные операции его поддерживают / Важное ограничение: Проверяйте разрешения каждого API endpoint и ограничения организации
• Ситуация: Интеграция работает от имени организации длительное время / С чего начать: GitHub App / Важное ограничение: Потребуются настройка приложения, установка и управление его доступом
• Ситуация: Git выполняет clone, fetch или push по SSH / С чего начать: SSH-ключ с подходящим доступом / Важное ограничение: SSH-доступ Git не авторизует REST API и команды gh автоматически
• Ситуация: Задача работает в GitHub Actions / С чего начать: Встроенный GITHUB_TOKEN с явными permissions / Важное ограничение: Он предназначен для workflow и ограничен репозиторием выполнения

GitHub рекомендует fine-grained PAT вместо classic PAT, когда нужный сценарий поддерживается. У fine-grained токенов есть ограничения совместимости: не расширяйте права наугад, если команда отказала. Сначала проверьте документацию операции. Classic PAT допустим при конкретной необходимости, но его широкие scopes требуют отдельного обоснования. [1]

Браузерный вход gh удобен для личной работы, однако он не обещает ограничение ровно одним проектом. SSH-ключ также нельзя по умолчанию считать узким: персональный SSH-ключ действует в рамках прав аккаунта. Для отдельного репозитория существуют deploy keys со своими ограничениями. [12]

Откройте GitHub Settings → Developer settings → Personal access tokens → Fine-grained tokens. Создавайте токен лично в доверенном браузере. Не отправляйте его агенту в чат для «помощи с настройкой».

1. Дайте токену понятное назначение. В названии достаточно указать проект и среду, без чувствительных данных.
2. Выберите Resource owner. Он должен соответствовать владельцу нужного репозитория.
3. Задайте срок действия по политике вашей команды. Не оставляйте бессрочный доступ ради удобства.
4. В Repository access выберите Only select repositories и нужный проект.
5. Разрешите только операции из записанной задачи. Если организация требует одобрения, дождитесь его. Состояние ожидания не означает, что приватный репозиторий уже доступен. [1]

Для чтения содержимого приватного репозитория начните с Contents: Read-only. Для отправки изменений понадобится Contents: Read and write. Создание pull request через REST API требует Pull requests: Write. Чтение pull request и работа с issues относятся к отдельным операциям. Не добавляйте управление администраторами, секретами или workflows, если этого нет в задаче. [6, 13]

Этот набор является отправной точкой для обычной работы с кодом, а не гарантией для любой команды. Изменение файлов workflows, работа с форками, правила защиты веток и политика организации могут добавить ограничения. Успешное чтение не подтверждает возможность push, а возможность push не отменяет защиту основной ветки.

Смысл иллюстрации: доступ складывается из отдельных разрешений. Точные настройки выбирайте по тексту и документации, это не снимок интерфейса GitHub.

Предпочитайте системное хранилище учётных данных или управляемую передачу секрета нужному процессу. GitHub CLI после браузерного входа использует системное credential store, но при его отсутствии или ошибке может записать токен в обычный текстовый файл. Поэтому «выполнил вход через gh» ещё не означает «получил защищённое хранилище». [2]

git credential-store тоже сохраняет данные без шифрования. Не используйте его как рекомендацию безопасного хранения по умолчанию. [8]

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

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

Для GitHub CLI переменная GH_TOKEN имеет приоритет над GITHUB_TOKEN и сохранёнными credentials. Это частая причина неожиданного аккаунта или отказа после успешного браузерного входа. Для fine-grained PAT документация gh auth login рекомендует GH_TOKEN, поскольку передача такого токена через --with-token может вести к неочевидным результатам на других ресурсах. [2, 3]

Сам Git не обязан читать GH_TOKEN. Доступ к Git по HTTPS настраивается через credential helper или другой поддерживаемый механизм. Успешная команда gh не доказывает, что Git использует те же credentials.

В GitHub Actions сначала рассмотрите встроенный GITHUB_TOKEN и явно задайте разрешения workflow. Для отдельного секрета используйте Actions secrets, но не передавайте его недоверенному коду. Обычные secrets не передаются workflow из fork pull request; встроенный токен имеет отдельные правила. Не обходите это ограничение переключением события на более привилегированное без анализа безопасности. [7, 14]

Секрет хранится отдельно от кода, переписки и публичных материалов. Иллюстрация объясняет принцип; она не показывает реальную схему доставки credentials.

Следующие команды показывают версии и справку. Они не создают токен, не выполняют вход и не меняют настройки авторизации:

git --version
gh --version
gh auth login --help
gh auth status --help
gh help environment
gh api --help
git ls-remote -h

Справка подтверждает наличие команды и её параметров, но не доступ к аккаунту. Если gh отсутствует, установите GitHub CLI по официальной инструкции для своей ОС. Для Git по SSH он не обязателен. Сообщение git ls-remote -h может завершаться ненулевым кодом после вывода usage; это не проверка сети.

Далее проверьте авторизацию самостоятельно в доверенном терминале. В этой редакционной проверке команды ниже подтверждены по документации, но не выполнялись с пользовательскими credentials:

gh auth status --hostname github.com
gh api --hostname github.com repos/OWNER/REPO --jq '.permissions'
git ls-remote https://github.com/OWNER/REPO.git HEAD

Замените OWNER и REPO на своего владельца и репозиторий. Первая команда показывает состояние авторизации и может содержать сведения об аккаунте. Не публикуйте её вывод целиком. Не добавляйте флаг показа токена. Вторая обращается к API выбранного репозитория. Поле permissions не является полным аудитом возможностей токена. Третья только читает удалённую ссылку HEAD; токен в URL не вставляется. [15, 16]

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

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

Не копируйте в отчёт git remote -v из неизвестного проекта без проверки: в старом remote URL может оказаться встроенный секрет. Не запускайте команды, которые печатают credentials, содержимое auth-файлов или все переменные окружения. Для совместной диагностики достаточно версии инструмента, кода ошибки, типа операции и обезличенного имени репозитория.

401 или Authentication failed. Проверьте срок действия, отзыв токена и то, какой credential реально выбирает текущий процесс. Старый GH_TOKEN может перекрывать новое сохранённое подключение. Не решайте это выдачей дополнительных прав.

403. Проверьте разрешения операции, политику организации, требование одобрения и ограничения типа токена. У classic PAT для организации с SAML SSO может требоваться отдельная авторизация. По одному статусу нельзя поставить окончательный диагноз. [1]

404 у приватного репозитория. Проверьте имя, владельца, выбранные репозитории и доступ учётной записи. Ответ может означать отсутствие видимости для текущих credentials; он не доказывает, что репозиторий удалён. [17]

Чтение работает, push запрещён. Проверьте write-разрешение, ветку, правила защиты и транспорт Git. Токен не даёт больше прав, чем есть у его владельца, и не отменяет правила репозитория. [1, 13]

В терминале работает, у агента нет. Сравните машину, пользователя ОС, контейнер, профиль и способ запуска. Сервис мог не получить переменные интерактивного shell. Исправляйте передачу нужного секрета нужному процессу, не рассылайте значение по конфигурациям «на всякий случай».

Считайте его раскрытым. Отзовите токен в настройках GitHub, создайте новый с минимальными правами и обновите только те места, где он нужен. Удаление сообщения, файла или последнего коммита не делает старый токен безопасным. [1, 18]

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

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

Можно ли использовать один токен для Codex и Hermes?

Если оба процесса выполняют одинаковые GitHub-операции, технически они могут использовать один credential. Для разных сред и задач отдельные токены обычно удобнее: проще ограничивать права, отслеживать назначение и отзывать доступ без остановки соседней задачи. Вход в модель при этом остаётся отдельным.

Достаточно ли добавить токен в .env?

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

Почему не дать classic PAT со всеми scopes?

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

Как понять, что всё настроено?

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

Посмотрите материал о совместной работе Codex и Hermes, чтобы связать доступ к репозиторию с задачами агента. Если агент будет работать на сервере, пригодится гайд по установке Hermes Agent на VPS. Настройку модели проверяйте отдельно: GitHub PAT не заменяет её авторизацию.

Перед реальной задачей согласуйте три вещи: разрешённый репозиторий, допустимые действия и место хранения credential. Начните с чтения и переходите к записи только после проверки ограничений.

Проверено 17 сентября 2026 года. Повторная проверка CLI/API требуется через 30 дней или раньше при изменении документации.

• [1] GitHub: управление personal access tokens.
• [2] GitHub CLI: gh auth login.
• [3] GitHub CLI: переменные окружения.
• [4] OpenAI: авторизация Codex.
• [5] Hermes Agent: провайдеры моделей.
• [6] GitHub REST: создание pull request.
• [7] GitHub Actions: встроенный токен.
• [8] Git: credential-store.
• [11] OpenAI: Codex cloud.
• [12] GitHub: deploy keys.
• [13] GitHub: permissions для fine-grained PAT.
• [14] GitHub Actions: использование secrets.
• [15] GitHub CLI: gh auth status.
• [16] Git: ls-remote.
• [17] GitHub REST: ошибки API.
• [18] GitHub: удаление чувствительных данных.