С 27 октября 2026 года фоновых помощников и внутренние сервисы на базе GitHub Copilot можно запускать без привязки к личному аккаунту разработчика. В официальном анонсе GitHub открыл предварительный доступ к серверной авторизации для своего набора инструментов Copilot SDK: теперь программа обращается к нейросетям от имени всей организации, и отдельная пользовательская подписка ей не нужна. Главный подвох кроется в настройках доступа и оплаты. Чтобы сервис заработал на внешнем сервере, администратор выдаёт приложению право с безобидным названием Copilot Requests: Read-only («только для чтения»). Как прямо сказано в руководстве по управлению доступом, эта галочка не делает вызовы бесплатными — она разрешает списывать платные кредиты с общего баланса компании, причём поставить отдельный денежный потолок на одного конкретного бота система не позволяет.
Почему доступ «только для чтения» тратит общие деньги компании
Раньше любой фоновый скрипт — например, ночная проверка кода или разбор типовых ошибок — держался на учётной записи живого сотрудника. Стоило человеку выйти из системы или сменить пароль, как автоматизация останавливалась. Новая схема убирает человека из цепочки: запросы идут через приложение GitHub App, установленное на организацию, а все расходы и правила выбора моделей ложатся на компанию. Само название права Read-only (внутри ключа это поле organization_copilot_requests со значением read) означает лишь то, что бот не меняет настройки компании, а только читает ответы модели — но каждый такой ответ сжигает внутренний баланс AI credits.
У такого общего кошелька есть три жёстких ограничения, о которых предупреждает документация для администраторов:
- Нет лимита на одно приложение. Все подключённые боты тратят общий бюджет организации.
- Письма о перерасходе не останавливают траты. Чтобы система сама отрезала запросы после исчерпания лимита, в настройках бюджета нужно включить жёсткую остановку — Stop usage when budget limit is reached.
- Доступ работает только для организации. Установки на личный профиль или на весь холдинг уровня Enterprise этот способ не поддерживают. Приостановка установки мгновенно остановит запросы к моделям, но заодно отключит приложению доступ и к остальным ресурсам компании.
Два пути подключения и ошибка, из-за которой сервер не видит ключ
В руководстве по серверным ключам GitHub разделяет настройку на два разных сценария в зависимости от того, где именно крутится ваш помощник.
Первый путь — внутри собственных сборочных сценариев GitHub Actions в репозитории организации. Здесь регистрировать отдельное приложение и вручную прятать секретные ключи не нужно. Достаточно использовать встроенный системный ключ GITHUB_TOKEN, прописать в файле сценария разрешение на запись copilot-requests: write и включить в настройках самой организации политику оплаты командной строки (Allow use of Copilot CLI billed to the organization).
Второй путь — ваш собственный сервер или внешний облачный сервис. Для него политика командной строки из первого пункта не требуется, зато сама организация должна поддерживать запросы от установленных приложений (название конкретного переключателя в меню справка пока не раскрывает, но если функция не активна, сервер вернёт ошибку 403). Приложение с правом Copilot Requests: Read-only запрашивает у GitHub временный ключ установки с префиксом ghs_ и передаёт его в SDK.
Именно на этом шаге разработчики попадают в неочевидную ловушку с параметром useLoggedInUser (в Python он пишется как use_logged_in_user, в Go — UseLoggedInUser). По умолчанию инструмент пытается найти учётную запись человека и заодно автоматически проверяет переменные окружения на сервере: COPILOT_GITHUB_TOKEN, GH_TOKEN и GITHUB_TOKEN. Когда программист настраивает сервер без участия человека, он логично ставит useLoggedInUser: false, а сам ключ кладёт в переменную окружения. В результате сервис падает при старте с ошибкой Not authenticated или сообщением No GitHub OAuth token or Copilot HMAC key provided.
Причина прямо разобрана в таблице неполадок: выключение useLoggedInUser отрезает весь автоматический поиск учётных данных, включая чтение переменных среды. Чтобы серверный агент авторизовался, ключ ghs_ нужно передать явно через параметр gitHubToken (или github_token) в коде запуска. В версии для Node.js передача gitHubToken сама переводит useLoggedInUser в положение false. Единственное исключение — когда программа подключается по сетевому адресу к уже запущенному процессу среды выполнения через RuntimeConnection.forUri: там параметры gitHubToken и useLoggedInUser передавать запрещено, а ключ задаётся именно через переменную COPILOT_GITHUB_TOKEN на самом фоновом процессе.
О том, как собирать надёжных ИИ-помощников для рабочих задач и не терять бюджет на скрытых ограничениях сервисов, мы регулярно пишем в телеграм-канале Ковчег.
Часовой таймер на каждый ключ и поиск расходов в почтовых таблицах
Ключ установки ghs_ действует ровно один час, после чего вызовы отбиваются с ошибкой 401 Unauthorized. Встроенный механизм автообновления gitHubTokenProvider рассчитан на восьмичасовые пользовательские сессии и со статическим gitHubToken не совмещается. Способа незаметно подменить часовой ключ внутри живого процесса справка не даёт: до истечения часа ваша обвязка должна выпустить новый ключ ghs_ и перезапустить клиент SDK либо саму среду выполнения.
Понять в конце недели, какой именно сервис потратил кредиты, через обычный веб-экран AI usage тоже не выйдет — сторонних приложений там нет. Атрибуция доступна только в выгрузке AI usage report в формате CSV, которая описана в справочнике биллинга: отчёт заказывается на основную почту (одна выгрузка за раз, ссылка живёт 24 часа и хранит данные максимум за 31 день). В таблице нужно найти непустые значения app_client_id для своей организации и сверить их со списком установок (client_id и app_slug). У обычных сотрудников, сценариев GitHub Actions и старой истории это поле остаётся пустым, поэтому пустая ячейка не означает нулевой расход.
Пока серверная авторизация работает в режиме предварительного тестирования (public preview), её условия ещё могут меняться. Сам отказ от личных аккаунтов избавляет команды от поломок, когда сотрудник уходит в отпуск или меняет пароль, но включать таких ботов в постоянную работу сейчас безопасно только вместе с жёсткой остановкой по бюджету и ежечасным перезапуском клиента.
