GitHub Copilot cloud agent по умолчанию использует стандартный размещённый Runner. Администратор организации может назначить для него группу самостоятельно размещённых Runner или указать метки. Разрешит ли организация репозиторию изменить выбор, определяется настройками организации. Эти возможности и ограничения описаны в официальной инструкции GitHub по выбору Runner для cloud agent.

Mac нужен не каждому заданию агента. Если агент редактирует код, анализирует структуру проекта или выполняет подготовку, которой достаточно доступной среды, переводить его на Mac только ради будущей проверки сборки необязательно. Переходите к настройке Mac Runner, если задача должна непосредственно обращаться к Xcode, инструментам командной строки macOS, зависимостям или внутренним системам, недоступным на стандартном Runner.

При этом не смешивайте разные этапы разработки:

• Среда cloud agent — Runner, на котором выполняются задачи агента, и подготовка окружения до его работы.
• Обычный GitHub Actions workflow — отдельная автоматизация репозитория. Её конфигурация сама по себе не доказывает, что сессию агента назначили на тот же Runner.
• Проверка Xcode CI — подтверждение, что конкретная сборка, тесты и необходимые проекту операции проходят в подходящей среде.
• Подписание и выпуск — отдельный процесс с собственными сертификатами, разрешениями и проверками. Регистрация Mac не включает его автоматически.

Решение для типовых случаев:

• Если проекту не нужны macOS-инструменты и внутренний доступ, оставьте стандартный Runner.
• Если агенту необходимы Xcode или ресурсы, доступные только из контролируемой сети, настройте группу либо метку Mac Runner и проверьте доступ в изоляции.
• Если Mac нужен лишь для финальной проверки, оставьте работу агента на стандартной среде, а Xcode CI организуйте отдельным workflow.
• Если невозможно ограничить репозитории, секреты или сетевые полномочия Runner, не подключайте его к недоверенным задачам. Оставьте стандартный Runner либо приостановите внедрение.

Настройку следует начинать не с установки Xcode, а с определения полномочий и границ доступа. Для изменения конфигурации нужны права, которые разрешают управлять настройками Copilot на уровне организации. Убедитесь, что у вас есть соответствующие полномочия, а не только доступ к репозиторию. Сверьте текущие пункты интерфейса с инструкцией по организационной конфигурации cloud agent: названия и доступность параметров могут зависеть от настроек и политики.

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

Составьте перечень реальных требований проекта. В него могут войти версия Xcode, Command Line Tools, менеджер пакетов, приватные пакеты, сертификаты, внутренние API и адреса репозиториев. Не устанавливайте инструменты «на будущее»: лишние зависимости усложняют обновление и расследование сбоев. Поддерживаемые операционные системы, архитектуры и ограничения самостоятельно размещённых Runner сверяйте с официальным справочником GitHub по self-hosted runners. Не предполагайте, что любой Mac или любая установленная версия инструмента совместимы с текущей конфигурацией cloud agent.

Отдельно проверьте сетевой маршрут. Mac должен разрешать необходимые соединения к GitHub и тем внутренним ресурсам, которые требуются проекту. Если сетевые правила блокируют загрузку зависимостей или доступ к репозиторию, Runner может быть зарегистрирован и отображаться онлайн, но задание всё равно не выполнится. В обратную сторону тоже есть риск: широкая доступность внутренней сети превращает Runner в чувствительную точку доступа. Поэтому проверяйте не только возможность соединения, но и его допустимый объём.

В настройках организации выберите стандартный вариант либо группу или метку, соответствующую подготовленному Mac Runner. Затем проверьте, разрешено ли целевым репозиториям использовать настройки workflow для выбора другой среды. Эти действия определяют политику назначения: они не устанавливают Xcode и не проверяют качество сборки.

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

Если для задания cloud agent важна подготовка зависимостей, изучите официальное руководство GitHub по настройке среды cloud agent. Файл настройки среды предназначен для подготовки проекта к работе агента. Его задача не равна регистрации Runner, выбору организационной группы или запуску полноценной цепочки Xcode CI.

Для проверки конкретных действий можно подготовить тестовый workflow с безопасными значениями-заполнителями. Пример выражает только выбор Runner для workflow и не заменяет настройку cloud agent в организации:

jobs:
  проверка-среды:
    runs-on: [self-hosted, macOS, ARM64, "TEAM_MAC_LABEL"]
    steps:
      - name: Проверить выбранный Runner
        run: |
          sw_vers
          xcode-select -p
          xcodebuild -version

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

Регистрация хоста — отдельная операция от настройки cloud agent. Следуйте актуальному официальному процессу добавления self-hosted Runner: выберите нужную область регистрации, назначьте группу согласно политике, зафиксируйте метки и проверьте состояние хоста. Не копируйте команды регистрации из старой инструкции или другого репозитория. Следуйте указаниям, отображаемым для вашей организации и выбранной области.

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

Подготовку среды разделите на независимые результаты:

• Runner зарегистрирован в ожидаемой области и связан с согласованной группой.
• Метки позволяют выбрать нужный Mac, но не расширяют список разрешённых репозиториев.
• На Mac установлен ожидаемый инструментальный набор, а xcode-select указывает на допустимую установку.
• Зависимости проекта доступны из задания и подготовлены способом, который команда умеет повторить.
• Файл среды cloud agent выполняет только необходимую подготовку до начала работы агента.

Для подробной проверки инструментов полезно отдельно пройти руководство по настройке удалённой среды разработки на Mac. Это не заменяет проверку cloud agent: здесь важно удостовериться, что конфигурация используется именно его задачей, а не только обычным workflow.

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

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

Проверяйте результаты по отдельности:

• Назначение: сессия использовала ожидаемый Runner, группу и метки. Если этого подтвердить нельзя, не считайте конфигурацию действующей.
• Доступ к коду: агент получил доступ к целевому репозиторию и смог выполнить разрешённые проектные операции.
• Подготовка: зависимости и команды из настройки среды выполнились в ожидаемом порядке.
• Инструментарий: вывод xcode-select -p и xcodebuild -version соответствует установленной и допущенной версии Xcode.
• Проверка проекта: выбранная задача действительно запускает нужную команду сборки или тестирования. Успех установки Xcode сам по себе не подтверждает Xcode CI.
• Разбор отказов: причина ошибки видна в сохранённых журналах и позволяет определить, что нужно исправить — права, сеть, метки, среду или проект.

В настройке среды указывайте воспроизводимые действия. Если версия Xcode выбирается через xcode-select, проверяйте итоговый путь и вывод команды, а не делайте вывод только по наличию каталога приложения. Если проект использует приватные пакеты, проверьте, что способ их получения доступен именно задаче агента. Ошибка авторизации может выглядеть как сбой установки зависимостей, хотя корень проблемы — в правах.

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

После пробного запуска проверьте не только полезность Mac, но и то, что может сделать задача, назначенная на этот Mac. Установите, какие репозитории могут обращаться к группе; кто способен изменить workflow или запросить переопределение; какие токены и секреты доступны; к каким внутренним ресурсам подключён хост. Подход GitHub к защите workflow и self-hosted Runner изложен в официальных рекомендациях по безопасному использованию GitHub Actions.

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

Публичные репозитории и недоверенные изменения требуют отдельного решения. Если workflow может быть изменён внешним участником, а Runner имеет доступ к внутренней сети или чувствительным данным, риск нельзя компенсировать одной меткой. Сверьте ограничения доступа и рекомендации GitHub до включения такого репозитория. Когда безопасную изоляцию нельзя подтвердить, оставьте задачу на стандартном размещённом Runner или приостановите подключение Mac.

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

Удалённый Mac полезен, когда задаче агента действительно нужен Apple-инструментарий или контролируемый доступ к проектным ресурсам. Но самостоятельное обслуживание хоста означает, что вам придётся отвечать за регистрацию, обновление среды, сетевые правила, очистку и расследование проблем. Если собственной машины для безопасного пробного запуска нет, изучите варианты удалённого Mac на странице KVMNODE: аренда позволяет проверить рабочую схему без покупки оборудования. Если же команде необходим постоянный хост с особыми физическими подключениями или непрерывной нагрузкой, сравните аренду с собственным Mac и заранее оцените, кто будет поддерживать его и контролировать доступ.