Data Engineering Expert

Die Lücke schließen: Ausführung nativer Windows-MCP-Server in sandboxierten KI-Agenten (Claude & Gemini CLI)

Lesezeit
4 ​​min

TL;DR:

Problem: In einer Sandbox ausgeführte Linux-Container-Agenten in WSL2 (Claude Code, Gemini CLI) können Windows-MCP-Server (wie den Power BI Modeling MCP) aufgrund von Transportbeschränkungen über Betriebssystemgrenzen hinweg, Blockierungen durch die Hyper-V-Firewall am Port 3000 und Problemen beim JSON-RPC-Stream-Framing nicht nativ ausführen.

Lösung: Ein auf dem Windows-Host ausgeführtes Node.js-Proxy-Skript empfängt HTTP-Anfragen vom Container, wandelt diese in native stdio-Prozesskommunikation des Hosts um, aggregiert fragmentierte JSON-Nutzdaten und verarbeitet asynchrone Benachrichtigungen sicher.



Dieser Beitrag ist eine (teil-)automatisierte Übersetzung des englischen Originals.

Durch die Integration von MCP-Servern (Model Context Protocol) in Entwicklertools erhalten Sprachmodelle direkten, strukturierten Kontext aus lokalen Umgebungen. In Verbindung mit Tools wie dem „Power BI Modeling MCP“ von Microsoft können CLI-Agenten wie Claude Code (claude) und Gemini CLI (gemini) tabellarische Modelle auswerten, DAX-Abfragen ausführen und TMDL-Definitionen in Echtzeit in lokalen Power BI Desktop-Instanzen ändern.

Sicherheitsrichtlinien schreiben jedoch vor, dass KI-CLI-Agenten in Sandbox-Umgebungen (wie Podman- oder Docker-Linux-Containern) ausgeführt werden müssen. Dies führt zu einem gravierenden Konflikt, wenn versucht wird, Windows-native Binärdateien aus einer isolierten Linux-Laufzeitumgebung heraus auszuführen.

Dieser Artikel beschreibt die damit verbundenen architektonischen Hindernisse – einschließlich der Einschränkungen der Windows 11 Hyper-V-Firewall – und stellt ein leichtgewichtiges Node.js-Proxy-Skript bereit, das die Kommunikation zwischen CLI-Agenten in der Sandbox und nativen Windows-Ausführungsdateien überbrückt.

Technische Herausforderungen auf Windows-Hostsystemen

Bei der Ausführung von Agent-CLIs mit aktivierter Container-Sandbox-Funktion treten vier wesentliche Probleme auf:

  1. Inkompatibilitäten zwischen Betriebssystem und DLLs
    Die Power BI Modeling MCP-Server-Binärdatei (.exe) ist auf Windows-Systembibliotheken wie iphlpapi.dll (IP Helper API) angewiesen, um laufende Power BI Desktop-Instanzen zu erkennen. Innerhalb einer Linux-Container-Sandbox sind diese Windows-Bibliotheken nicht vorhanden, was dazu führt, dass Standardausführungsversuche unter Linux sofort fehlschlagen.
  2. Trennung der Transportschicht (stdio vs. HTTP/SSE)
    MCP-Server kommunizieren in der Regel über Standard-Ein- und -Ausgabe (stdio). Eine containerisierte Sandbox kann native stdio-Streams nicht direkt an eine auf dem Host-Betriebssystem ausgeführte ausführbare Datei anbinden. Die Kommunikation muss in Netzwerkprotokolle wie HTTP oder SSE umgewandelt werden.
  3. Einschränkungen der Hyper-V-Firewall (Windows 11 22H2+)
    Die Hyper-V-Firewall filtert den Datenverkehr, der über virtuelle Netzwerkadapter fließt, die für Container-Laufzeiten und WSL erstellt wurden. Selbst wenn die Standardports der Windows Defender-Firewall offen sind, wird eingehender Datenverkehr vom virtuellen Container-Switch zum Host standardmäßig verworfen, sofern er nicht ausdrücklich zugelassen wird.
  4. Unterschiede beim Stream-Framing und beim JSON-RPC-Protokoll
    MCP-Implementierungen unter Windows unterteilen JSON-Nutzdaten häufig in fragmentierte Datenblöcke oder fügen Längen-Header hinzu. Die rohe TCP-Weiterleitung führt zu Parsing-Fehlern wie „Unerwartetes Ende der JSON-Eingabe“. Zudem erwarten standardmäßige JSON-RPC-Benachrichtigungsmethoden (wie „notifications/initialized“) keine Antworten, was dazu führt, dass synchrone Listener eine Zeitüberschreitung verzeichnen.

Die grobe Übersicht für Claude und für Gemini ist unten dargestellt:

Implementierungsanleitung

Schritt 1: Konfigurieren der Windows Hyper-V-Firewall-Regeln

Da der Container-Datenverkehr über einen virtuellen Hyper-V-Switch geleitet wird, führen Sie den folgenden Befehl in PowerShell als Administrator aus, um eingehenden Datenverkehr auf Port 3000 vom Container-Switch zuzulassen:

 Schritt 2: Bereitstellung des Node.js-Bridge-Skripts (bridge.js)

Speichern Sie dieses Proxy-Skript auf Ihrem Windows-Host. Es verarbeitet nicht blockierende Benachrichtigungen, aggregiert fragmentierte stdout-Puffer und stellt die ausführbare Datei über HTTP bereit.

Schritt 3: Konfiguration der CLI-Clients

Option A: Konfiguration der Gemini CLI (gemini)

Fügen Sie den Bridge-Eintrag zu Ihrer Datei „settings.json“ hinzu:

Option B: Konfiguration von Claude CLI (claude / Claude Code)

Fügen Sie den Bridge-Eintrag in Ihre Datei .mcp.json oder ~/.claude.json ein:

Schritt 4: Überprüfung und Arbeitsablauf

  1. Starten Sie die Bridge auf dem Windows-Host:
  2.   Rufen Sie die Tool-Erkennung in Ihrem bevorzugten CLI-Client auf:
    • Für Gemini CLI: /mcp refresh
    • Für Claude CLI: claude mcp list oder /mcp

Fazit

Durch die Kombination gezielter Hyper-V-Firewall-Regeln mit einer Node.js-Proxy-Brücke können in einer Sandbox ausgeführte CLI-Agenten wie Claude CLI und Gemini CLI nahtlos mit Windows-nativen MCP-Servern interagieren. Diese Konfiguration gewährleistet eine vollständige Containerisolierung und gewährt Ihren KI-Agenten gleichzeitig uneingeschränkten Zugriff auf lokale Power BI-Modelle.

Jobs bei inovex Freie Stellen
*Gender, Herkunft etc. sind keine Bewertungskriterien. Hauptsache, du bist genauso technologiebegeistert wie wir.

Hat dir der Beitrag gefallen?

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

inoNews

5 gute Gründe für den inovex Newsletter:

  • Exklusive Insights & Tipps unserer inovexperts
  • Infos und Updates zu IT-Trend-Themen & Angeboten
  • Trainingsrabatte & Eventeinladungen
  • Gratis Whitepapers & Infosheets
  • Austausch- & Beratungsoptionen

Zur Newsletter-Anmeldung