GitHub Copilot im Detail: Kontext, Speicher und Netzwerkverkehr analysiert

GitHub Copilot im Detail: Kontext, Speicher und Netzwerkverkehr analysiert
Deine Reaktion:

Die meisten halten GitHub Copilot für eine simple Anfrage an ein Sprachmodell: Tippen, Enter, fertig. Wer den Netzwerkverkehr der VS-Code-Erweiterung beobachtet, findet ein komplexes System aus Authentifizierung, Modell-Routing und Kontext-Sammlung. Rafael, ein Entwickler, hat das analysiert und zeigt, wie Copilot wirklich arbeitet.

Rafael ist Ingenieur und betreibt den Newsletter „Lighthouse“ über KI-Systeme. Er interessiert sich für Electron-basierte Desktop-Apps – ein Framework, das Webtechnologien wie HTML, CSS und JavaScript mit Node.js bündelt und in Chromium rendert. Viele KI-Tools wie Cursor, Notion oder ChatGPT Desktop setzen darauf. Rafael wollte wissen, was diese Apps nach außen senden. Der Auslöser war ein praktisches Problem: Sein Copilot-Kontingent war Monat für Monat schneller aufgebraucht, als ihm lieb war. Das brachte ihn dazu, VS Code und Copilot genauer zu analysieren.

Warum Electron-Apps eine Fundgrube für Reverse Engineering sind

Electron hat einen schlechten Ruf, was Ressourcenverbrauch angeht, aber für Reverse Engineering ist es nützlich. Da die App-Grundstruktur aus Chromium und Node.js besteht, kannst du den Netzwerkverkehr fast beliebig abgreifen. Es gibt zwei Hauptwege, über die eine Electron-App HTTP-Anfragen schickt: über die Netzwerkfunktionen des Browsers (Chromium-API) oder über Node.js-Module wie http oder fetch. Für die Analyse ist wichtig, welcher Weg genutzt wird, weil sich beide unterschiedlich abfangen lassen.

VS Code hat eine zusätzliche Besonderheit: eine Prozessarchitektur mit dediziertem Extension Host. Erweiterungen – inklusive Copilot – laufen in einem eigenen Prozess, getrennt von der Oberfläche. Ein Absturz einer Erweiterung reißt dann nicht die ganze IDE mit. Das macht die Analyse aber kniffliger, denn der Extension Host kann eigene Netzwerkverbindungen aufbauen.

Rafael nutzte diese Architektur, um Copilot zu untersuchen. Sein Plan: Ein Proxy-Server zwischen App und Internet schaltet sämtliche HTTP- und WebSocket-Verbindungen mit. Dafür verwendet er mitmproxy, ein Open-Source-Tool, das als Man-in-the-Middle arbeitet. Der Proxy fängt Anfragen ab, leitet sie an den Zielserver weiter und reicht Antworten zurück. Bei HTTPS erzeugt er ein eigenes Zertifikat, dem der Client vertrauen muss. Dadurch entstehen zwei TLS-Verbindungen – eine zwischen App und Proxy, eine zwischen Proxy und Server – und der Proxy liest den Datenverkehr im Klartext.

Für macOS beschreibt Rafael die Installation mit Homebrew und das Einrichten in VS Code. Du setzt in den Benutzereinstellungen den HTTP-Proxy auf localhost:8080, deaktivierst striktes SSL und erzwingst Proxy-Unterstützung für Erweiterungen. Nach einem Neustart erscheint im mitmweb-Interface ein Strom von Requests, die du filtern kannst – etwa mit marketplace, um nur den Traffic zur Marketplace-API zu sehen. Ein Stolperstein: Der Extension-Host-Prozess wird manchmal nicht korrekt aktualisiert. Die Lösung: Über die Befehlspalette „Developer: Restart Extension Host“ ausführen und prüfen, ob die Prozess-IDs mit dem aktuellen Zeitstempel übereinstimmen.

Mit mitmproxy dem Copilot in die Karten schauen

Nachdem die Infrastruktur stand, analysierte Rafael die Requests. Bereits beim Start sendet VS Code eine Reihe von Anfragen an GitHub und Copilot – noch bevor du eine Eingabe machst. Diese Bootstrap-Phase lässt sich in Kategorien unterteilen: Authentifizierung & Session, Konfiguration & Richtlinien, Registry für MCP, Repository- und Session-Kontext, Modell-Erkennung sowie zuletzt geöffnete Repositories. Die Verteilung zeigt: Der Großteil des Netzwerkverkehrs betrifft GitHub oder Copilot, nicht den Marketplace.

Die erste Aktion von Copilot ist die OAuth-Authentifizierung. Der Client holt ein OAuth-Token, tauscht es gegen ein kurzlebiges Token und prüft die Berechtigung. Das ist ein klassischer OAuth-Ablauf. Es beginnt mit einem Redirect zu GitHub, dann folgt der Token-Austausch, am Ende steht eine validierte Session. Dieser Prozess läuft bei jedem Neustart von VS Code durch – selbst wenn du eingeloggt bist. Das erklärt die vielen Requests beim Start.

Danach folgt die Modell-Erkennung. Copilot fragt zuerst eine Liste der verfügbaren Modelle über den Endpunkt /models ab. Kurz darauf geht eine zweite Anfrage an /agents/swe/models, speziell für Agents mit Software-Engineering-Fähigkeiten. Hier erfährt Copilot, welche Modelle für dich und deinen Plan freigeschaltet sind. Das beeinflusst, welche Modelle später ausgewählt werden.

Zusätzlich lädt die Erweiterung Konfigurations- und Richtlinieninformationen, vermutlich um Enterprise-Policies oder Datenschutzeinstellungen durchzusetzen. Auch eine Registry für MCP (Model Context Protocol) wird abgerufen. MCP ist ein Standard, über den KI-Anwendungen auf externe Tools und Datenquellen zugreifen. In der Registry sind die verfügbaren Tools und Ressourcen verzeichnet. Rafael erwähnt außerdem, dass die zuletzt geöffneten Repositories mitgeschickt werden – vermutlich um den Arbeitskontext vorzuladen, damit die KI schneller auf relevante Dateien zugreifen kann.

Was VS Code beim Start bereits an GitHub schickt

Die Menge an Daten, die beim Start übertragen wird, ist beachtlich. Rafael hat die prozentuale Verteilung der Requests während der Bootstrap-Phase in einem Diagramm festgehalten. Es zeigt: Nicht der Marketplace dominiert, sondern GitHub-spezifische Endpunkte. Copilot ist also tief in die Grundfunktionen von VS Code integriert – selbst wenn du es nicht aktiv nutzt, läuft ein ständiger Austausch mit den GitHub-Servern.

Für Nutzer mit sensiblen Projekten ist das relevant. Beim Start werden automatisch Kontext wie Repositories, Session-Informationen und Modell-Verfügbarkeit übertragen. GitHub erhält ein detailliertes Bild deiner Arbeitsumgebung, unabhängig davon, ob du eine KI-Empfehlung anforderst. Rafael merkt an, dass diese Requests nicht dokumentiert sind, aber durch Netzwerkanalyse sichtbar werden. So wird Transparenz geschaffen.

Er testete außerdem, ob das Bearbeiten einer .env-Datei mit geheimen Schlüsseln automatisch einen HTTP-Request auslöst. Das passierte nicht. Die bloße Änderung sendet keinen Inhalt nach außen. Das bedeutet nicht, dass der Inhalt nicht in den Kontext aufgenommen wird, wenn du Copilot darauf ansprichst. Es zeigt nur, dass kein Hintergrund-Versand ohne deine Aktion erfolgt. Für alle, die sorgen, ihre Schlüssel könnten unbemerkt hochgeladen werden, ist das beruhigend.

Ein weiterer Befund ist die Intent-Klassifikation. Nachdem du eine Nachricht im Auto-Modus sendest, geht eine Anfrage an den Endpunkt /models/session/intent. Diese Anfrage bewertet dein Prompt und ordnet ihn einer Kategorie zu – etwa code-gen, debugging, reasoning oder tool-use. Erst danach wird das passende Modell ausgewählt und die Generierung gestartet. Diese Klassifikation ist nicht immer dokumentiert, aber sie spart Kosten, weil teure Modelle gezielt eingesetzt werden. Rafael beobachtete das live, obwohl es bereits in der Copilot-Dokumentation erwähnt wird.

Wie Copilot das passende Modell für deine Anfrage wählt

Die Intent-Klassifikation ist der erste Schritt in einer mehrstufigen Pipeline. Nachdem die Absicht erkannt ist, wählt ein Modell aus der zuvor abgerufenen Liste. Das erklärt, warum Copilot mit verschiedenen Modellen arbeitet – je nach Aufgabe nutzt es kleinere, schnellere Modelle oder mächtigere, langsamere. Der Wechsel passiert automatisch und ist für dich unsichtbar, es sei denn, du schaust genau hin.

Rafael untersuchte auch die Inline-Vervollständigung (Ghost Text). Während des Schreibens sendet die Erweiterung ständig Kontext an den Server – in der Regel den aktuellen Inhalt der geöffneten Datei. Das war zu erwarten. Überraschend war, wie viel zusätzlicher Kontext mitgeschickt wird: häufig der gesamte Inhalt des aktuellen Tabs sowie relevante Ausschnitte aus anderen geöffneten Dateien. Diese Informationen werden als Teil des Prompt-Kontexts zusammengebaut und an das Modell übertragen.

„Speicher“ bei Copilot ist also kein dauerhafter Verlauf. Es ist ein flüchtiger Kontext-Puffer, der für jede Anfrage neu aufgebaut wird. Was hineingelangt, hängt von deiner Aktion ab – welche Datei du bearbeitest, welche Symbole du referenzierst, welche Änderungen vorliegen. Copilot baut sich ein situatives Bild, das weit über die Prompt-Zeile hinausgeht. Dieses Vorgehen ist nötig für qualitativ hochwertige Vorhersagen, aber es bedeutet auch, dass ein großer Teil deines Codes die lokale Umgebung verlässt.

Die Netzwerk-Traffic-Analyse deckte zudem auf: Verbindungen führen nicht nur zu GitHub, sondern auch zu Azure-basierten Endpunkten, wo die eigentliche Inferenz stattfindet. Die Trennung zwischen Authentifizierung (GitHub) und Inferenz (Azure) ist ein bekanntes Muster. Gut zu wissen: Die API-Schlüssel gehen nicht an Dritte. Der OAuth-Token wird ausschließlich für die GitHub-Authentifizierung verwendet, die Inferenz-Endpunkte nutzen kurzfristige, gesonderte Tokens.

Kontext und Speicher: Was mit deiner Anfrage mitreist

Copilot ist also mehr als ein simpler „Prompt in, Antwort raus“-Dienst. Die Architektur kombiniert Identitätsmanagement, Modell-Routing und Kontext-Konstruktion. Für dich als Nutzer bedeutet das: Je präziser du dein Arbeitsumfeld pflegst – relevante Dateien geöffnet lässt, klare Namen verwendest, die Projektstruktur sauber hältst – desto bessere Vorschläge bekommst du, weil der Kontext auf soliden Informationen basiert.

Für Entwickler, die ähnliche KI-Funktionen einbauen möchten, liefert die Analyse eine Vorlage. Sie zeigt, wie man mit einem Proxy, ein paar Einstellungen und etwas Geduld die Netzwerkkommunikation einer Electron-App nachvollzieht. Das ist nicht nur für Reverse Engineering nützlich, sondern auch für das Debugging eigener Anwendungen. Wer versteht, welche Daten die App sendet, kann Leistung optimieren, Datenschutzrisiken erkennen und Serverlast reduzieren.

Copilot ist keine simple HTTP-API, die einen Prompt an ein LLM schickt. Es ist ein komplexes System mit mehreren Verarbeitungsstufen. Die Netzwerk-Traffic-Analyse von Rafael zeigt, wie tief es in VS Code integriert ist. Wer die Requests selbst beobachtet, versteht die Integration besser. Die Analyse ist einfach durchzuführen – und die Erkenntnisse sind oft erstaunlich.

Quelle: lighthousenewsletter.com

Deine Reaktion:
Artikel teilen:
Krötzsch-Check0 — 100
Fakten 90
Relevanz 85
Hype 20
Einschätzung 85
Redaktion 50 Stand 50 · noch keine Stimmen
Ist das Hype?
Sebastian Krötzsch
Autor

Sebastian Krötzsch

Sebastian Krötzsch schreibt auf sebask.de über Künstliche Intelligenz, Automatisierung, digitale Systeme und die Frage, was davon im Alltag wirklich nützlich ist. Ohne Buzzword-Nebel, dafür mit klarem Blick auf Praxis, Tools und echte Wirkung.