GitHub Copilot Coding Agent: ein Test des Pull-Request-Agenten

DER GITHUB COPILOT CODING AGENT ist ein autonomer Coding Agent, der auf github.com lebt. Er nimmt eine Aufgabe als Issue oder Chat-Prompt an, bearbeitet sie in einer ephemeren GitHub-Actions-Umgebung und öffnet einen Pull Request mit dem Ergebnis. Die Dokumentation nennt diese Oberfläche inzwischen Copilot Cloud Agent, und das ist ein besserer Name: Der Pull Request ist das eigentliche Produkt. Als Test: Es ist der am engsten integrierte Coding Agent, der existiert, und diese Integration ist der Grund, warum er Arbeit liefert, die Menschen wirklich mergen, und zugleich der Grund, warum sich seine Kosten kaum wegdiskutieren lassen.

Er ist kein IDE-Feature und kein lokaler Agent. Auf einem Entwicklerrechner läuft nichts: Der Agent bekommt seinen eigenen Runner, seinen eigenen Branch, seine eigene Firewall. Das macht ihn zum richtigen Werkzeug für eine Warteschlange — Dependency-Upgrades, Test-Nachbesserungen, Dokumentationsdurchgänge, erste Korrekturen für Security-Alerts — und zum falschen für die enge Schleife, in der jemand eine einzelne Funktionssignatur steuern will. Die [Harness-Engineering-Abwägung](/blog/harness-engineering-coding-agents) betrifft dieselbe Modellklasse mit umgekehrter Ergonomie.

Was es ist

Die Oberfläche ist bewusst klein. Eine Aufgabe kommt als zugewiesenes Issue, aus dem Agenten-Panel, aus Copilot Chat, aus der REST-API, aus der GitHub CLI oder von einem MCP-Server. Der Agent klont ein Repository, plant, ändert Dateien, führt Tests und Linter aus und pusht auf einen Branch, den er selbst angelegt hat. Dieser Vertrag wird erzwungen, nicht erbeten: Pushes sind nur auf Branches erlaubt, die mit copilot/ beginnen, Workflows, die durch seine Pull Requests ausgelöst werden, brauchen die Freigabe durch jemanden mit Schreibrecht, und andere Repositories erreicht er in einem Lauf nicht.

• Ein Repository pro Session. Änderungen über Repositories hinweg sind in einem Lauf unmöglich, ein auf mehrere Repositories verteilter Code braucht also einen Menschen dazwischen.
• Ein Branch und ein Pull Request pro Aufgabe. Was wirklich zwei Pull Requests braucht, sind zwei Aufgaben und zwei Reviews.
• Eine harte Obergrenze von 59 Minuten Ausführungszeit pro Session, die laut Dokumentation weder verlängert noch umgangen werden kann.
• Commits werden von Copilot verfasst, der anfragende Mensch steht als Co-Autor, sie sind signiert, und jede Commit-Nachricht verlinkt auf die Session-Logs.
• CodeQL, Secret Scanning und Dependency Analysis laufen während der Session gegen den erzeugten Code, und der Agent versucht, Funde vor dem Push zu beheben.
• Kein Zugriff auf Actions-Secrets. Nur Secrets und Variablen, die bewusst zur copilot-Umgebung hinzugefügt wurden, werden übergeben.

Wie es funktioniert

Vier serverseitige Schritte. Die Aufgabe wird mit Repository-Kontext zusammengeführt und an ein von GitHub betriebenes Modell geschickt; das Modell plant und editiert in der ephemeren Umgebung; Tests und Linter laufen dort; das Ergebnis wird committet und gepusht, und die Beschreibung des Pull Requests wird zur Session-Zusammenfassung. Danach bleibt der Agent erreichbar: Ein Review-Kommentar oder eine Erwähnung von @copilot wird zurückgespielt und erzeugt einen weiteren Commit.

Die Session-Logs sind der Teil, den Teams zu wenig nutzen. Jeder Commit verlinkt auf sie, sie protokollieren welche Werkzeuge liefen, und Copilot Chat auf github.com kann befragt werden, was ein Pull Request geändert hat und warum, weil es die Logs in die Unterhaltung zieht. Wenn ein agentenerzeugter Pull Request falsch aussieht, sind die Logs oft aussagekräftiger als der Diff: Man sieht, welcher Test lief, zweimal fehlschlug und was der Agent stattdessen gemacht hat.

Wo er bricht

Die ehrliche Liste ist länger als die Feature-Liste. Das sind dokumentierte Grenzen und keine in der Wildnis gefundenen Fehler, und genau sie entscheiden, ob ein Workflow einen echten Backlog übersteht.

• Die 59-Minuten-Grenze ist die schmerzhafteste. Lange Migrationen und mehrstufige Refactorings müssen in passende Aufgaben geschnitten werden, was aus einem Ticket drei Tickets und drei Reviews macht.
• Der Agent reagiert nur auf Nutzer mit Schreibrecht am Repository. Kommentare von außerhalb erreichen ihn nie, was in beide Richtungen wirkt: sinnvolle Voreinstellung und Sackgasse für externe Mitwirkende.
• Repository-Regeln können ihn vollständig blockieren. Eine Regel, die Commits auf eine feste Autorenliste beschränkt, verhindert zum Beispiel, dass er Pull Requests öffnet oder aktualisiert, sofern ein Administrator Copilot nicht als Bypass-Akteur einträgt.
• Nur auf GitHub gehostete Repositories. Eine selbst gehostete GitLab-, Gerrit- oder andere Code-Plattform bekommt nichts, und die Dokumentation sagt das klar.
• Nicht verfügbar auf GitHub Enterprise Server. Ist das das Zielsystem, lautet die Antwort unabhängig von der Seat-Zahl nein.
• Er kann Code erzeugen, der öffentlichen Repositories entspricht, selbst wenn die Richtlinie solche Vorschläge blockieren soll. In dem Fall zeigt er im Session-Log einen Verweis statt einer Code-Referenz am Vorschlag.

Der Umgang mit Daten unterscheidet sich je nach Plan, und der Unterschied zählt in der Beschaffung. Prompts und Vorschläge aus einer IDE werden nicht gespeichert; Prompts und Vorschläge aus Chat-, Mobil- und CLI-Sitzungen bleiben 28 Tage. Auf Business und Enterprise werden sie nicht zum Trainieren von Modellen verwendet. Auf Free, Pro und Pro+ dürfen sie es, seit dem 24. April, sofern das Konto nicht abmeldet. Ein Team, das nur die Marketingseite liest, sieht diese Zeile nicht — also vor dem Rollout den Plan prüfen, nicht danach.

• Auf der ephemeren Umgebung ist standardmäßig eine Firewall aktiv, die ausgehende Verbindungen zu nicht erlaubten Hosts blockiert. Sie lässt sich anpassen oder abschalten, und jede Erweiterung sollte zuerst geprüft werden.
• Nur das Repository der Aufgabe ist erreichbar. Andere Repositories derselben Organisation nicht.
• Der Agent filtert versteckte Zeichen in Issue-Texten und Kommentaren und schließt damit den billigsten Prompt-Injection-Kanal.
• Custom Instructions, MCP-Server und Lifecycle-Hooks sind pro Repository oder pro Organisation konfigurierbar, Validierung kann also in der Agentenschleife laufen und nicht erst danach in CI.

Erste Schritte

Die kleinste sinnvolle Integration ist die Agent-Tasks-API: ein POST, danach eine Task-ID zum Pollen. Sie ist Public Preview, akzeptiert nur User-to-Server-Token und keine Installationstoken — was eine GitHub App ausschließt, die Agentenläufe aus einem serverseitigen Webhook ohne menschliches Token auslösen will.

# Start a task: only a user-to-server token works here
curl -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  -H "Authorization: Bearer $TOKEN" \
  https://api.github.com/agents/repos/octo-org/octo-repo/tasks \
  -d '{
    "prompt": "Fix the login button on the homepage",
    "base_ref": "main",
    "create_pull_request": true
  }'

# Poll until the state is completed, failed or timed_out
curl -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $TOKEN" \
  https://api.github.com/agents/repos/octo-org/octo-repo/tasks/$TASK_ID

Die Antwort enthält ein Feld state mit queued, in_progress, completed, failed, idle, waiting_for_user, timed_out oder cancelled, und diese Liste gehört in den aufrufenden Code. waiting_for_user ist der Fall, den ein naiver Poller falsch behandelt: Der Agent hält an, um eine Frage zu stellen, und nichts geht weiter, bis ein Mensch auf dem Pull Request antwortet. Dieselbe Arbeit gibt es lokal als gh agent-task create, gh agent-task list und gh agent-task view --log ab GitHub CLI 2.80.0, wobei auch dieser Befehlssatz Public Preview ist.

Preise und Credits

Copilot wird pro Seat abgerechnet, Agenten verbrauchen zusätzlich eine gemessene Währung: GitHub AI Credits, ein Credit für 0,01 US-Dollar. Inline-Vervollständigungen und Next-Edit-Vorschläge verbrauchen keine Credits und bleiben in jedem bezahlten Plan unbegrenzt; Chat, Agenten, CLI und Spaces schon. Das Credit-Kontingent, nicht der Seat-Preis, ist das, was ein agentenlastiges Team tatsächlich steuert.

Zwei Preisdetails entscheiden, ob das bezahlbar ist. Erstens sind Agenten der teure Teil der Credit-Ökonomie: Eine lange Session auf einem Frontier-Modell über viele Dateien kostet weit mehr als eine Chatfrage, ein Repository, in dem jedes Issue automatisch zugewiesen wird, verbraucht also binnen einer Woche ein Pro-Kontingent. Zweitens gibt es nach dem Kontingent drei Wege — auf den Reset warten, auf ein günstigeres Modell wechseln oder bezahlte Nutzung mit einem Dollar-Budget aktivieren — und auf Business und Enterprise entscheidet die Administration, nicht der Entwickler. Seit dem 1. Juni 2026 verbrauchen Code-Review-Workflows zusätzlich GitHub-Actions-Minuten, die Runner-Rechnung wandert also mit.

Alternativen

Der relevante Vergleich ist nicht mit anderen Cloud-Agenten, denn davon gibt es kaum welche, sondern mit den lokal-first Coding-Agenten, die im Terminal eines Entwicklers laufen. Sie teilen Modellkatalog und MCP-Story; sie unterscheiden sich darin, wo sie ausgeführt werden und wer das Ergebnis verantwortet.

Beim Ergonomie-Vergleich liegen die Dinge nicht knapp. Ein lokaler Agent antwortet in Sekunden und lässt sich mitten im Gedanken unterbrechen; dieser hier liefert in Minuten einen Pull Request und lässt sich nur per Kommentar steuern. Was den lokalen Agenten fehlt, ist das Pull Request als Lieferformat, Branch-Schutz, die Scan-Hooks und ein Session-Log, das ein Compliance-Team später lesen kann. Teams, die ohnehin in GitHub-Issues leben, holen mehr aus Copilot heraus als Teams, die im Terminal leben, und das ist der einzige ernsthafte Grund für die Wahl. Mehr dazu im [Werkzeug-für-Werkzeug-Vergleich](/blog/agents-md-skills-mcp-cli-decision-matrix) und in der [Sandbox-Checkliste](/blog/sandboxing-coding-agents-ci-checklist).

Fazit

Der Copilot Cloud Agent ist den Seat-Preis für genau eine Aufgabe wert: eine gut formulierte Warteschlange auf github.com abzuarbeiten, ohne dass ein Entwickler jede Session beaufsichtigt. Er ist ein Warteschlangenabbeiter mit anhängendem Review, kein autonomer Kollege. So gelesen liefert er; als Pair-Programming erwartet enttäuscht er jedes Mal.

1. Nutzen für Backlog-Einträge mit objektiven Akzeptanzkriterien: Dependency-Upgrades, generierte Tests, Dokumentation, Security-Alert-Fixes, erste Refactorings.
2. Nicht nutzen für Architektur, für Änderungen über Repositories hinweg oder für alles, was die 59-Minuten-Grenze halbieren würde.
3. Branch-Schutz, Code Owner und verpflichtende Reviews behalten. Seine Pull Requests sind Entwürfe, und das ist eine Konvention, keine Erzwingung.
4. Auf Credits budgetieren statt auf Seats, und die Regel für bezahlte Nutzung bewusst in beide Richtungen setzen, bevor die erste Überschreitung passiert.
5. Review-Zeit einplanen. Der Engpass wandert vom Schreiben des Diffs zum Lesen, was echte Einsparung und echte Kosten zugleich ist; die ausführlichere Fassung steht im [Engpass beim Review KI-generierter Pull Requests](/blog/ai-generated-pr-review-bottleneck).

You should always review and test the content generated by the agent to ensure that it meets your requirements and is free of errors or security concerns prior to merging.

Quellen

1. GitHub Docs: GitHub Copilot on GitHub.com, workflow and limitations
2. GitHub Docs: Application card, GitHub Copilot Agents
3. GitHub Docs: Plans for GitHub Copilot, prices and AI credits
4. GitHub Docs: Using Copilot cloud agent via the REST and GraphQL API
5. GitHub Docs: Using Copilot cloud agent from the GitHub CLI
6. GitHub Copilot product page: plans, privacy and FAQ
7. Anthropic: Claude Code product page
8. OpenAI: Codex CLI documentation