Ein selbst gehosteter Mac Runner ist für den GitHub Copilot cloud agent möglich. Er ist aber nicht automatisch für jedes Repository die richtige Wahl. Der cloud agent verwendet standardmäßig einen von GitHub gehosteten Runner; Organisationsadministratoren können stattdessen eine Runner-Gruppe oder Labels vorgeben. Ob ein Repository diese Einstellung überschreiben darf, hängt von der Organisationsrichtlinie ab. Maßgeblich ist die offizielle Anleitung zur Runner-Konfiguration für den Coding Agent.

Entscheidend ist, welche Aufgabe der Agent tatsächlich ausführen soll. Benötigt das Projekt ausschließlich sprachunabhängige Bearbeitung und Tests, kann ein Standard-Runner genügen. Werden macOS-spezifische Werkzeuge, eine Xcode-Umgebung oder freigegebene interne Ressourcen benötigt, ist ein Mac Runner zu prüfen. Daraus folgt nicht, dass der Agent zwingend Xcode benötigt oder nach der Einrichtung automatisch eine App signieren und veröffentlichen kann.

Unterscheiden Sie drei Abläufe:

• Agent-Sitzung: Der Agent bearbeitet eine Aufgabe in seiner zugewiesenen Umgebung.
• Umgebungsvorbereitung: Ein Setup-Workflow kann erforderliche Werkzeuge und Abhängigkeiten bereitstellen, bevor der Agent arbeitet.
• Reguläre CI und Freigabe: Ein separater Workflow muss Build, Tests, Signierung und Veröffentlichung nach den Regeln Ihres Projekts ausführen und abnehmen.

Ein erfolgreicher Agent-Lauf ist deshalb kein Beleg für eine vollständige Xcode-CI oder eine freigegebene Veröffentlichung.

Entscheidung nach Bedarf und Risiko

Verwenden Sie die folgenden Bedingungen, bevor Sie Runner registrieren:

• Wenn Aufgaben macOS, Xcode oder interne Ressourcen zwingend voraussetzen, dann prüfen Sie einen zugriffsbeschränkten Mac Runner. Andernfalls bleiben Sie zunächst beim Standard-Runner.
• Wenn die Organisation eine Runner-Gruppe für den Agent freigibt und die erforderlichen Repositories gezielt zuordnen kann, dann testen Sie diese Gruppe mit einem begrenzten Repository. Andernfalls ändern Sie keine Richtlinie, bevor Zuständigkeit und Zugriff geklärt sind.
• Wenn der Agent wiederholt auf vertrauliche interne Daten oder langlebige Zugangsdaten zugreifen könnte, dann reduzieren Sie Berechtigungen und prüfen Sie die Isolation besonders streng. Andernfalls legen Sie trotzdem fest, wie Arbeitsverzeichnisse und Prozesse nach jedem Lauf bereinigt werden.
• Wenn Sie die Zuordnung und Bereinigung nicht zuverlässig nachweisen können, dann nutzen Sie weiterhin den Standard-Runner oder pausieren die Mac-Anbindung.

Klären Sie zuerst, wer Einstellungen für den cloud agent und Runner-Gruppen verwalten darf. Der Zugriff auf eine Runner-Gruppe ist nicht dasselbe wie die Berechtigung, eine Agent-Umgebung zu ändern. Prüfen Sie die Zuständigkeiten für Organisationsrichtlinien, Repository-Einstellungen, Netzwerkfreigaben und Geheimnisse. Die Dokumentation zu Zugriffsrichtlinien für Runner-Gruppen beschreibt, wie der Zugriff für ausgewählte Repositories begrenzt werden kann.

Erstellen Sie anschließend eine Anforderungsliste für das konkrete Projekt. Erfassen Sie darin:

• benötigte Xcode-Version und Command-Line-Werkzeuge;
• verwendete Paketmanager und private Paketquellen;
• benötigte Netzwerkziele und interne Dienste;
• erforderliche Umgebungsvariablen und Geheimnisse;
• erwartete Build- und Testbefehle;
• Regeln für temporäre Dateien, Caches und Arbeitsverzeichnisse.

Behandeln Sie diese Liste als Soll-Zustand, nicht als Zusage, dass der bereitgestellte Mac ihn bereits erfüllt. Betriebssystem, Prozessorarchitektur, Runner-Version und installierte Werkzeuge müssen Sie am tatsächlichen Host kontrollieren. Die Referenz für selbst ge hostete Runner erklärt die unterstützten Plattformen und die grundlegenden Runner-Eigenschaften; die konkrete Eignung hängt dennoch von Ihrem Projekt ab.

Auch die Netzwerkverbindung ist vorab zu prüfen. Der Runner muss GitHub erreichen können, und der Agent darf interne Ressourcen nur dann sehen, wenn dies ausdrücklich vorgesehen ist. Ein erreichbarer Mac ist nicht automatisch ein sicher erreichbarer Mac: Ein weit geöffnetes internes Netz vergrößert die mögliche Auswirkung fehlerhafter oder nicht vertrauenswürdiger Änderungen.

Die Organisationskonfiguration bestimmt, ob der cloud agent die Standardumgebung oder eine festgelegte Runner-Gruppe beziehungsweise ein Label verwendet. Legen Sie zuerst fest, welche Runner-Gruppe für den Agent zugelassen werden soll. Ordnen Sie ihr nur die Repositories zu, die den Mac tatsächlich benötigen. Kontrollieren Sie danach, ob Repository-Verantwortliche die Organisationsvorgabe überschreiben dürfen. Diese Möglichkeit wird durch die Organisationsrichtlinie gesteuert; sie ist nicht pauschal für alle Repositories verfügbar.

Die technische Zuordnung sollte keine echten Organisationsnamen, Repository-Namen oder internen Labels in Beispielen oder öffentlichen Anleitungen offenlegen. Verwenden Sie Platzhalter wie <RUNNER_GROUP>, <MAC_LABEL> und <TEST_REPOSITORY>. Prüfen Sie im Einstellungsbereich der Organisation, welche Auswahl die Oberfläche für Ihre Konfiguration anbietet, und halten Sie den Ist-Zustand fest.

Eine Repository-Konfiguration ist nicht automatisch ein Ersatz für die Organisationsfreigabe. Kann ein Repository die Runner-Auswahl überschreiben, muss die Organisation festlegen, ob das gewollt ist und welche Repositories dafür infrage kommen. Ist die Überschreibung gesperrt, muss die Verwaltung die Änderung auf Organisationsebene vornehmen.

Registrieren Sie den Host erst, wenn Runner-Gruppe, Repository-Bereich und Netzwerkregeln feststehen. Folgen Sie dem offiziellen Verfahren zum Hinzufügen eines selbst gehosteten Runners. Verwenden Sie die von GitHub für den vorgesehenen Geltungsbereich erzeugten Anweisungen. Übernehmen Sie Registrierungstoken nicht in Skripte, Tickets, Beispieltexte oder dauerhaft gespeicherte Konfigurationsdateien.

Bei der Registrierung ordnen Sie den Runner der vorgesehenen Organisation oder dem passenden Repository-Bereich zu. Prüfen Sie anschließend die Gruppe und Labels im Runner-Datensatz. Selbst ge hostete Runner erhalten Standard-Labels für Runner-Typ, Betriebssystem und Architektur; die konkrete Kennzeichnung für macOS und die Architektur des Hosts muss zur tatsächlichen Maschine passen. Ergänzen Sie eigene Labels nur, wenn sie die Auswahl eindeutig machen und keine vertraulichen Infrastrukturdetails preisgeben. Die Details zu Standard-Labels stehen in der Runner-Referenz von GitHub.

Die Agent-Umgebung benötigt eine getrennte Vorbereitung. Ein Setup-Workflow kann Werkzeuge und Abhängigkeiten installieren oder konfigurieren, die der Agent vor Beginn seiner Arbeit benötigt. Die dazugehörige Datei heißt üblicherweise .github/workflows/copilot-setup-steps.yml; prüfen Sie die jeweils aktuelle Struktur in der Dokumentation zur Anpassung der cloud-agent-Umgebung.

Halten Sie die Zuständigkeiten getrennt:

• Runner-Registrierung: Macht den Mac als ausführbare Umgebung verfügbar.
• Agent-Setup: Bereitet Werkzeuge und Abhängigkeiten für die Agent-Sitzung vor.
• Xcode-Auswahl: Stellt sicher, dass die erwartete Entwicklungsumgebung aktiv ist.
• Regulärer CI-Workflow: Führt Projektprüfungen wie Build und Tests aus.
• Veröffentlichungsfreigabe: Entscheidet gesondert über Signierung und Auslieferung.

Prüfen Sie nach der Registrierung, ob der Runner online ist, Labels und Gruppe korrekt angezeigt werden und der Host die erforderlichen GitHub-Verbindungen aufbauen kann. Ein Online-Status belegt nur die Erreichbarkeit des Runners. Er bestätigt weder, dass der Agent ihn verwendet, noch dass Xcode oder private Abhängigkeiten korrekt eingerichtet sind.

Führen Sie den ersten Test in einem nicht produktiven oder gezielt freigegebenen Repository aus. Wählen Sie eine kleine Aufgabe ohne produktive Geheimnisse. Damit prüfen Sie die Zuweisung und Umgebungsdetails, ohne sofort den Zugriff auf weitere Projekte zu öffnen.

1. Zuweisung prüfen: Starten Sie eine kontrollierte Agent-Aufgabe und kontrollieren Sie, welcher Runner beziehungsweise welche Gruppe verwendet wurde. Vergleichen Sie den Ist-Zustand mit den Organisationsvorgaben.
2. Repository-Zugriff prüfen: Stellen Sie sicher, dass der Agent nur auf das vorgesehene Repository und die ausdrücklich freigegebenen Ressourcen zugreifen kann.
3. Arbeitsbereich prüfen: Lassen Sie eine ungefährliche Datei lesen oder bearbeiten und kontrollieren Sie, ob der Agent im erwarteten Projektverzeichnis arbeitet.
4. Werkzeuge prüfen: Erfassen Sie die verfügbaren Xcode- und Command-Line-Werkzeuge. Führen Sie nur die Befehle aus, die das Projekt tatsächlich benötigt.
5. Build und Test getrennt ausführen: Lassen Sie den passenden Xcode- oder Testbefehl laufen. Prüfen Sie Protokolle und Rückgabestatus; behandeln Sie eine abgeschlossene Agent-Aufgabe nicht als Build-Abnahme.
6. Spuren sichern und bereinigen: Speichern Sie relevante Protokolle und Fehlernachweise. Entfernen Sie danach temporäre Dateien, nicht mehr benötigte Zugangsdaten und prozessbezogene Rückstände gemäß Ihrer Betriebsrichtlinie.

Bewahren Sie die Nachweise so auf, dass ein Teammitglied später erkennen kann, ob ein Problem bei der Runner-Zuordnung, beim Setup, bei der Projektabhängigkeit oder beim eigentlichen Build entstand. Vermischen Sie diese Fehlerklassen nicht: Eine falsche Xcode-Auswahl verlangt eine andere Korrektur als ein fehlender Repository-Zugriff.

Ein selbst ge hosteter Runner befindet sich in einer Umgebung, die Ihre Organisation verwaltet. Das ist bei internen Abhängigkeiten hilfreich, erhöht aber die Verantwortung für Isolation und Wartung. GitHub weist in den Sicherheitsempfehlungen für GitHub Actions darauf hin, die Vertrauenswürdigkeit von Workflow-Code und Actions zu berücksichtigen. Behandeln Sie Änderungen aus nicht vertrauenswürdigen Beiträgen nicht wie gewöhnlichen internen Code, wenn sie auf einen Runner mit Zugang zu internen Ressourcen gelangen könnten.

Kontrollieren Sie vor einer Freigabe insbesondere:

• Repository-Reichweite: Die Runner-Gruppe soll nur für erforderliche Repositories zugänglich sein.
• Workflow-Rechte: Prüfen Sie, wer Workflows ändern und damit auf Runner oder Ressourcen zugreifen kann.
• Geheimnisse und Token: Gewähren Sie nur notwendige Berechtigungen und vermeiden Sie langlebige Zugangsdaten.
• Netzwerkgrenzen: Begrenzen Sie erreichbare interne Dienste auf den tatsächlichen Bedarf.
• Rückstände zwischen Aufgaben: Kontrollieren Sie Arbeitsverzeichnisse, Prozesse, Caches und Zugangsdaten nach einem Lauf.
• Nicht vertrauenswürdiger Code: Prüfen Sie gesondert, ob externe Beiträge oder automatisierte Änderungen den Runner erreichen können.

Für Actions empfiehlt GitHub, verwendete Actions möglichst auf eine vollständige Commit-SHA festzulegen. Bei SHA-1 entspricht eine vollständige Kennung 40 hexadezimalen Zeichen; sie identifiziert einen konkreten Commit statt eines beweglichen Versions-Tags. Diese Maßnahme ersetzt keine Prüfung des Action-Codes, erschwert aber unbemerkte Änderungen an einer referenzierten Version. Details und weitere Schutzmaßnahmen finden Sie in den Sicherheitsempfehlungen für Actions.

Erweitern Sie den Zugriff nur, wenn Sie die Runner-Zuordnung, Berechtigungen, Netzgrenzen und Bereinigung anhand des Probelaufs nachweisen können. Fehlt ein solcher Nachweis, belassen Sie es beim kontrollierten Test oder verwenden Sie weiterhin die Standardumgebung. Eine erfolgreiche Einzelaufgabe ist kein hinreichender Sicherheitsnachweis für alle Repositories oder Beitragstypen.

Der praktische Unterschied zum bisherigen Vorgehen sollte anhand Ihrer Anforderungen entschieden werden: Ein Standard-Runner kann bei Xcode oder internen Abhängigkeiten an Grenzen stoßen; ein selbst gehosteter Runner verursacht zusätzliche Wartung; ein lokaler Mac ist für ein dauerhaft benötigtes Teamgerät womöglich die einfachere Wahl, bindet aber Kapital und muss selbst betrieben werden. Wenn Sie nur eine Mac-Umgebung für einen begrenzten Test oder eine zeitweise Agent-Erprobung benötigen, kann ein gemieteter Mac den Hardwarekauf vermeiden und einen echten macOS-Zugriff über SSH, VNC oder eine Webkonsole ermöglichen. Prüfen Sie vorab, ob die angebotene Umgebung Ihre konkrete Xcode- und Sicherheitsanforderung erfüllt: KVMNODE und die verfügbaren Mac-Umgebungen. Für Teams, die statt einer zeitweiligen Umgebung einen eigenen Mac mini beschaffen möchten, bietet der Mac-mini-Leitfaden zur Beschaffung eine alternative Entscheidungsrichtung.