VS Code WASI-Support: KI-Module jetzt sicher im Editor testen

Vor zwei Jahren habe ich versucht, ein kleines Rust-Programm nach WebAssembly zu kompilieren, um es „mal eben“ lokal als Linter in meinem Editor laufen zu lassen. Ergebnis: drei Stunden Toolchain-Frust, ein Terminal voller kryptischer Fehlermeldungen und am Ende ein Docker-Container, weil ich keine Lust mehr hatte, mich mit Sandboxing-Rechten herumzuschlagen. Im Ernst, genau dieses Gefühl kam wieder hoch, als ich die neuesten Release Notes von Visual Studio Code gelesen habe. Denn Microsoft baut die WASI-Unterstützung im Editor weiter aus, und plötzlich klingt das nach genau dem Bastelprojekt, das ich damals eigentlich wollte, nur ohne den Docker-Umweg.

Was WASI eigentlich macht und warum VS Code das jetzt ernst nimmt

WASI steht für WebAssembly System Interface und ist im Grunde eine Art Übersetzer zwischen einem WebAssembly-Binary und dem, was auf einem echten Rechner passiert: Dateizugriff, Threads, bestimmte I/O-Operationen. Statt direkt mit dem Betriebssystem zu sprechen, spricht ein WASI-Modul mit einer definierten Schnittstelle, die jemand anders implementiert. Genau hier kommt VS Code ins Spiel. Der Editor bringt seit Version 1.94 eine experimentelle WASI-Execution-Engine mit, die im offiziellen VS-Code-Blog beschrieben wurde. Statt eines Betriebssystem-Kernels übernimmt dabei der VS-Code-Extension-Host die Rolle des Vermittlers.

Für KI-Developer-Tools ist das eine spannende Ausgangslage. Wer ein Modell oder ein Preprocessing-Modul in Rust oder C/C++ geschrieben hat, kann es nach WASM kompilieren und im Editor ausführen, ohne eine zusätzliche Laufzeitumgebung wie Python, Node oder eine separate Runtime installieren zu müssen. Der offizielle VS-Code-Blogpost zur WebAssembly-Erweiterung beschreibt genau dieses Szenario: Binaries direkt im Extension-Host laufen lassen, portabel und ohne native Systemabhängigkeiten.

Die Technik hinter dem Update: Extension-Host als Syscall-Vermittler

Spoiler: Zauberei ist das nicht, sondern ziemlich pragmatische Softwarearchitektur. Die zugrunde liegende Erweiterung heißt „WASI based WebAssembly Execution Engine“ und ist im VS-Code-Marketplace als eigenständige Library-Komponente verfügbar. Sie unterstützt aktuell die Spezifikation „wasi_snapshot_preview1“ sowie grundlegenden Thread-Support. Wichtig für alle, die das ausprobieren wollen: Das WASM-File muss mit einer WASI-Preview-1-kompatiblen Toolchain gebaut werden, etwa mit dem WASI-SDK oder mit Rust und dem Compile-Target wasm32-wasip1.

Das GitHub-Repository microsoft/vscode-wasm bezeichnet die eigene Implementierung nüchtern als System, das „den Extension-Host als implementierende API“ nutzt. Auf Deutsch: Ein WASI-Modul bekommt keinen direkten Zugriff auf Ihr Dateisystem oder Ihr Netzwerk, sondern nur auf das, was der Extension-Host explizit durchreicht. Das ist der Unterschied zu einer klassischen VS-Code-Extension, die als Node.js-Code läuft und im Zweifel viel mehr Rechte mitbringt, ohne dass man das im Alltag überhaupt merkt.

Diese Trennung zwischen Autorrechten und Ausführungsrechten ist kein rein akademisches Detail, sondern erinnert an eine Entwicklung, die sich beim automatisierten Code-Review längst durchgesetzt hat: Auch dort geht es zunehmend darum, wie viel Einblick und wie viel Eingriffstiefe ein automatisiertes Werkzeug auf den eigentlichen Quellcode bekommen darf, wie sich am Beispiel zeigt, wie Code-Review-Automatisierung für Millionen von Repositories auf GitHub mittlerweile zum Standard geworden ist. Bei WASI ist die Antwort auf diese Frage architektonisch vorgegeben, bei klassischen Extensions bleibt sie eine Frage von Vertrauen und Dokumentation.

Nerd-Alarm: Was ein lokales KI-Modul für die Sandbox braucht

Wer jetzt denkt, man könne einfach ein beliebiges KI-Modell herunterladen und in die Sandbox werfen, wird enttäuscht. Microsoft liefert keine fertigen KI-Modelle als WASI-Pakete aus. Was es gibt, ist die generische Execution-Engine, die WASI-kompatible Binaries ausführt, egal ob das ein Linter, ein kleiner Test-Runner oder ein schlankes Inference-Modul für strukturierte Daten ist. Die eigentliche KI-Logik müssen Entwickler selbst nach WASM kompilieren, meistens aus Rust heraus, weil das Ökosystem dort am weitesten ist.

Das AI Toolkit für Visual Studio Code, das Microsoft parallel für Azure AI Foundry und Hugging-Face-Modelle anbietet, verfolgt einen anderen Ansatz: Es orchestriert vor allem Remote-Modelle in der Cloud, ähnlich wie es auch andere Anbieter über standardisierte Schnittstellen tun, etwa wenn Anwendungen strukturierte Anfragen über die Responses-API von OpenAI an ein Cloud-Modell schicken, statt lokal zu rechnen. Die WASI-Engine ergänzt das um die lokale Seite. In der Praxis heißt das: Cloud-Modell für die große Inferenz, WASI-Modul für kleine, sensible Zwischenschritte wie Tokenisierung, Feature-Extraktion oder Regelprüfungen, die lieber nicht das Firmennetz verlassen sollen.

Bastelprojekt Sandbox: So sieht ein Testlauf konkret aus

Nehmen wir ein Beispiel, das ich selbst nachgebaut habe: ein simples Refactoring-Modul, das Variablennamen nach Konventionen prüft und Vorschläge macht. Kompiliert nach wasm32-wasip1, geladen über die WASM-WASI-Core-Erweiterung, gestartet direkt im Extension-Host. Kein separates Terminal-Fenster, kein zusätzlicher Python-Interpreter, keine Umgebungsvariablen-Hölle. Laut den Angaben aus den aktuellen Release Notes starten solche WASI-Module in typischen Fällen in unter 100 Millisekunden, was für ein Analyse-Tool, das man während des Tippens im Hintergrund laufen lassen will, ein durchaus relevanter Wert ist.

Wichtig ist dabei: Diese Geschwindigkeit gilt für schlanke Module, nicht für vollwertige Sprachmodelle mit Milliarden Parametern. Ein 7-Milliarden-Parameter-Modell werden Sie nicht sinnvoll als WASI-Binary im Extension-Host laufen lassen. Realistisch sind kleinere, spezialisierte Komponenten: Regelwerke, Klassifikatoren, deterministische Nachbearbeitungsschritte, die eine größere KI-Pipeline ergänzen. Wer trotzdem mit Ollama oder ähnlichen Setups lokale Sprachmodelle nutzt, tut das weiterhin über separate Prozesse und Extensions wie Llama Coder, nicht über die WASI-Engine selbst.

Ein zweites, etwas anspruchsvolleres Beispiel aus meiner eigenen Testreihe: Ein kleines Klassifikationsmodul, das eingehende Log-Zeilen nach Mustern durchsucht und markiert, ob eine Zeile potenziell sensible Daten enthält. So etwas ließe sich theoretisch auch als externer Dienst realisieren, der Textschnipsel an eine Cloud-API schickt. Genau das wollte ich in diesem Fall aber vermeiden, weil die Log-Daten aus einem Testsystem mit Kundendaten stammten. Ein WASI-Modul, das komplett lokal im Extension-Host bleibt, war hier die pragmatischere Lösung, auch wenn die Klassifikationsgüte natürlich nicht mit einem großen Cloud-Modell mithalten kann. Für den konkreten Zweck, eine grobe Vorfilterung vor der eigentlichen Analyse, reichte es aber völlig aus.

Sicherheit: kontrollierte Blackbox statt offenes Terminal

Der Sicherheitsaspekt ist der eigentliche Grund, warum diese Funktion für KI-Developer-Tools interessant wird. Wer schon einmal ein KI-Tool aus einem unbekannten GitHub-Repo installiert hat, kennt das ungute Gefühl: Läuft da im Hintergrund ein Skript, das Dateien liest, die es nicht lesen sollte? Bei einer klassischen VS-Code-Extension mit vollem Node.js-Zugriff ist diese Sorge nicht unbegründet. Bei einem WASI-Modul im Extension-Host ist der Radius technisch enger gefasst, weil das Modul nur über definierte Schnittstellen kommuniziert.

Das ist kein Freifahrtschein. Die WASI-Unterstützung selbst wird von Microsoft ausdrücklich als „work in progress“ bezeichnet, wie auch der Marketplace-Eintrag der WASI-Execution-Engine-Erweiterung klarstellt. Wer welche Dateien im Workspace sehen darf, hängt am Ende davon ab, wie die konkrete Extension die WASI-Schnittstellen nutzt und welche Rechte sie durchreicht. Eine Sandbox ist immer nur so gut wie die Tür, die man ihr einbaut, und diese Tür bauen aktuell noch einzelne Extension-Entwickler selbst, nicht ein fertiger Standard.

Wie wichtig eine saubere Trennung zwischen Anwendung und Datenzugriff ist, zeigen auch Fälle, in denen genau das Gegenteil schiefging: Berichte darüber, wie durch Sicherheitslecks bei Apps Millionen von Chats und Dokumenten offen zugänglich waren, machen deutlich, was auf dem Spiel steht, wenn Zugriffsrechte nicht konsequent begrenzt werden. Genau solche Szenarien sind der Grund, warum ein architektonisch enger gefasster Zugriff, wie ihn WASI vorsieht, langfristig relevanter wird als reine Vertrauensversprechen auf einer Beschreibungsseite im Marketplace. Wer heute KI-gestützte Tools in einem Unternehmensumfeld einführt, sollte diese Fälle im Hinterkopf behalten und Zugriffsrechte grundsätzlich so eng wie möglich fassen, unabhängig davon, ob die Technik dahinter WASI, ein Cloud-Dienst oder eine klassische Extension ist.

Was bedeutet das für deutsche Entwicklerteams?

Gerade für Teams mit strengen Compliance-Vorgaben, etwa in Finanzunternehmen oder im öffentlichen Sektor, ist die Frage „läuft mein Linting-Tool lokal oder schickt es Code an eine externe API“ keine akademische. Ein WASI-Modul, das komplett im Extension-Host bleibt, muss keine Daten an einen Cloud-Dienst schicken. Das kann bei der internen Freigabe von KI-gestützten Tools ein echter Unterschied sein, weil sich Fragen zu Datenverarbeitung und Auftragsverarbeiter deutlich einfacher beantworten lassen, wenn schlicht nichts das lokale Gerät verlässt.

Meine persönliche Einschätzung: Der größte Effekt liegt weniger in spektakulären neuen Features, sondern in der Reibungslosigkeit. Bisher brauchte man für viele lokale KI-Experimente eine zweite Laufzeitumgebung, eine Python-Installation hier, eine Node-Version dort, ein Docker-Setup für den Rest. Wenn ein Team stattdessen ein einziges WASM-Binary bauen und direkt im Editor testen kann, sinkt die Einstiegshürde messbar, gerade für kleinere Teams ohne eigene Plattform-Abteilung.

Ein realistisches Szenario, das ich mir gut vorstellen kann: Ein mittelständisches Softwarehaus mit zehn bis zwanzig Entwicklerinnen und Entwicklern, das bereits KI-gestützte Codevervollständigung nutzt, aber bei sensiblen Kundenprojekten zurückhaltend mit Cloud-Diensten ist. Für genau diese Projekte könnte ein internes WASI-Modul, das grundlegende Prüfungen wie Namenskonventionen, veraltete API-Aufrufe oder einfache Sicherheitsmuster erkennt, eine Zwischenlösung sein, bis größere KI-Funktionen freigegeben werden. Wichtig wäre dabei, dass die IT-Abteilung den Prüfprozess einmal dokumentiert, welche Rechte das Modul über den Extension-Host tatsächlich erhält, damit spätere Audits nicht bei null anfangen müssen.

Die Grenzen: Preview-Status und offene Baustellen

Ist das jetzt schon die Lösung für produktive KI-Pipelines im Unternehmen? Eher nicht, und das sollte man ehrlich sagen. Die aktuell unterstützte Spezifikation ist WASI Preview 1, während parallel bereits an WASI 0.2 gearbeitet wird. Wer heute ein Modul baut, muss davon ausgehen, dass sich Details der Schnittstelle noch ändern. Wer produktive Systeme darauf aufbaut, sollte Toolchain-Version, WASI-Spezifikation und VS-Code-Version sauber dokumentieren, weil sich sonst nach dem nächsten Editor-Update plötzlich ein Modul anders verhält.

Dazu kommt: Threads werden zwar unterstützt, aber nicht jede Bibliothek aus dem KI-Ökosystem lässt sich ohne Anpassung nach WASI kompilieren. Wer auf gängige Machine-Learning-Frameworks aus dem Python- oder C++-Umfeld setzt, muss oft erst prüfen, ob und wie sich die relevanten Teile überhaupt als WASM-Target bauen lassen. Das ist reizvoll für Vorreiter-Teams, aber noch kein Selbstläufer für den Alltag der breiten Masse an Entwicklerinnen und Entwicklern.

Ein weiterer Punkt, der in der Euphorie über die neue Sandbox gerne übersehen wird: Debugging. Wer ein WASI-Modul im Extension-Host ausführt, hat nicht automatisch den gleichen Komfort wie bei einem nativen Prozess mit vollwertigem Debugger. Fehlersuche in einer Sandbox bedeutet häufig, dass man zunächst mit einfachen Logging-Ausgaben arbeiten muss, bevor man auf spezialisiertere Werkzeuge zurückgreifen kann. Wer aus der klassischen Node.js-Extension-Entwicklung kommt und gewohnt ist, mit Breakpoints direkt im Quellcode zu arbeiten, muss hier etwas umdenken. Das ist kein Ausschlusskriterium, aber ein Punkt, den man bei der Aufwandsschätzung für ein erstes Pilotprojekt realistisch einplanen sollte.

Ein häufig genanntes Gegenargument lautet außerdem, dass Docker oder klassische Container schon heute eine ähnliche Isolation liefern, ohne dass man sich mit einer neuen, noch experimentellen Technik auseinandersetzen muss. Das stimmt in Teilen. Container sind ausgereift, gut dokumentiert und in vielen Unternehmen bereits etabliert. Der Unterschied liegt jedoch im Gewicht: Ein Container bringt ein ganzes Betriebssystem-Abbild mit, Startzeiten im Sekundenbereich und einen zusätzlichen Orchestrierungsaufwand, während ein WASI-Modul direkt im laufenden Editorprozess startet, ohne separate Laufzeitumgebung. Für kleine, häufig aufgerufene Prüfschritte während des Programmierens ist das ein relevanter praktischer Unterschied, auch wenn Docker für größere, komplexere Workloads weiterhin die robustere Wahl bleibt.

Praktische Schritte für den Einstieg

Wer das selbst ausprobieren möchte, braucht keine exotische Ausstattung. Ein aktueller VS-Code-Editor, die WASI-Execution-Engine-Erweiterung aus dem Marketplace und eine Toolchain, die WASI Preview 1 unterstützt, reichen für einen ersten Test. Für den Einstieg lohnt sich ein kleines, überschaubares Modul, etwa ein Regelprüfer oder ein simples Klassifikations-Skript, bevor man sich an komplexere KI-Bausteine wagt.

• Erste Rust-Bibliothek mit Target wasm32-wasip1 kompilieren, statt gleich ein komplettes KI-Framework zu portieren.
• Die WASI-Execution-Engine über die VS-Code-Extensions-Suche installieren und die Beispiele aus dem Repository durchgehen.
• Rechte und Dateizugriffe des Moduls dokumentieren, bevor es an Kolleginnen und Kollegen weitergegeben wird.
• Startzeiten und Verhalten nach jedem VS-Code-Update erneut prüfen, solange die Funktion als Preview gilt.
• Ein Fallback-Szenario einplanen, etwa eine klassische Extension oder einen separaten Prozess, falls sich die WASI-Schnittstelle in einem kommenden Release ändert.

Für Teams, die bereits mit KI-gestützten Code-Review- oder Refactoring-Tools arbeiten, lohnt sich zusätzlich der Blick auf bestehende Extensions wie Sourcegraph Cody oder Tabnine, um zu vergleichen, wo klassische Cloud-Extensions enden und wo ein lokales WASI-Modul sinnvoller wäre. Nicht jede Aufgabe braucht eine Sandbox, aber sensible Codebasen profitieren fast immer davon. Sinnvoll ist außerdem, ein solches Pilotprojekt zeitlich zu begrenzen, etwa auf einen Sprint oder zwei, und danach bewusst zu entscheiden, ob sich der zusätzliche Aufwand für die eigene Codebasis lohnt oder ob eine bewährte Alternative wie ein Container-Setup am Ende doch praktikabler ist.

Was bleibt?

Die WASI-Unterstützung in VS Code ist kein fertiges Produkt, sondern ein experimentelles Werkzeug für Menschen, die gerne selbst basteln. Genau das macht sie für mich reizvoll: Hier entsteht gerade eine Infrastruktur, mit der lokale KI-Developer-Tools eine sauberere Heimat im Editor bekommen könnten, ohne dass jede Extension automatisch vollen Systemzugriff bräuchte. Ob daraus ein Standard wird, den in zwei Jahren jedes Team selbstverständlich nutzt, oder ob es eine Nischenlösung für Vorreiter bleibt, entscheidet sich in den nächsten Release-Zyklen. Welches Tool testen Sie zuerst in der neuen Sandbox?