GitHub объявил о завершении поэтапного внедрения stateless-формата токенов установки для GitHub App. Начиная с 2 октября 2026 года, все новые токены установки GitHub App по умолчанию выдаются в stateless-формате ghs_APPID_JWT. Это изменение, анонсированное ещё 27 апреля 2026 года, теперь действует для всех приложений без исключения.
Что изменилось
Новый формат токенов кардинально отличается от прежнего. Если раньше токен установки GitHub App представлял собой строку длиной 40 символов с префиксом ghs_, то теперь его длина составляет около 520 символов. При этом токен по-прежнему начинается с ghs_, но внутри содержит идентификатор приложения (APPID) и JWT-часть.
Ключевое преимущество stateless-формата — токен не требует обращения к базе данных для проверки. Валидация выполняется на стороне GitHub API без дополнительных запросов к хранилищу состояний, что ускоряет как выпуск токенов, так и их проверку. GitHub прямо указывает, что это повышает надёжность API.
Что не изменилось
Для разработчиков, использующих GitHub App в своих рабочих процессах, большинство аспектов остались прежними:
- Права доступа токенов и привязка к репозиториям не изменились
- Срок действия токена — один час — остался без изменений
- REST API endpoint для получения токена установки работает как и раньше
- Токены, выпущенные до перехода, продолжают работать до истечения срока действия
Что нужно сделать разработчикам
GitHub ввёл временный HTTP-заголовок X-GitHub-Stateless-S2S-Token, который позволял разработчикам принудительно запрашивать stateless-токен для тестирования ещё до завершения rollout. Этот заголовок будет удалён 30 ноября 2026 года. После этой даты GitHub перестанет учитывать заголовок, и все приложения, поддерживающие stateless-формат (а теперь — все), будут получать токены только в новом формате.
Разработчикам рекомендуется:
Проверить, что все системы, обрабатывающие токены установки, работают с ними как с непрозрачными строками (opaque strings). Это означает, что код не должен полагаться на длину токена, его внутреннюю структуру или наличие определённых символов.
2. Убедиться, что приложения и рабочие процессы корректно работают с токенами обоих форматов — старыми (40 символов) и новыми (520 символов).
3. До 30 ноября 2026 года удалить заголовок X-GitHub-Stateless-S2S-Token из production-кода, если он использовался для принудительного получения stateless-токенов.
Почему это важно для разработчиков AI-агентов и инструментов
Для читателей COMRAD404, работающих с AI-агентами, автоматизацией и CI/CD, это изменение имеет прямое практическое значение. Многие AI-агенты и инструменты на базе MCP (Model Context Protocol) используют GitHub App токены для доступа к репозиториям, управления issues, pull request и code review. Stateless-формат уменьшает задержки при инициализации сессий агентов, поскольку токен не требует проверки состояния на стороне сервера.
Это особенно актуально в контексте недавнего перехода на stateless MCP (спецификация 2026-07-28), который также упрощает реализацию клиентов и серверов. GitHub, по сути, применяет ту же логику к своей инфраструктуре токенов — уменьшение зависимости от состояния ускоряет и упрощает взаимодействие.
Практическая проверка для разработчиков
Если вы используете GitHub App в своих проектах, вот минимальный набор проверок:
- Выполните тестовый запрос на получение токена установки через API. Убедитесь, что ответ содержит токен длиной около 520 символов.
- Проверьте, что ваш код не делает предположений о длине токена. Если в коде есть проверка типа len(token) == 40 или аналогичная, её нужно заменить.
- Если вы использовали заголовок X-GitHub-Stateless-S2S-Token для тестирования, удалите его из production-конфигурации до 30 ноября.
GitHub также напоминает, что токены следует рассматривать как непрозрачные строки: не пытайтесь парсить их содержимое, не полагайтесь на определённые символы или структуру внутри токена. Единственное, на что можно полагаться — это префикс ghs_, который остаётся неизменным.
Ограничения и что ещё стоит проверить
Хотя GitHub заявляет, что переход завершён, разработчикам, использующим кастомные интеграции или устаревшие библиотеки для работы с GitHub API, стоит провести дополнительное тестирование. Некоторые старые библиотеки могли неявно полагаться на фиксированную длину токена. Если ваша интеграция использует стороннюю библиотеку для GitHub App, проверьте, что она поддерживает новый формат.
GitHub не сообщает о каких-либо известных проблемах совместимости, но рекомендует провести валидацию всех систем до 30 ноября 2026 года — даты окончательного удаления временного заголовка.
Для тех, кто использует GitHub Actions или Copilot в enterprise-средах, это изменение не должно вызвать проблем, так как эти сервисы уже обновлены для работы с новым форматом. Однако для кастомных GitHub App, особенно тех, что используются в AI-агентах и MCP-серверах, проверка обязательна.
