GitHub MCP: как дать агенту доступ к репозиторию без лишних прав

GitHub MCP позволяет агенту читать код в репозитории и менять его, если вы разрешили. Начните с официального github/github-mcp-server, отдельного токена для своего проекта и режима только чтения. Сначала проверьте, что агент читает нужный файл.

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

Зачем агенту GitHub MCP и почему не надо разрешать всё

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

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

Общий обзор плагинов Claude Code - в отдельной статье.

Если собираете своего ИИ-агента, загляните в мои каналы:

Шаг 1. Выберите сервер GitHub, свой проект и файл

Берите сервер из проекта github/github-mcp-server. Проверьте владельца github, параметры подключения сверяйте с README.

Будем подключать удалённый сервер https://api.githubcopilot.com/mcp/ в VS Code версии 1.101 или новее. Локально запускать сервер не нужно.

Если клиент не поддерживает удалённый MCP, этот же сервер можно запустить локально. Для контейнера нужен работающий Docker; образ - ghcr.io/github/github-mcp-server. Пример ниже относится к удалённому подключению.

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

• OWNER - владелец проекта;
• REPO - имя репозитория;
• PATH - путь к файлу;
• REF - его ветка.

В запросах замените OWNER, REPO, PATH и REF своими значениями. Публиковать проект для проверки не нужно.

Шаг 2. Создайте отдельный токен с правом чтения

В GitHub откройте Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token. Задайте имя и выберите Expiration - срок действия.

Resource owner - свой аккаунт. Repository access - Only select repositories и выбранный проект. В Permissions установите Contents: read для чтения файла. Остальные разрешения не повышайте: запись в Issues и Pull requests для этой задачи не нужна.

PAT храните как пароль: не отправляйте агенту, не показывайте на снимках экрана, не сохраняйте в коммите или открытом файле настроек. В конце упражнения этот токен удалите; отдельный PAT позволит не затронуть другие задачи.

Что именно мы ограничили

Обещание «агент увидит ровно этот репозиторий и больше ничего» неверно. Публичный файл может читаться и без авторизации. Поэтому для проверки выбран приватный проект.

Для проекта организации проверьте Resource owner и одобрение PAT. До одобрения может работать только публичное чтение. Политика организации также может запрещать такие токены; расширение разрешений запрет не исправит.

Шаг 3. Подключите GitHub MCP в VS Code только на чтение

В настройках MCP вашего VS Code добавьте конфигурацию ниже. Для других клиентов, в том числе Claude Desktop, она может отличаться.

Если работаете в Claude Code, его MCP-подключения разобраны в отдельной статье.

{
"servers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer ${input:github_mcp_pat}",
"X-MCP-Readonly": "true"
}
}
},
"inputs": [
{
"type": "promptString",
"id": "github_mcp_pat",
"description": "GitHub Personal Access Token",
"password": true
}
]
}

Authorization оставьте как в примере. PAT введите по запросу клиента. password: true относится к полю ввода, а не к защите хранения токена.

X-MCP-Readonly: "true" оставляет только инструменты чтения. Не смешивайте настройки разных способов запуска:

Не переносите GITHUB_READ_ONLY в HTTP-заголовки. Для удалённого сервера есть также путь /readonly, но здесь оставьте заголовок. Подробнее - в документации GitHub.

toolsets и tools выбирают доступные агенту инструменты, но не меняют права PAT. Не пытайтесь оставить только чтение, просто добавив get_file_contents: у локального сервера списки инструментов и наборов складываются. Если наборы не указаны, действуют стандартные. Здесь достаточно read-only.

Шаг 4. Запустите подключение и посмотрите инструменты

Запустите подключение средствами VS Code. Поручите агенту:

Покажите инструменты подключённого GitHub MCP. Пока ничего не вызывайте и не меняйте.

Сами откройте список инструментов этого подключения в клиенте. Нужен get_file_contents, инструментов записи быть не должно. Ответ модели «всё подключено» эту проверку не заменяет.

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

Шаг 5. Прочитайте конкретный файл и сверьте результат

Подставьте выбранные значения в запрос:

Через GitHub MCP вызовите get_file_contents: owner=OWNER, repo=REPO, path=PATH, ref=REF. Прочитайте этот существующий файл, укажите путь и ветку. Ничего не меняйте; не используйте локальный файл вместо вызова MCP.

В ответе должно быть содержимое выбранного приватного файла. Проверьте вызов инструмента: аргументы и ответ сервера. Сверьте путь, ветку и текст с файлом в GitHub.

Для последней сверки поручите:

Покажите, какие инструменты записи доступны именно у этого подключения; ничего не выполняйте.

Затем вручную проверьте разрешения PAT в GitHub. Список инструментов сервера и права токена сверяются отдельно. Не проверяйте защиту попыткой удалить или изменить файл.

В get_file_contents предусмотрен также sha: не задавайте его, он используется вместо ref. Ветку передайте явно, иначе берётся ветка по умолчанию.

Для дополнительной проверки можно взять другой собственный приватный проект, не выбранный в PAT. В этом упражнении такая проверка необязательна. Чужие проекты не используйте.

Шаг 6. Отзовите токен и повторите обращение к файлу

В GitHub откройте Settings → Developer settings → Personal access tokens → Fine-grained tokens. Нажмите Delete справа от созданного для упражнения PAT. Сверьте имя перед удалением: удаление записи подключения в клиенте сам токен не отзывает.

Поручите агенту:

Сделайте новый вызов get_file_contents для того же OWNER, REPO, PATH и REF через это подключение GitHub MCP. Не отвечайте по прошлому сообщению или локальному файлу. Покажите результат нового вызова без токена.

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

Старый текст в переписке не подтверждает отзыв. Если нового вызова не видно, проверка не завершена. Чтение публичного файла тоже не подходит: он доступен и без PAT.

Кстати, я снял ролик «Полный гайд - Связка для первого агента Hermes Agent» о подключениях и правах агента, обязательно посмотрите.

В нём я показал, как выбирать подключения и права агента и как не поставить вредный MCP.

Сохраните карточку упражнения: проект, путь, ветка; разрешения PAT; список инструментов без записи; ответ чтения и новый ответ после удаления PAT. Токен не записывайте. Если нового вызова после удаления не видно, переходите к диагностике.

Если вы собираете свои проекты с ИИ-агентами, посмотрите программу практикума СмыслоКода.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - инструменты, метод, первый проект

Старт 17–19 ноября  ·  2 000 ₽

Записаться →

Если не работает: проверьте соединение, токен и новый вызов

Не повышайте разрешения наугад.

Если добавляли X-MCP-Tools, сверьте имена: недопустимое имя мешает запуску. Неизвестные наборы в X-MCP-Toolsets игнорируются, поэтому проверяйте сам список инструментов. При запуске контейнера проверьте Docker.

Не переключайте PAT на All repositories и не выдавайте запись из-за ошибки чтения. Если новый вызов после удаления PAT вернул приватный файл, проверьте, с какой авторизацией он сделан.

Если позже понадобится запись, разрешите только нужное действие

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

Для создания или обновления обычного файла через REST API требуется Contents: write. Для .github/workflows дополнительно может понадобиться Workflows: write. Из этого не следуют права записи в Issues и Pull requests: проверяйте разрешения конкретной операции.

Права записи у PAT не возвращают серверу инструменты записи при read-only. Снятие read-only не даёт токену write-прав. Проверять нужно оба ограничения. В этом упражнении их не меняйте.

О доступе Claude Code к своим данным читайте в отдельной статье.

Вопросы и ответы

Оставьте агенту только то, что по-настоящему нужно

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

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

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - инструменты, метод, первый проект

Старт 17–19 ноября  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

Подписаться в Telegramили на email