Copilot Surfaces, CLI und Cloud Agent

Warum diese Seite wichtig ist

Die meiste Verwirrung um Copilot entsteht, weil Leute die falschen Oberflächen vergleichen. Diese Seite trennt die lokalen, editor-first-, terminal-first- und cloud-ausgeführten Modi, damit du den richtigen für die Aufgabe wählst, statt zu erwarten, dass sich eine Oberfläche wie eine andere verhält.

1. Die vier wichtigsten Ausführungsstile

Modus	Läuft wo	Am besten für	Was zu erwarten ist
IDE-Vorschläge und Chat	in deinem Editor	schnelle Hilfe, Erklärungen, kurze Edits	schnellstes Feedback, geringste Autonomie
IDE-Agent-Modus	deine lokale Entwicklungsumgebung	Multi-Datei-Fixes, lokale Test-Schleifen	autonome Edits, weiterhin lokal
Copilot CLI	dein Terminal	shell-first-Coding und Repo-Aufgaben	starke lokale Kontrolle, skriptbar
Copilot Cloud Agent	GitHub-Actions-gestützte Umgebung	asynchrone Issue-Arbeit, Branch- + PR-Generierung	Hintergrundausführung auf GitHub

2. IDE-Chat und Agent-Modus

In der IDE deckt Copilot zwei unterschiedliche Bedürfnisse ab:

• Chat und Vorschläge für unmittelbare Hilfe beim Coden,
• Agent-Modus für größere Edit-Schleifen, in denen Copilot Änderungen machen, Checks ausführen und iterieren kann.

Das ist der natürlichste Ausgangspunkt für Entwickler, die ohnehin in VS Code, JetBrains, Visual Studio, Neovim oder ähnlichen Umgebungen leben. Es hält den Menschen in der Schleife und macht die Review-Reibung gering.

Nutze den IDE-Agent-Modus, wenn:

• die Aufgabe größer als eine einzelne Vervollständigung ist,
• du lokales Feedback aus deinem tatsächlichen Workspace willst,
• das Repo bereits ausgecheckt und bereit ist,
• du trotzdem enge Aufsicht über jeden Schritt willst.

3. Copilot CLI

GitHub dokumentiert die Copilot CLI als über alle Copilot-Pläne hinweg verfügbar, unterliegt jedoch der Organisationsrichtlinie, wenn der Seat organisationsverwaltet ist. Sie gibt dir einen Agenten im Terminal statt im Editor.

Was sie nützlich macht:

• sie unterstützt interaktive und programmatische Nutzung,
• sie kann mit Repository-Dateien und Shell-Befehlen arbeiten,
• sie unterstützt Custom Instructions, Custom Agents und MCP-Server,
• sie kann mit lokalem oder Cloud-Sandboxing laufen,
• sie kann über ACP als Agent-Endpoint genutzt werden.

Was sie von älteren „Assistent in der Shell"-Tools unterscheidet, ist, dass GitHub sie klar als echte Agent-Laufzeit behandelt, nicht nur als Befehlsvorschläger.

Wann die Copilot CLI die beste Copilot-Oberfläche ist

Wähle die Copilot CLI, wenn:

• du in Befehlen, Diffs und Test-Läufen denkst,
• du Copilot-Interaktionen automatisieren oder skripten willst,
• du einen local-first-Agenten brauchst, das GitHub-Ökosystem aber nicht verlassen willst,
• du eine Brücke zwischen Terminal-Workflows und GitHub-nativen Agent-Features willst.

Wichtige Sicherheitsgewohnheiten für die Copilot CLI

GitHubs Doku ist eindeutig darin, dass die Copilot CLI in deinem Namen lesen, modifizieren und ausführen kann. In der Praxis bedeutet das:

• starte sie nur aus vertrauenswürdigen Projektverzeichnissen,
• prüfe Freigaben und Shell-Aktionen sorgfältig,
• bevorzuge Sandboxing für riskante oder experimentelle Aufgaben,
• vermeide es, sie aus breiten Verzeichnissen wie deinem Home-Ordner auszuführen.

Wenn dein Team einen Terminal-Agenten will, sich aber Sorgen um den Blast Radius macht, ist CLI-Sandboxing eines der ersten Dinge, die eine Evaluierung wert sind.

4. Copilot Cloud Agent

Der Copilot Cloud Agent ist die asynchrone Seite des Produkts. Statt deinen lokalen Checkout zu bearbeiten, arbeitet er in einer isolierten Umgebung auf GitHub, kann ein Repository recherchieren, Änderungen auf einem Branch vornehmen und optional einen Pull Request öffnen.

Das ist das richtige mentale Modell:

• Agent-Modus in der IDE = lokales autonomes Pair Programming,
• Cloud Agent = remote delegierte Engineering-Arbeit.

Gute Anwendungsfälle für den Cloud Agent

Der Cloud Agent ist besonders nützlich für:

• Backlog-Aufräumen,
• wiederkehrende Wartungsaufgaben,
• Issue-zu-PR-Delegation,
• Repository-Recherche und Planung vor der Implementierung,
• das Öffnen eines ersten Entwurfs, den ein Entwickler verfeinern kann.

Er ist oft wertvoller als paralleler Arbeiter denn als Ersatz für aktive Entwicklung.

Warum der Cloud Agent den Workflow verändert

Der GitHub-native Vorteil ist nicht nur Code-Generierung. Es ist Workflow-Verdichtung:

• die Branch-Erstellung ist automatisch,
• Commits passieren im Hintergrund,
• Pull Requests können zum Review erstellt werden,
• die Iteration kann aus Issues, Kommentaren oder Chat auf GitHub fortgesetzt werden.

Das macht den Cloud Agent zu einer starken Wahl für Teams, die ihre Arbeit ohnehin über Issues und Pull Requests organisieren.

Vorsichtshinweise und Einschränkungen

Ein paar praktische Vorbehalte sind wichtig:

• die Verfügbarkeit des Cloud Agent hängt von Plan und Admin-Richtlinie ab,
• die Nutzung verbraucht sowohl AI-Credits als auch GitHub-Actions-Kapazität,
• Repository-Eigentümer können Repositories ausschließen,
• die Umgebung ist zeitlich begrenzt und kein Ersatz für unbegrenzte Hintergrund-Compute.

Nutze den Cloud Agent für begrenzte Aufgaben mit klaren Akzeptanzkriterien, nicht für vage „fix the whole codebase"-Prompts.

5. Ein einfaches Betriebsmodell

Für viele Teams sieht der beste kombinierte Workflow so aus:

1. Erkunde und kläre im IDE-Chat oder auf GitHub.
2. Nutze den Agent-Modus oder die Copilot CLI für lokale Iteration.
3. Nutze den Cloud Agent für Arbeit, die asynchron weiterlaufen sollte.
4. Reviewe jeden generierten Branch oder PR wie normalen Engineering-Output.

Das hält Copilot in der Rolle eines produktiven Mitarbeiters, nicht einer ungeprüften Änderungsquelle.