2 октября 2026 года GitHub объявил о завершении перехода токенов установленных GitHub Apps на формат stateless. Новые токены по умолчанию выпускаются в виде ghs_APPID_JWT. Заметное изменение — длина: вместо прежних 40 символов строка теперь содержит около 520.
Что изменилось в токенах GitHub Apps
Согласно анонсу GitHub от 2 октября, префикс ghs_ сохраняется. Разрешения токена, ограничение доступа выбранными репозиториями, срок действия в один час и REST API для его получения остались прежними. Уже выпущенные токены продолжают работать до истечения своего срока. GitHub связывает новый формат с ускорением выдачи и проверки токенов и повышением надёжности API, но не приводит в этом анонсе численных результатов производительности.
Компания также назвала дату прекращения поддержки временного заголовка X-GitHub-Stateless-S2S-Token: 30 ноября 2026 года. После этого GitHub перестанет учитывать его значение. Разработчикам предлагается проверить совместимость и убрать заголовок из рабочего кода до указанной даты.
Какие ограничения в интеграциях стоит проверить
Рекомендация GitHub — воспринимать токен как непрозрачную строку. Проверке подлежат валидаторы старого формата, поля хранения с небольшим пределом длины, промежуточные серверы, способные обрезать заголовок Authorization, и правила скрытия секретов в журналах. Ошибка может возникнуть ещё до обращения к API, если приложение отвергает строку только потому, что она длиннее ожидаемой.
Как проходил переход: контекст с точными датами
Это завершение миграции, начатой 27 апреля 2026 года, а не появление всей технологии 2 октября. В объявлении от 15 мая 2026 года GitHub описал временный механизм проверки совместимости: значение enabled в специальном заголовке запрашивало новый формат, а disabled — прежний. Выбор действовал для отдельного запроса выпуска токена.
В майском документе компания отдельно указала область перехода: GitHub Enterprise Cloud и среды с резидентностью данных. GitHub Enterprise Server этим изменением не затрагивался. Речь шла о серверных токенах установленных приложений, включая GITHUB_TOKEN в Actions. Поэтому переносить новость на любые персональные ключи доступа или все разновидности авторизации GitHub было бы неточно.
Майская инструкция предлагала испытать оба формата и затем отказаться от принудительного выбора. В ней уже отмечались дополнительные символы и увеличенная длина новой строки. Октябрьское сообщение добавляет к этому контексту два существенных факта: завершение основного развёртывания и конкретный срок отключения временного механизма.
Как выдача токена связана с правами приложения
Документация по созданию installation access token описывает прежнюю последовательность: приложение удостоверяет себя, определяет идентификатор установки и обращается к соответствующему REST-методу. В ответе возвращаются токен, время окончания действия и сведения о доступе. Обновление длины строки не означает расширения разрешений.
При выпуске можно ограничить набор репозиториев и прав, но нельзя предоставить токену доступ, которого нет у самой установки приложения. Если дополнительные ограничения не заданы, используются разрешённые установке репозитории и права приложения. Это различие важно для автоматизации: успешное получение токена и достаточные права на конкретную операцию — отдельные условия.
GitHub также указывает, что SDK Octokit может управлять получением и обновлением таких токенов после истечения срока. Использование SDK, однако, не отменяет проверки собственного хранилища и промежуточных компонентов, через которые проходит строка. Практический результат новости — необходимость убедиться, что вся интеграция принимает актуальный формат без обрезания и раскрытия секретов. Дата события — 2 октября; статья опубликована 3 октября 2026 года.
