GitHub Copilot Agent in JetBrains: 13 Schritte, 40 Min [2026]

GitHub Copilot läuft seit Sommer 2026 nicht mehr nur als Autocomplete-Plugin in JetBrains-IDEs, sondern als vollwertiger Agent direkt in der AI Chat-Oberfläche von IntelliJ IDEA, PyCharm, WebStorm und Co. Wer bisher nur Code-Vorschläge Zeile für Zeile abgenickt hat, kann dem Agenten jetzt eine ganze Aufgabe übergeben: Dateien ändern, Befehle ausführen, Tests starten, Ergebnisse iterieren. Das klingt praktisch, bringt aber auch neue Fragen mit sich. Wie aktiviert man den Agenten korrekt über GitHub-OAuth? Wie verhindert man, dass er versehentlich die Produktionsdatenbank-Config überschreibt? Und wie baut man einen Workflow, der Reviews, Tests und Git-Worktrees sauber einbindet?

Dieses Tutorial führt Sie Schritt für Schritt durch die komplette Einrichtung: von der Plugin-Installation über die OAuth-Anmeldung bis zu einem produktionsreifen Setup mit Repository-Anweisungen, isolierten Git-Worktrees und einer CI-Pipeline, die jede Agent-Änderung automatisch prüft. Am Ende steht ein vollständiges Beispielprojekt, das Sie direkt übernehmen können. Die Struktur orientiert sich bewusst an Praktiken, die sich 2026 branchenübergreifend durchgesetzt haben: Worktrees statt direkter Hauptbranch-Bearbeitung, Pflicht-Diff-Review vor jedem Commit und ein CI-Job als zweite Kontrollinstanz.

Der Agent-Markt im Oktober 2026: Wo JetBrains und Copilot stehen

Bevor es an die eigentliche Einrichtung geht, lohnt sich ein kurzer Blick auf das Umfeld, in dem dieser Workflow entsteht. Die Entwicklung bei AI-Coding-Agenten verläuft 2026 in sehr kurzen Zyklen. Microsoft hat allein im September 2026 fünf VS-Code-Versionen veröffentlicht, von 1.136 bis 1.140, jede mit Anpassungen am Agent-Verhalten. Wer Tutorials oder interne Dokumentationen auf Basis eines älteren Editor-Standes pflegt, läuft Gefahr, mit veralteten Menüpunkten zu arbeiten.

Auch bei den CLI-Werkzeugen, die häufig parallel zur IDE laufen, hat sich in den ersten Oktoberwochen 2026 einiges bewegt. Codex CLI erschien am 8. Oktober 2026 in Version 0.162.0 und brachte dabei laut AI/TLDR-Changelog verwaltete Git-Worktree-Befehle direkt in die Kommandozeile, inklusive Erstellung und Auflistung bestehender Worktrees sowie ein Task-Pinning im sogenannten Command Center. Das bestätigt den Trend, den dieses Tutorial für die JetBrains-Integration manuell abbildet: Worktree-Isolation wird zum Standardbaustein jedes seriösen Agent-Workflows, nicht zur Ausnahme.

Einen Tag später, am 9. Oktober 2026, zog Anthropic mit Claude Code 2.1.296 nach: Die Version erlaubt es, Workflow-Agenten fest an ein einzelnes Modell zu pinnen, und führt eine unabhängige Compaction-Planung für Subagenten ein. Am selben Tag erschien Cursor 3.24, das laut AI Developer Toolkit riskante Lösch-Operationen durch den Agenten jetzt per Auto-Review stoppt, bis ein Mensch zustimmt, und Admins erlaubt, den Agentenzugriff über eine verwaltete Richtlinie auf genehmigte Remote-Workspaces zu beschränken. Für JetBrains-Teams, die GitHub Copilot als Agent einsetzen, ist das ein nützlicher Vergleichspunkt: Ähnliche Schutzmechanismen, etwa über Branch-Protection und Pflicht-Reviews, lassen sich wie in Schritt 11 und 12 beschrieben auch ohne native Auto-Review-Funktion nachbauen.

Voraussetzungen: Diese Versionen brauchen Sie

Bevor Sie anfangen, prüfen Sie, ob Ihre Umgebung aktuell genug ist. GitHub Copilot als Agent in JetBrains-IDEs setzt auf eine Reihe von Mindestversionen auf, die sich laut JetBrains-Dokumentation seit der Integration als native Agent-Option mehrfach verschoben haben.

• Eine JetBrains-IDE der 2026.2-Reihe oder neuer (IntelliJ IDEA, PyCharm, WebStorm, Rider, GoLand) mit installiertem AI Assistant-Plugin
• Ein aktiver GitHub-Account mit einem Copilot-Plan (Free, Pro, Pro+, Business oder Enterprise)
• Git ab Version 2.40, damit Worktree-Befehle ohne Umwege funktionieren
• Node.js 20 LTS oder neuer, falls Ihr Projekt JavaScript- oder TypeScript-Tests enthält, die der Agent ausführen soll
• Ein GitHub-Repository mit Schreibrechten, idealerweise mit bestehender Testsuite
• Mindestens 8 GB freier Arbeitsspeicher für die IDE, da AI Assistant und Copilot-Agent parallel Indizes aufbauen

Wichtig: Eine reine JetBrains-AI-Subscription reicht nicht aus, um Copilot zu aktivieren. Laut JetBrains-Dokumentation lässt sich GitHub Copilot ausschließlich über ein GitHub-Konto per OAuth freischalten, nicht über ein JetBrains-AI-Abo und nicht über eine eigene BYOK-Konfiguration (Bring Your Own Key). Das ist ein häufiger Stolperstein, auf den wir in Schritt 3 genauer eingehen.

Nehmen Sie sich für die Erstinstallation realistischerweise 30 bis 45 Minuten Zeit, auch wenn die einzelnen Schritte für sich genommen schnell gehen. Die Indizierung eines mittelgroßen Repositorys beim ersten Öffnen nach der Plugin-Installation kann je nach Projektgröße mehrere Minuten dauern, und die erste Konfiguration der Instruktionsdatei lohnt sich nur, wenn Sie sie in Ruhe auf Ihr Projekt zuschneiden, statt eine generische Vorlage unverändert zu übernehmen.

Schritt 1: JetBrains-IDE und AI Assistant-Plugin installieren

Starten Sie mit einer aktuellen JetBrains-IDE. Falls Sie bereits mit IntelliJ IDEA, PyCharm oder WebStorm arbeiten, reicht ein Update über den integrierten Updater (Help → Check for Updates). Öffnen Sie danach Settings → Plugins und suchen Sie nach “AI Assistant”. Das Plugin ist seit mehreren Versionen Teil der Standardinstallation der meisten JetBrains-Produkte, bei älteren Lizenzen muss es manuell nachinstalliert werden.

Nach der Installation erscheint ein neues Panel am rechten Bildschirmrand mit der Bezeichnung AI Chat. Das ist die zentrale Oberfläche, über die sowohl JetBrains-eigene Modelle als auch GitHub Copilot als Agent angesprochen werden. Ein Neustart der IDE nach der Installation ist in der Regel notwendig, damit die Indizierung für den Agenten korrekt aufgebaut wird.

Arbeiten Sie in einem Team mit unterschiedlichen JetBrains-Produkten, etwa IntelliJ IDEA für das Backend-Team und WebStorm für das Frontend-Team, müssen Sie das AI Assistant-Plugin in jeder IDE separat installieren und aktivieren. Die Einstellungen werden nicht automatisch zwischen verschiedenen JetBrains-Produkten synchronisiert, auch wenn Sie dieselbe JetBrains-Account-ID verwenden. Prüfen Sie außerdem im Plugin-Marketplace, ob für Ihre konkrete IDE-Version eine kompatible Plugin-Version angezeigt wird, da ältere Lizenzstände gelegentlich nur eine eingeschränkte Vorschau-Version des Plugins erhalten.

Schritt 2: GitHub Copilot als Agent auswählen

Öffnen Sie das AI Chat-Panel und klicken Sie auf das Agenten-Auswahlmenü oben im Fenster. JetBrains beschreibt diesen Schritt im eigenen Blog so: “Open AI chat in your JetBrains IDE, navigate to the agent picker menu, and select GitHub Copilot.” Das bedeutet konkret: Sie wählen GitHub Copilot aus einer Liste verfügbarer Agenten aus, genau wie Sie auch ein JetBrains-eigenes Modell oder einen anderen verbundenen Agenten wählen könnten.

Falls GitHub Copilot in der Liste fehlt, prüfen Sie zuerst, ob das Plugin “GitHub Copilot” separat installiert ist. Es handelt sich technisch um eine eigenständige Erweiterung, die zusätzlich zum AI Assistant-Plugin läuft und in der Agent Communication Protocol (ACP) Registry der IDE eingebunden wird.

Dieser Aufbau über eine offene Registry statt eines starren Einzelintegration bringt einen praktischen Vorteil: Sie können im selben AI Chat-Fenster zwischen GitHub Copilot und anderen registrierten Agenten wechseln, ohne die IDE neu zu konfigurieren. Für ein Team, das zum Vergleich auch JetBrains eigenes Junie oder ein weiteres Werkzeug testen möchte, bedeutet das, dass sich beide Optionen parallel im selben Projekt evaluieren lassen, ohne zwei getrennte Installationen pflegen zu müssen.

Schritt 3: Mit GitHub-Account anmelden (OAuth)

Nach der Auswahl fordert die IDE Sie zur Anmeldung auf. JetBrains fasst den Ablauf so zusammen: “From there, follow the OAuth login prompt to connect your GitHub account.” Es öffnet sich ein Browserfenster mit der GitHub-Login-Seite. Melden Sie sich mit dem Account an, der über einen aktiven Copilot-Plan verfügt, und bestätigen Sie die Berechtigungsanfrage.

Die GitHub-Dokumentation selbst betont zur Installation: “To use GitHub Copilot, you need to install and activate it with your GitHub account.” Danach gilt laut Dokumentation: “After setup, select GitHub Copilot in AI Chat to start using it.” Diese zwei Sätze beschreiben exakt den Pfad, den Sie in Schritt 2 und 3 durchlaufen haben. Wenn die Anmeldung fehlschlägt, liegt es in den meisten Fällen an einem abgelaufenen Browser-Cookie oder einer Firmen-Firewall, die den OAuth-Callback blockiert – dazu mehr im Troubleshooting-Teil.

Beachten Sie, dass die OAuth-Anmeldung an den jeweils aktiven Browser-Profil gebunden ist. Wer auf einem Firmenrechner mehrere Browser-Profile für private und geschäftliche GitHub-Accounts nutzt, sollte vor dem Login prüfen, welches Profil gerade als Standard eingestellt ist. Eine Verwechslung führt nicht zu einer Fehlermeldung, sondern dazu, dass der Agent später mit den Rechten und dem Copilot-Plan des falschen Accounts arbeitet, was besonders in Organisationen mit mehreren GitHub-Enterprise-Mandanten zu Verwirrung führt.

Schritt 4: Aktivierung verifizieren

Sobald die Anmeldung abgeschlossen ist, zeigt das AI Chat-Panel den Namen Ihres GitHub-Accounts und den Status “Connected” an. Tippen Sie zur Kontrolle eine einfache Testanfrage ein, zum Beispiel “Erkläre die Struktur dieses Projekts”. Antwortet der Agent mit einer inhaltlich korrekten Zusammenfassung Ihres geöffneten Repositorys, ist die Grundaktivierung erfolgreich.

Prüfen Sie außerdem, welches Modell im Hintergrund aktiv ist. Je nach Copilot-Plan und IDE-Version stehen unterschiedliche Modelle zur Auswahl, die sich über ein Dropdown direkt im Chat-Fenster wechseln lassen.

Schritt 5: Repository-Anweisungen für den Agenten anlegen

Ein Agent, der nichts über Ihre Projektkonventionen weiß, rät. Legen Sie deshalb eine Instruktionsdatei an, die Copilot bei jeder Anfrage automatisch mitliest. GitHub Copilot unterstützt dafür projektweite Markdown-Dateien im Repository-Root beziehungsweise im .github-Ordner.

# .github/copilot-instructions.md

## Projektkontext
Dies ist ein Node.js-Backend mit Express und PostgreSQL.
Zielgruppe: interne API fuer ein oesterreichisches Fintech-Team.

## Coding-Konventionen
- TypeScript strict mode, keine impliziten any-Typen
- Tests mit Vitest, jede neue Funktion braucht mindestens einen Testfall
- Keine direkten SQL-Strings, ausschliesslich ueber das Query-Builder-Modul
- Fehlermeldungen auf Deutsch fuer Endnutzer, Logs auf Englisch

## Sicherheitsregeln
- Niemals Umgebungsvariablen oder .env-Dateien veraendern
- Niemals Migrationsdateien loeschen, nur neue anlegen
- Aenderungen an Auth-Modulen erfordern einen expliziten Hinweis im PR-Text

Diese Datei wird vom Agenten bei jeder Session automatisch berücksichtigt, ohne dass Sie sie jedes Mal neu in den Chat einfügen müssen. Das spart nicht nur Zeit, sondern reduziert auch die Zahl der Korrekturdurchgänge erheblich.

Halten Sie die Datei bewusst kurz und konkret. Eine Instruktionsdatei mit zwanzig abstrakten Grundsätzen bringt weniger als zehn klare, überprüfbare Regeln. Formulieren Sie Regeln so, dass sich ihre Einhaltung im Diff-Review direkt erkennen lässt, etwa “jede neue Route braucht einen Test” statt “Code soll gut getestet sein”. Bei größeren Monorepos können Sie zusätzlich pro Unterordner eine eigene, spezifischere Instruktionsdatei anlegen, die die allgemeinen Projektregeln um modulspezifische Hinweise ergänzt, etwa abweichende Namenskonventionen in einem älteren Legacy-Modul.

Schritt 6: Git-Worktree für isolierte Agent-Änderungen einrichten

Ein zentrales Sicherheitsprinzip beim Einsatz von AI-Agenten lautet: Lassen Sie den Agenten nie direkt auf Ihrem Hauptbranch arbeiten. Git-Worktrees lösen dieses Problem elegant, weil sie einen zweiten Arbeitsordner für einen separaten Branch anlegen, ohne dass Sie das Repository klonen müssen.

# Im Hauptrepository ausfuehren
git worktree add ../projekt-agent-feature -b agent/neue-funktion

# In den neuen Ordner wechseln und die IDE dort oeffnen
cd ../projekt-agent-feature

# Nach Abschluss der Agent-Session: Worktree wieder entfernen
git worktree remove ../projekt-agent-feature

Öffnen Sie diesen separaten Ordner als eigenes Projekt in der JetBrains-IDE. Der Copilot-Agent arbeitet dann ausschließlich im isolierten Branch, während Ihr Hauptfenster mit dem produktiven Code unberührt bleibt. Das deckt sich mit einer Beobachtung aus einem aktuellen Vergleich von Cursor und GitHub Copilot: Cursor gruppiert vom Agenten vorgeschlagene Änderungen bewusst als Ganzes, bevor sie akzeptiert werden, während Copilot in der IDE eher fortlaufend Dateien ändert und der Entwickler das Ergebnis danach prüft. Mit einem eigenen Worktree holen Sie sich diesen Review-Vorteil auch für Copilot in JetBrains, unabhängig davon, wie die IDE den Diff standardmäßig anzeigt.

Ein weiterer Vorteil von Worktrees: Sie können mehrere Agent-Sessions parallel laufen lassen, ohne dass sich die Änderungen gegenseitig überschreiben. Legen Sie für jede größere Aufgabe einen eigenen Worktree-Ordner mit eigenem Branch-Namen an, etwa agent/pdf-export und agent/such-filter, und wechseln Sie je nach Aufgabe zwischen den geöffneten IDE-Fenstern. Das verhindert, dass zwei Agent-Läufe gleichzeitig dieselbe Datei bearbeiten und widersprüchliche Änderungen produzieren.

Schritt 7: Dem Agenten eine konkrete Aufgabe geben

Jetzt kommt der eigentliche Agent-Modus zum Einsatz. Die GitHub-Dokumentation beschreibt das Verhalten so: “In agent mode, Copilot takes a high-level task, decides which files to change, makes the edits, and runs commands as needed, iterating until the task is done.” Das heißt: Sie formulieren ein Ziel, keine einzelne Codezeile.

Ein guter Prompt für den Agenten im Worktree sieht zum Beispiel so aus: “Füge einen neuen Endpunkt /api/invoices/:id/pdf hinzu, der eine Rechnung als PDF zurückgibt. Nutze die bestehende PDF-Bibliothek im Projekt, schreibe einen Test dafür und aktualisiere die OpenAPI-Spezifikation.” Je präziser die Aufgabe, desto weniger Nachbesserungsrunden braucht es.

Schritt 8: Agenten während der Arbeit steuern

Der Agent arbeitet nicht in einem einzigen Durchgang, sondern iterativ: Er liest Dateien, schlägt Änderungen vor, führt Befehle aus und passt seinen Plan an, wenn ein Test fehlschlägt. Während dieser Phase können Sie eingreifen, etwa um eine Zwischenanweisung zu geben (“Verwende stattdessen die vorhandene PdfGenerator-Klasse”) oder um den Vorgang zu stoppen, falls der Agent in die falsche Richtung läuft.

Nutzen Sie dafür die Stopp-Schaltfläche im Chat-Panel, statt die IDE hart zu schließen. Ein harter Abbruch kann dazu führen, dass Dateien in einem halb geänderten Zustand zurückbleiben, was spätere Git-Diffs unnötig verschmutzt.

Ein hilfreiches Muster in dieser Phase: Lesen Sie die Zwischenschritte des Agenten aktiv mit, statt nur auf die finale Zusammenfassung zu warten. Viele Agenten zeigen im Chat an, welche Datei sie gerade öffnen und welchen Befehl sie als Nächstes ausführen wollen. Wer diese Zwischenschritte überfliegt, erkennt Fehlentwicklungen oft schon, bevor der Agent mehrere Minuten in die falsche Richtung weiterarbeitet, und kann frühzeitig mit einer präzisierenden Nachricht eingreifen.

Schritt 9: Vollständigen Diff vor dem Übernehmen prüfen

Sobald der Agent meldet, die Aufgabe sei abgeschlossen, zeigt die IDE eine Zusammenfassung aller geänderten Dateien. Öffnen Sie an dieser Stelle unbedingt die Diff-Ansicht (meist über ein Icon direkt in der Chat-Antwort oder über Git → Show Diff). Gehen Sie jede Datei einzeln durch, bevor Sie etwas committen.

# Diff fuer alle vom Agenten geaenderten Dateien im Worktree ansehen
git diff --stat
git diff src/routes/invoices.ts

# Nur bestimmte Dateien aus dem Agent-Commit uebernehmen
git add src/routes/invoices.ts src/routes/invoices.test.ts
git commit -m "Agent: PDF-Endpunkt fuer Rechnungen hinzugefuegt"

Diese Review-Pflicht ist keine Formalität. Gerade bei mehrstufigen Aufgaben neigen Agenten dazu, zusätzliche Dateien anzufassen, etwa Konfigurationsdateien oder Lockfiles, die mit der eigentlichen Aufgabe nichts zu tun haben.

Achten Sie beim Review besonders auf drei Dinge: erstens, ob neue Abhängigkeiten in package.json oder einer vergleichbaren Datei auftauchen, die Sie nicht angefordert haben. Zweitens, ob Kommentare oder Log-Ausgaben versehentlich Zugangsdaten oder interne Hostnamen enthalten, die der Agent aus dem Kontext übernommen hat. Drittens, ob der Agent bestehende Tests verändert hat, um sie zum Bestehen zu bringen, statt den eigentlichen Code zu korrigieren. Dieser letzte Punkt ist besonders tückisch, weil ein grüner Testlauf dann nichts mehr über die tatsächliche Korrektheit der Änderung aussagt.

Schritt 10: Tests, Linter und Typchecker automatisch ausführen

Verlassen Sie sich nicht allein auf die Einschätzung des Agenten, dass “alle Tests grün” seien. Lassen Sie die Testsuite lokal noch einmal manuell laufen, bevor Sie den Branch pushen.

npm run lint
npm run typecheck
npm run test -- --run

# Bei Erfolg: Branch pushen und PR anlegen
git push origin agent/neue-funktion
gh pr create --title "Agent: PDF-Endpunkt fuer Rechnungen" --body "Von GitHub Copilot Agent erstellt, manuell geprueft."

Diese drei Befehle sollten für jedes Projekt, in dem ein Agent arbeitet, zur festen Routine werden, unabhängig davon, wie vertrauenswürdig der Agent in der Vergangenheit war.

Schritt 11: CI-Job für Agent-generierten Code einrichten

Manuelle Prüfung reicht auf Dauer nicht aus, besonders wenn mehrere Teammitglieder parallel Agenten einsetzen. Richten Sie eine GitHub-Actions-Pipeline ein, die bei jedem Pull Request automatisch Lint, Typecheck und Tests ausführt, unabhängig davon, ob ein Mensch oder ein Agent den Branch erstellt hat.

# .github/workflows/agent-pr-check.yml
name: Agent PR Check

on:
  pull_request:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test -- --run

Ergänzen Sie die Branch-Protection-Regeln in den Repository-Einstellungen so, dass dieser Check vor jedem Merge in den Hauptbranch bestehen muss. Damit entsteht eine zweite, unabhängige Kontrollinstanz neben der manuellen Diff-Prüfung aus Schritt 9.

Bei größeren Projekten lohnt sich zusätzlich ein Caching-Schritt für die Node-Module, damit der CI-Job nicht bei jedem Agent-Pull Request die komplette Abhängigkeitsinstallation neu durchläuft. Das hält die Rückmeldezeit kurz, was gerade bei iterativen Agent-Workflows wichtig ist: Je schneller ein fehlgeschlagener Check zurückkommt, desto schneller kann entweder der Agent oder ein Teammitglied nachbessern, ohne dass die Session bereits weitergezogen ist.

Schritt 12: Berechtigungen und Dateischutz dokumentieren

Legen Sie schriftlich fest, welche Dateien und Befehle der Agent anfassen darf und welche tabu sind. Das gehört in dieselbe Instruktionsdatei aus Schritt 5, kann aber zusätzlich über eine Sperrliste ergänzt werden, die Teammitglieder beim Onboarding lesen.

• Produktionsnahe Konfigurationsdateien (.env, secrets.yml) grundsätzlich sperren
• Datenbank-Migrationsskripte nur zum Anlegen, nie zum Löschen freigeben
• CI/CD-Pipeline-Dateien nur mit explizitem menschlichem Review ändern lassen
• Abhängigkeits-Updates (package.json, go.mod) separat kennzeichnen, da sie Lieferketten-Risiken bergen

Diese Liste ist kein starres Regelwerk, sondern ein Ausgangspunkt. Passen Sie sie an die tatsächlichen Risiken Ihres Projekts an und überprüfen Sie sie alle paar Monate erneut, insbesondere wenn sich die Struktur des Repositorys ändert oder neue, besonders sensible Komponenten hinzukommen.

Schritt 13: Erst im kleinen Repository testen, dann skalieren

Bevor Sie den Agent-Workflow für ein großes Team-Repository mit Dutzenden Mitwirkenden ausrollen, testen Sie ihn zwei bis drei Wochen an einem kleineren, risikoärmeren Projekt. So lassen sich typische Fehlkonfigurationen bei den Instruktionsdateien, der Worktree-Struktur und den CI-Checks ohne Zeitdruck ausbügeln, bevor das gesamte Team davon abhängig ist.

Sicherheits- und Compliance-Überlegungen für Teams in Österreich

Sobald ein Agent Lese- und Schreibzugriff auf ein Repository hat, stellt sich unweigerlich die Frage, welche Daten dabei an einen Cloud-Dienst gehen. GitHub Copilot verarbeitet Code-Kontext, Dateinamen und Chat-Verläufe, um Vorschläge und Agent-Aktionen zu generieren. Für Teams in Österreich und generell im EU-Raum bedeutet das: Prüfen Sie vor dem Rollout, welcher Copilot-Plan (Business oder Enterprise) in Ihrer Organisation aktiv ist, da sich Datenverarbeitungs- und Aufbewahrungsregeln zwischen den Plänen unterscheiden können.

Legen Sie zusätzlich fest, welche Repositories für den Agent-Einsatz überhaupt freigegeben sind. Code mit besonders sensiblen Daten, etwa Kundendatenbanken-Schemas oder kryptografische Schlüssel, sollte entweder komplett ausgenommen oder nur mit zusätzlichen Zugriffsbeschränkungen bearbeitet werden. Die bereits beschriebene Instruktionsdatei und die Sperrliste aus Schritt 12 sind dafür die praktische Grundlage, ersetzen aber keine förmliche interne Richtlinie, die von der IT- oder Compliance-Abteilung freigegeben wurde. Dokumentieren Sie außerdem, wer in Ihrem Team Zugriff auf die Agent-Protokolle hat, falls im Nachhinein nachvollzogen werden muss, welche Änderung von einem Agenten und welche von einem Menschen stammt.

Komplettes Beispielprojekt: Dateistruktur im Überblick

Nach allen 13 Schritten sieht ein fertig eingerichtetes Projekt mit Agent-Workflow so aus:

mein-projekt/
├── .github/
│   ├── copilot-instructions.md
│   └── workflows/
│       └── agent-pr-check.yml
├── src/
│   ├── routes/
│   │   ├── invoices.ts
│   │   └── invoices.test.ts
│   └── lib/
│       └── pdf-generator.ts
├── package.json
├── tsconfig.json
└── vitest.config.ts

# Zugehoeriger Worktree waehrend einer Agent-Session:
../mein-projekt-agent-feature/   (Branch: agent/neue-funktion)

Dieses Skelett lässt sich auf praktisch jedes Node.js-, Python- oder Java-Projekt übertragen. Die Kernidee bleibt gleich: Instruktionsdatei für Kontext, Worktree für Isolation, CI-Job für automatisierte Kontrolle. Bei Java- oder Kotlin-Projekten ersetzen Sie lediglich die Node-spezifischen Befehle in der Workflow-Datei durch die entsprechenden Gradle- oder Maven-Aufrufe, während die Instruktionsdatei und der Worktree-Ablauf unverändert bleiben.

Beispiel-Ausgabe: So sieht eine erfolgreiche Agent-Session aus

Eine typische Konsolen- und Chat-Ausgabe nach Abschluss einer Agent-Aufgabe sieht etwa so aus:

Agent: Aufgabe abgeschlossen.
Geaenderte Dateien: 3
  + src/routes/invoices.ts (neu)
  + src/routes/invoices.test.ts (neu)
  ~ src/lib/pdf-generator.ts (erweitert)

Ausgefuehrte Befehle:
  npm run test -- --run invoices.test.ts   -> 4 passed, 0 failed
  npm run typecheck                        -> keine Fehler

Zusammenfassung: Neuer Endpunkt GET /api/invoices/:id/pdf
mit Testabdeckung fuer Erfolgs- und Fehlerfall implementiert.

Weicht Ihre Ausgabe deutlich davon ab, etwa weil Tests fehlschlagen oder der Agent Dateien außerhalb des erwarteten Bereichs anfasst, ist das ein klares Signal, die Session abzubrechen und die Instruktionsdatei nachzuschärfen.

Praxisbeispiel: Ein Legacy-Modul mit dem Agenten modernisieren

Um zu zeigen, wie die einzelnen Schritte im Alltag zusammenspielen, folgt ein durchgängiges Beispiel. Angenommen, ein Team pflegt ein zehn Jahre altes Rechnungsmodul, das noch auf callback-basierte Datenbankzugriffe setzt, während der Rest der Codebasis längst auf async/await umgestellt ist. Die Aufgabe: das Modul schrittweise modernisieren, ohne das bestehende Verhalten zu brechen.

Der erste Schritt ist ein eigener Worktree mit dem Branch agent/invoices-async. Darin bekommt der Agent eine eng gefasste erste Aufgabe: “Konvertiere ausschließlich die Funktion getInvoiceById in src/lib/invoices.js von Callback- auf async/await-Syntax. Ändere keine andere Funktion in dieser Datei. Halte die bestehende Testdatei invoices.test.js grün.” Diese Eingrenzung ist bewusst klein gehalten, denn ein Agent, der gleichzeitig zehn Funktionen umbauen soll, produziert deutlich häufiger fehlerhafte Zwischenstände.

Nach Abschluss der ersten Teilaufgabe folgt der Diff-Review aus Schritt 9, danach ein Commit, dann die nächste Teilaufgabe für die nächste Funktion. Auf diese Weise entsteht eine Kette kleiner, einzeln nachvollziehbarer Commits statt eines einzigen riesigen Agent-Commits, der sich im Nachhinein kaum noch sinnvoll reviewen lässt. Nach vier bis fünf solchen Zyklen ist das gesamte Modul migriert, mit einer Git-Historie, die jeden einzelnen Schritt dokumentiert und bei Bedarf einzeln zurückgerollt werden kann.

Die häufigsten Fallstricke bei der Einrichtung

Bei der Einführung von Copilot-Agent in JetBrains-Teams tauchen immer wieder dieselben fünf Probleme auf. Wer sie kennt, spart sich Stunden Fehlersuche.

• JetBrains-AI-Abo mit Copilot verwechselt: Ein aktives JetBrains-AI-Abonnement aktiviert Copilot nicht automatisch. Es bleibt eine separate GitHub-Anmeldung nötig, da beide Systeme unterschiedliche Abrechnungs- und Berechtigungsmodelle verwenden.
• Agent arbeitet direkt auf dem Hauptbranch: Ohne Worktree oder Feature-Branch landen unfertige Agent-Änderungen direkt im produktiven Code, und ein versehentliches Commit lässt sich nur noch über einen Revert wieder rausnehmen.
• Diff-Review übersprungen: Wer die Zusammenfassung des Agenten blind akzeptiert, übersieht oft Nebenänderungen an Konfigurationsdateien, die mit der eigentlichen Aufgabe gar nichts zu tun haben.
• Fehlende oder zu vage Instruktionsdatei: Ohne klare Coding-Konventionen in copilot-instructions.md produziert der Agent inkonsistenten Stil, der im Review wieder korrigiert werden muss, was den Zeitgewinn der Automatisierung wieder aufzehrt.
• Keine CI-Absicherung: Teams, die ausschließlich auf manuelle Reviews setzen, verpassen irgendwann einen fehlerhaften Agent-Commit, der durchrutscht, meist dann, wenn mehrere PRs gleichzeitig zur Review anstehen und die Aufmerksamkeit sinkt.

Troubleshooting: Die wichtigsten Fehlerquellen

Auch mit korrekter Einrichtung treten typische Probleme auf. Diese acht Punkte decken die häufigsten Supportfälle ab.

• OAuth-Fenster öffnet sich nicht: Prüfen Sie, ob die IDE als Standard-Browser-Handler eingeschränkt ist, und öffnen Sie den angezeigten Link manuell im Browser. Kopieren Sie dafür die URL aus der Statuszeile der IDE in die Zwischenablage.
• Copilot taucht nicht im Agenten-Menü auf: Das separate GitHub-Copilot-Plugin fehlt oder ist veraltet. Prüfen Sie Settings → Plugins → Installed auf Updates und starten Sie die IDE nach einer Aktualisierung neu.
• Anmeldung erfolgreich, aber “Not connected”-Status: Der Copilot-Plan ist möglicherweise inaktiv oder über die Organisation gesperrt. Prüfen Sie den Account-Status direkt auf GitHub unter den Copilot-Einstellungen Ihres Profils.
• Agent hängt in einer Schleife fest: Meist ein Zeichen für eine zu vage Aufgabenstellung oder einen Test, der strukturell nicht bestehen kann. Brechen Sie ab und formulieren Sie die Aufgabe kleinteiliger, wie im Praxisbeispiel oben.
• Worktree lässt sich nicht entfernen: Schließen Sie zuerst das IDE-Fenster, das im Worktree-Ordner geöffnet ist, da offene Dateihandles das Löschen blockieren. Unter Windows hilft zusätzlich ein Neustart des Explorer-Prozesses.
• CI-Job schlägt fehl, obwohl lokale Tests grün sind: Prüfen Sie Node- oder Python-Versionsunterschiede zwischen lokaler Umgebung und CI-Runner, und fixieren Sie die Version explizit in der Workflow-Datei statt sich auf “latest” zu verlassen.
• Agent ignoriert die Instruktionsdatei: Stellen Sie sicher, dass die Datei exakt unter .github/copilot-instructions.md liegt und nicht in einem Unterordner versteckt ist. Ein Tippfehler im Dateinamen führt dazu, dass die Datei stillschweigend ignoriert wird.
• Hohe Latenz bei Antworten: Große, nicht indizierte Repositories verlangsamen die Kontextanalyse. Schließen Sie nicht benötigte Module im Projekt, um die Indizierung zu beschleunigen, und vermeiden Sie es, Binärdateien oder große Datensätze im selben Repository zu versionieren.

Fortgeschrittene Tipps für den Teameinsatz

Sobald die Grundeinrichtung läuft, lohnt sich der Blick auf drei weiterführende Praktiken. Erstens: Verwenden Sie für wiederkehrende Aufgabentypen wie “Neuen REST-Endpunkt hinzufügen” oder “Testlücke schließen” feste Prompt-Vorlagen im Team-Wiki, statt jedes Mal neu zu formulieren. Das verbessert die Konsistenz der Agent-Ausgaben deutlich.

Zweitens: Kombinieren Sie den Copilot-Agenten mit einem zweiten, unabhängigen Review-Agenten für Pull Requests. Aktuelle Marktbeobachtungen zeigen, dass viele Teams inzwischen den Code-Review-Schritt bewusst von einem anderen Werkzeug als dem Code-Generierungs-Agenten übernehmen lassen, um blinde Flecken zu reduzieren.

Drittens: Dokumentieren Sie, welches Modell hinter dem Agenten aktiv war, wenn Sie einen PR mit Agent-generiertem Code zur Review stellen. Das erleichtert es Reviewer:innen, bekannte Schwächen eines bestimmten Modells gezielt im Blick zu haben, etwa bei komplexer asynchroner Logik.

Viertens: Beobachten Sie, wie andere Werkzeuge im selben Umfeld mit riskanten Agent-Aktionen umgehen, und übertragen Sie brauchbare Ideen auf Ihr Setup. Cursor 3.24 etwa hält laut aktuellen Marktbeobachtungen riskante Löschoperationen automatisch an, bis ein Mensch zustimmt. Ein ähnliches Verhalten lässt sich für Copilot in JetBrains nachbilden, indem Sie in der Instruktionsdatei explizit festlegen, dass der Agent vor dem Löschen von mehr als einer Datei pro Aufgabe nachfragen muss, statt stillschweigend fortzufahren.

GitHub Copilot in JetBrains vs. andere Agent-Workflows

Wie unterscheidet sich dieser native JetBrains-Workflow von anderen Einsatzorten für Copilot? Die folgende Tabelle vergleicht die drei gängigsten Umgebungen anhand zentraler praktischer Kriterien.

Umgebung	Aktivierung	Diff-Review	Worktree-Unterstützung	Typischer Einsatz
JetBrains-IDE (nativ)	GitHub-OAuth im AI Chat	Integrierte Diff-Ansicht	Manuell über Git-CLI	Java-, Kotlin-, Python-Teams
VS Code	GitHub-OAuth im Copilot-Panel	Inline-Diff im Editor	Manuell über Git-CLI	JavaScript-, TypeScript-Teams
Copilot CLI	GitHub-OAuth im Terminal	Terminal-Diff-Ausgabe	Native Worktree-Befehle	Skript- und Automatisierungs-Workflows

Der grundlegende Aktivierungsweg über GitHub-OAuth bleibt in allen drei Umgebungen identisch, da Copilot in jedem Fall an denselben GitHub-Account gebunden ist. Unterschiede liegen vor allem darin, wie tief Worktree- und Diff-Funktionen in das jeweilige Werkzeug integriert sind. Wer bereits GitHub Copilot in VS Code eingerichtet hat, erkennt den OAuth-Ablauf sofort wieder, auch wenn die Diff-Darstellung in JetBrains-IDEs anders aufgebaut ist.

Für Teams, die ohnehin schon mit Codex CLI arbeiten, ist die native Worktree-Verwaltung aus Version 0.162.0 ein Hinweis darauf, wohin sich auch IDE-Integrationen entwickeln dürften: weg von manuellen Git-Befehlen, hin zu Worktree-Funktionen, die direkt im jeweiligen Werkzeug sichtbar und steuerbar sind. Bis JetBrains eine vergleichbare native Worktree-Verwaltung für den Copilot-Agenten anbietet, bleibt die in Schritt 6 beschriebene manuelle Variante über die Git-CLI der zuverlässigste Weg.

Agent-Nutzung im Team nachvollziehen

Sobald mehrere Entwickler:innen parallel mit dem Copilot-Agenten arbeiten, wird Nachvollziehbarkeit zum eigenen Thema. Ohne klare Kennzeichnung lässt sich im Nachhinein kaum unterscheiden, welcher Commit von einem Menschen und welcher vom Agenten stammt, was spätere Fehlersuche unnötig erschwert. Eine einfache Lösung: Verwenden Sie ein festes Präfix wie “Agent:” in jeder Commit-Message, die aus einer Agent-Session stammt, wie es auch in den Codebeispielen dieses Tutorials durchgängig gemacht wird.

Ergänzend lässt sich auf GitHub ein eigenes Pull-Request-Label wie “ai-agent” anlegen, das bei jedem Agent-generierten PR automatisch oder manuell gesetzt wird. Darüber lassen sich im Projektverlauf Auswertungen fahren, etwa wie viele Pull Requests pro Monat über den Agenten entstanden sind oder wie hoch die Quote an Agent-PRs ist, die ohne Nachbesserung durch den CI-Check kommen. Diese Kennzahl ist ein guter Indikator dafür, ob die Instruktionsdatei aus Schritt 5 gut genug kalibriert ist oder ob sie nachgeschärft werden muss. Eine niedrige Erstdurchlauf-Quote deutet meist darauf hin, dass entweder die Aufgaben zu groß geschnitten sind oder die Projektregeln zu unklar formuliert wurden.

Checkliste: Bereitschaftsstufen für den Produktiveinsatz

Bevor Sie den Agent-Workflow für das gesamte Team freigeben, hilft eine kurze Reifegrad-Übersicht, um den aktuellen Stand ehrlich einzuschätzen.

Reifegrad	Merkmale	Risiko ohne Anpassung
Einstieg	Agent aktiviert, keine Instruktionsdatei, kein Worktree	Hoch: unkontrollierte Änderungen am Hauptbranch
Grundlegend	Instruktionsdatei vorhanden, Worktree manuell genutzt	Mittel: Reviewqualität hängt stark von Einzelpersonen ab
Abgesichert	CI-Job prüft jeden PR, Berechtigungen dokumentiert	Niedrig: Fehler werden vor dem Merge abgefangen
Skaliert	Teamweite Prompt-Vorlagen, zweiter Review-Agent aktiv	Sehr niedrig: mehrschichtige Kontrolle etabliert

Wenn Sie bereits Erfahrung mit Subagents und Hooks in Claude Code gesammelt haben, lassen sich viele der hier beschriebenen Prinzipien, etwa klar abgegrenzte Berechtigungen und automatisierte Checks, direkt auf den Copilot-Workflow in JetBrains übertragen. Auch ein Blick auf die Einrichtung eines MCP-Servers lohnt sich, falls Sie den Agenten später mit zusätzlichen externen Werkzeugen verbinden möchten. Für Teams, die stattdessen lieber direkt über die Kommandozeile arbeiten, bietet sich ergänzend ein Blick auf die Einrichtung von GitHub Copilot CLI an, die denselben OAuth-Mechanismus nutzt. Und wer zusätzlich JetBrains’ eigenen KI-Agenten Junie ausprobieren möchte, findet in der Anleitung zur Einrichtung von JetBrains Junie einen passenden Vergleichspunkt zum hier beschriebenen Copilot-Workflow.

Häufig gestellte Fragen

Funktioniert GitHub Copilot als Agent mit jedem JetBrains-Produkt?

Ja, die Integration läuft über das gemeinsame AI Assistant-Plugin und ist damit in IntelliJ IDEA, PyCharm, WebStorm, Rider, GoLand und weiteren JetBrains-Produkten verfügbar, sofern die IDE-Version aktuell genug ist.

Brauche ich zusätzlich ein JetBrains-AI-Abo?

Nein. Für die reine Nutzung von GitHub Copilot als Agent reicht ein aktiver Copilot-Plan bei GitHub. Ein JetBrains-AI-Abo wird nur benötigt, wenn Sie zusätzlich JetBrains-eigene Modelle im selben Chat-Panel nutzen möchten.

Kann der Agent versehentlich Produktionscode verändern?

Technisch ja, wenn Sie direkt im Hauptbranch arbeiten. Deshalb empfiehlt dieses Tutorial ausdrücklich den Einsatz von Git-Worktrees und eine Pflicht-Review der Diffs vor jedem Commit.

Wie unterscheidet sich der Agent-Modus von normalen Code-Vorschlägen?

Normale Vorschläge betreffen einzelne Zeilen oder Blöcke, die Sie manuell bestätigen. Der Agent-Modus übernimmt eine ganze Aufgabe eigenständig: Er wählt Dateien aus, nimmt Änderungen vor, führt Befehle aus und wiederholt diesen Zyklus, bis die Aufgabe abgeschlossen ist.

Lässt sich die Instruktionsdatei für mehrere Repositories wiederverwenden?

Der Inhalt lässt sich als Vorlage wiederverwenden, die Datei selbst muss aber in jedem Repository einzeln unter .github/copilot-instructions.md abgelegt werden, da Copilot sie projektbezogen einliest.

Was passiert, wenn der CI-Job fehlschlägt?

Mit korrekt eingerichteten Branch-Protection-Regeln kann der Pull Request in diesem Fall nicht in den Hauptbranch gemergt werden, bis entweder der Agent oder ein Teammitglied die fehlgeschlagenen Checks behebt.

Ist der Agent-Modus für kleine Nebenprojekte überhaupt sinnvoll?

Ja, gerade kleine Repositories eignen sich gut als Testumgebung, um Instruktionsdatei, Worktree-Workflow und CI-Checks risikoarm einzuüben, bevor der Workflow in einem größeren Team-Repository zum Einsatz kommt.

Muss ich für jede Agent-Aufgabe einen neuen Worktree anlegen?

Nicht zwingend, aber für größere oder riskantere Aufgaben ist es empfehlenswert. Bei sehr kleinen, risikoarmen Änderungen, etwa einem Tippfehler in einem Kommentar, können Sie auch direkt in einem bestehenden Feature-Branch arbeiten. Sobald der Agent jedoch mehrere Dateien anfassen oder Befehle ausführen soll, lohnt sich die zusätzliche Isolation durch einen eigenen Worktree, da sie das Risiko unbeabsichtigter Seiteneffekte deutlich senkt.

Kann ich mehrere Agenten gleichzeitig in derselben JetBrains-IDE nutzen?

Das Agenten-Auswahlmenü im AI Chat erlaubt den Wechsel zwischen verschiedenen Agenten, etwa GitHub Copilot und einem JetBrains-eigenen Modell, allerdings jeweils für eine Chat-Session zur Zeit. Für echte Parallelität, also mehrere Agenten gleichzeitig an unterschiedlichen Aufgaben, benötigen Sie wie in Schritt 6 beschrieben mehrere geöffnete IDE-Fenster mit jeweils eigenem Worktree.