Mit den Versionen 2.14 und 2.15 hat der KI-Stack einen entscheidenden Schritt gemacht: Aus einem lokalen KI-System, das bisher vor allem Modelle, RAG, Bild- und Video-Workflows sowie spezialisierte Agenten bereitstellt, wird zunehmend eine Plattform, die kontrolliert mit dem lokalen Rechner interagieren kann.
Der Weg dorthin erfolgte bewusst in zwei Schritten.
Version 2.14 integriert mit Open Terminal erstmals einen verwalteten lokalen Ausführungspfad. Version 2.15 führt anschließend mit dem Model Context Protocol, kurz MCP, eine standardisierte Tool-Schnittstelle ein und macht diese zum bevorzugten Zugriffspfad für terminalfähige Open-WebUI-Profile.
Der eigentliche Entwicklungsschritt lautet damit:
Lokaler Terminalzugriff → standardisierte MCP-Tool-Schnittstelle
Dabei wurde bewusst darauf verzichtet, funktionierende Komponenten sofort wieder zu ersetzen. Open Terminal bleibt auch nach der MCP-Migration vollständig erhalten und dient weiterhin als validierter Fallback.
Warum überhaupt lokaler Systemzugriff?
Ein lokales Sprachmodell kann zunächst nur Text verarbeiten und Text erzeugen.
Es kann beispielsweise erklären, welcher PowerShell-Befehl einen Windows-Dienst neu startet oder wie eine Konfigurationsdatei geändert werden müsste. Ohne zusätzliche Werkzeuge kann es diese Aktion jedoch nicht selbst durchführen.
Für einen praktisch nutzbaren lokalen KI-Assistenten reicht das auf Dauer nicht aus.
Typische Aufgaben wären beispielsweise:
- eine Datei aus einem Projektverzeichnis lesen
- eine Konfiguration ändern
- einen Prozess starten oder stoppen
- ein Logfile untersuchen
- einen PowerShell-Befehl ausführen
- den Status einer lokalen Anwendung prüfen
- Dateien innerhalb eines definierten Arbeitsbereichs suchen
Dafür benötigt das Sprachmodell einen kontrollierten Zugriff auf Werkzeuge des Betriebssystems.
Genau diese Grundlage wurde mit KI-Stack 2.14 geschaffen.
KI-Stack 2.14 – Open Terminal wird Teil des Stacks
Open Terminal wurde in Version 2.14 nicht einfach als zusätzlich installiertes Drittprogramm eingebunden.
Es wurde als eigenständige, verwaltete Komponente in den Complete Installer aufgenommen.
Damit folgt Open Terminal denselben grundlegenden Betriebsprinzipien wie andere isolierte Komponenten des KI-Stacks: Installation, Upgrade, Repair, Backup, Rollback und Versionsprüfung sind Bestandteil des bestehenden Installationsmodells.
Die Komponente besitzt einen eigenen Einstiegspunkt und einen eigenen lokalen Zustand. Dadurch bleibt sie von anderen Komponenten weitgehend entkoppelt.
Das ist wichtig, weil ein Werkzeug mit Zugriff auf das lokale System betrieblich deutlich kritischer ist als beispielsweise eine rein statische Konfigurationsdatei.
Kein zusätzlicher Docker-Stack
Open Terminal läuft im KI-Stack direkt unter Windows.
Der Dienst wird über die bestehende Python- beziehungsweise uv-Umgebung gestartet. Ein zusätzlicher Docker-Container ist dafür nicht notwendig.
Die Runtime wird unter einem definierten lokalen Pfad aufgelöst und nicht davon abhängig gemacht, dass irgendeine zufällig vorhandene globale Installation von uvx oder Python verfügbar ist.
Damit bleibt die Installation reproduzierbar.
Der Dienst bindet ausschließlich an:
127.0.0.1:8000
Er ist damit nicht direkt über das lokale Netzwerk erreichbar.
Open WebUI bleibt weiterhin die zentrale Benutzeroberfläche.
Lokales Credential statt offener Schnittstelle
Ein lokaler Dienst auf 127.0.0.1 ist zwar nicht unmittelbar aus dem Netzwerk erreichbar, sollte aber trotzdem nicht vollständig ungeschützt betrieben werden.
Deshalb erzeugt der KI-Stack für Open Terminal einen zufälligen 256-Bit-API-Schlüssel.
Dieser Schlüssel wird nicht im Klartext in einer Konfigurationsdatei abgelegt.
Stattdessen wird er mit Windows DPAPI im Benutzerkontext geschützt gespeichert.
Das Credential wird erst beim Start des Prozesses in dessen Umgebung eingebracht.
Es landet damit nicht:
- im Git-Repository
- in Startskripten
- in Konfigurationsdateien im Klartext
- in normalen Logdateien
Der Schlüssel bleibt außerdem über Neustarts, Upgrades und Reparaturen hinweg stabil, solange keine explizite Rotation erfolgt.
Damit muss nicht nach jedem Update die gesamte Tool-Verbindung neu aufgebaut werden.
Sicherer Umgang mit Prozessen
Ein Detail der Implementierung ist für die Betriebssicherheit besonders relevant.
Windows verwendet Prozess-IDs wieder.
Ein Prozess mit beispielsweise PID 1234 kann beendet werden. Später kann Windows dieselbe PID einem völlig anderen Prozess zuweisen.
Deshalb reicht es bei einem verwalteten Dienst nicht aus, beim Stoppen einfach eine gespeicherte PID zu verwenden.
Open Terminal wird im KI-Stack deshalb über die Kombination aus Prozess-ID und tatsächlicher Kommandozeile identifiziert.
Erst wenn der Prozess zur erwarteten Open-Terminal-Instanz gehört, darf er beendet werden.
Damit wird verhindert, dass durch eine veraltete Statusdatei versehentlich ein anderer Prozess beendet wird.
Integration in den zentralen Lifecycle
Open Terminal ist seit 2.14 in die zentralen Start-, Stop- und Statusmechanismen des KI-Stacks eingebunden.
Damit startet der Dienst zusammen mit den übrigen verwalteten Komponenten und wird auch über die zentrale Statusabfrage erfasst.
Ein separater manueller Betriebsweg ist dadurch nicht notwendig.
Das klingt zunächst nach Komfort, ist aber vor allem eine Frage der Betriebsführung.
Wenn eine Komponente Bestandteil einer Plattform ist, sollte sie auch über deren normale Betriebswerkzeuge steuerbar sein.
Open WebUI bleibt das Frontend
Open Terminal selbst soll keine zusätzliche Benutzeroberfläche schaffen.
Der Nutzer arbeitet weiterhin über Open WebUI.
In 2.14 musste die Verbindung zwischen Open WebUI und Open Terminal allerdings noch manuell über die OpenAPI-Schnittstelle eingerichtet werden.
Damit funktionierte der lokale Tool-Zugriff bereits, architektonisch war diese Lösung aber noch stark an die konkrete Open-Terminal-API gebunden.
Genau hier setzt Version 2.15 an.
Neben Open Terminal: Verbesserungen am Complete Installer
Während der realen Installationstests für 2.14 wurden gleichzeitig mehrere Schwächen des Complete Installers sichtbar.
Eine davon betraf erhöhte Installationsläufe.
Wurde der Installer über UAC mit Administratorrechten neu gestartet, wurden Statusinformationen intern zwar bereits erzeugt, erschienen aber erst nach Abschluss des erhöhten Prozesses in der ursprünglichen Konsole.
Bei längeren Installationen entstand dadurch der Eindruck, dass nichts passiert.
Seit 2.14 wird der laufende Transcript-Status auch während des erhöhten Prozesses sichtbar ausgegeben.
Gleichzeitig wurde diese Ausgabe gefiltert.
Interne PowerShell-Transcriptzeilen, Trennmarker und doppelte Abschlussausgaben werden nicht mehr zusammen mit den eigentlichen Statusinformationen angezeigt.
Damit wurde nicht nur die Funktionalität, sondern auch die Bedienbarkeit des Installers verbessert.
Stabilere Transaktionsdaten
Ein weiterer Fehler betraf das Feld centralStarters innerhalb des Installationszustands.
PowerShell besitzt an mehreren Stellen ein automatisches Verhalten zum Entpacken von Arrays.
Bei genau einem Element kann aus einem erwarteten Array dadurch unbeabsichtigt ein einzelnes Objekt werden.
Für menschliche Leser ist das oft kaum relevant.
Für automatisierte Verarbeitung ist es dagegen problematisch.
Ein Parser erwartet entweder:
[
{
"name": "example"
}
]
oder plötzlich:
{
"name": "example"
}
Seit Version 2.14 bleibt centralStarters deshalb unabhängig von null, einem oder mehreren Einträgen immer ein echtes JSON-Array.
Solche Details gehören zu den weniger sichtbaren, aber wichtigen Grundlagen für reproduzierbare Installations- und Recovery-Prozesse.
KI-Stack 2.15 – MCP wird die neue Tool-Schicht
Mit 2.14 war der lokale Zugriff technisch vorhanden.
Die nächste Frage lautete:
Soll Open WebUI dauerhaft über eine proprietäre OpenAPI-Anbindung direkt mit Open Terminal kommunizieren?
Die Antwort war nein.
Mit KI-Stack 2.15 wurde deshalb das Model Context Protocol als neue Standardschnittstelle eingeführt.
MCP definiert einen einheitlichen Mechanismus, über den KI-Anwendungen externe Werkzeuge und Kontextquellen verwenden können.
Statt also für jedes Werkzeug eine eigene Integration in das Frontend zu bauen, kann die Anwendung über einen generischen MCP-Client mit unterschiedlichen Servern kommunizieren.
Für den KI-Stack ist das architektonisch wesentlich sauberer.
Ein eigener MCP Runtime Service
Version 2.15 ergänzt dafür die Komponente:
mcp-runtime
Auch diese Komponente folgt dem isolierten Komponentenmodell des Complete Installers.
Die Runtime verwendet Open Terminal weiterhin als technische Basis, startet es aber im MCP-Modus.
Die Verbindung läuft über Streamable HTTP und bindet lokal an:
127.0.0.1:8021
Open WebUI registriert diese Verbindung als generischen MCP Tool Server.
Damit verschiebt sich die Architektur von:
Open WebUI → spezielle Open-Terminal-OpenAPI
zu:
Open WebUI → MCP → Open Terminal
Der Unterschied ist wesentlich.
Open WebUI muss nun nicht mehr wissen, dass hinter der Verbindung konkret Open Terminal steckt. Es sieht lediglich einen MCP-Server mit definierten Tools.
Zwölf Werkzeuge stehen über MCP bereit
Der MCP Runtime stellt aktuell zwölf Werkzeuge bereit.
Für die Prozesssteuerung stehen unter anderem zur Verfügung:
run_command
get_process_status
kill_process
send_process_input
list_processes
Für Dateioperationen und Suche stehen weitere Funktionen bereit:
read_file
write_file
replace_file_content
list_files
glob_search
grep_search
display_file
Damit kann ein entsprechend konfiguriertes Sprachmodell direkt mit Dateien und Prozessen arbeiten.
Ein wichtiger Punkt ist dabei run_command.
Über dieses Werkzeug lassen sich vorhandene Betriebssystemfunktionen weiterverwenden, statt für jede einzelne Windows-Funktion ein spezielles MCP-Tool zu entwickeln.
Diese Entscheidung wird mit Version 2.16 noch wichtiger.
Kein neuer Credential-Mechanismus
Auch der MCP Runtime verwendet das bereits etablierte lokale Credential-Modell.
Credentials werden nicht in das Repository geschrieben und nicht unverschlüsselt in Konfigurationsdateien abgelegt.
Der verwendete Schutz basiert erneut auf Windows DPAPI.
Damit entstehen durch die neue Tool-Schicht keine zusätzlichen Klartext-Secrets.
Produktionsprofile wechseln auf MCP
Mit Version 2.15 wurden die realen terminalfähigen Open-WebUI-Profile auf die MCP-Verbindung umgestellt.
Die Profile referenzieren nun den MCP-Server:
server:mcp:ki-stack-mcp-runtime
Der Research-Agent erhält diese Verbindung bewusst nicht.
Das ist eine wichtige Designentscheidung.
Nicht jedes Profil benötigt Systemzugriff.
Ein Agent, dessen Aufgabe in Recherche und Quellenverarbeitung besteht, sollte nicht automatisch lokale Terminalrechte erhalten, nur weil die technische Möglichkeit vorhanden ist.
Tool-Zugriff wird damit profilabhängig vergeben.
Der alte Zugriff bleibt als Fallback bestehen
Die Einführung von MCP bedeutet nicht, dass der bisherige Open-Terminal-Pfad aus dem System entfernt wurde.
Die alte Terminalfähigkeit bleibt absichtlich bestehen.
Damit existiert ein getesteter Rückweg.
Sollte die MCP-Verbindung fehlerhaft sein oder eine zukünftige Open-WebUI-Version Änderungen an der MCP-Unterstützung mitbringen, kann der vorherige Zugriff weiterhin verwendet werden.
Das ist ein wiederkehrendes Architekturprinzip im KI-Stack:
Neue Funktionalität wird eingeführt, ohne funktionierende Rückfallwege unnötig früh zu zerstören.
Ein verstecktes Reconcile-Problem
Die MCP-Migration brachte außerdem einen Fehler in der Profilverwaltung ans Licht.
Der Agent Pack erzeugt beim Reconcile eines Profils dessen Tool-Zuordnungen neu.
Die MCP-Verbindung wurde jedoch außerhalb dieser ursprünglichen Definition hinzugefügt.
Das bedeutete:
Ein MCP-fähiges Profil konnte zunächst korrekt funktionieren.
Ein späteres Repair oder Upgrade des Agent Packs hätte die Tool-Liste aber erneut erzeugt und dabei die MCP-Verbindung wieder entfernen können.
Der Fehler wäre besonders unangenehm gewesen, weil er nicht sofort bei der Einführung von MCP auftritt, sondern erst bei einem späteren Wartungslauf.
Die Reconcile-Logik wurde deshalb erweitert.
Profile mit definierter MCP-Bindung behalten diese Verbindung nun auch über Upgrade- und Repair-Läufe hinweg.
Credential Drift bei der alten Open-Terminal-Verbindung
Während der 2.15-Tests wurde außerdem ein bereits vorhandenes Problem der alten OpenAPI-Anbindung entdeckt.
Wenn das Open-Terminal-Credential außerhalb des normalen Installationspfades neu erzeugt wurde, konnte Open WebUI weiterhin den alten Schlüssel gespeichert haben.
Open Terminal selbst war dann gesund und erreichbar.
Tool-Aufrufe endeten trotzdem mit:
HTTP 401
Für diesen Fall wurde eine gezielte Reparaturfunktion ergänzt.
Die Aktion:
SyncRegistrationCredential
synchronisiert ausschließlich das Credential der bereits vorhandenen Registrierung.
Die Verbindung muss dadurch nicht vollständig gelöscht und neu eingerichtet werden.
Der Schlüssel wird dabei nicht in der Konsole oder im Log ausgegeben.
LM Studio und die Suche nach Latenz
Die Arbeiten an 2.15 fanden parallel zu einer Untersuchung der wahrgenommenen Antwortlatenz im KI-Stack statt.
Dabei wurde eine relevante LM-Studio-Einstellung identifiziert:
Max Concurrent Predictions
Eine zu niedrige Einstellung kann zu zusätzlicher Queue-Latenz führen.
Deshalb enthält der KI-Stack seit 2.15 einen Runtime-Baseline-Test.
Der Test prüft die Einstellung und bewertet sie, verändert sie aber nicht automatisch.
Für den getesteten Stack wurde ein Wert von 3 als empfohlene Baseline festgelegt.
Das Prinzip dahinter ist wichtig.
Der Installer soll nicht jede Einstellung eines externen Programms ungefragt überschreiben.
Er soll jedoch erkennen können, wenn eine relevante Laufzeitkonfiguration von der getesteten Basis abweicht.
Ein weiterer Fehler im Compliance-Modell
Bei einem realen Execute-Lauf wurde noch ein anderes Problem sichtbar.
Die Komponente cutover-runtime konnte erfolgreich ausgeführt werden, einen aktuellen lokalen Marker schreiben und mit Exitcode 0 abschließen.
Ein späterer Audit meldete sie trotzdem weiterhin als nicht compliant.
Der Grund lag in der Versionsprüfung.
Statt den aktuellen Zustand des Zielsystems zu verwenden, wurde an dieser Stelle bevorzugt ein historischer Acceptance-Snapshot ausgewertet.
Für cutover-runtime wurde diese Logik korrigiert.
Wenn ein aktueller lokaler Marker vorhanden ist, wird dieser nun zuerst verwendet. Nur wenn kein solcher Marker existiert, greift die bisherige historische Fallback-Logik.
Damit stimmt der gemeldete Compliance-Zustand wieder mit dem realen Zielsystem überein.
Warum 2.14 und 2.15 zusammengehören
Beide Releases lösen unterschiedliche Teile desselben Problems.
2.14 beantwortet die Frage:
Wie kann der KI-Stack sicher und kontrolliert lokale Befehle ausführen?
2.15 beantwortet anschließend:
Wie stellen wir diesen Zugriff dem KI-Frontend über eine standardisierte Schnittstelle bereit?
Open Terminal ist deshalb nicht durch MCP ersetzt worden.
MCP sitzt vielmehr eine Ebene darüber.
Die Architektur lässt sich vereinfacht so darstellen:
Open WebUI
|
| MCP
v
MCP Runtime
|
v
Open Terminal
|
v
Windows / PowerShell / Dateien / Prozesse
Damit sind Verantwortlichkeiten klar getrennt.
Open WebUI stellt die Benutzeroberfläche und den MCP-Client bereit.
Der MCP Runtime stellt die standardisierte Tool-Schnittstelle zur Verfügung.
Open Terminal übernimmt die eigentliche lokale Ausführung.
Windows und die darauf installierten Werkzeuge bleiben die eigentliche Ausführungsumgebung.
Warum nicht einfach alles direkt in Open WebUI integrieren?
Eine direkte Integration wäre zunächst vielleicht einfacher gewesen.
Langfristig hätte sie den KI-Stack aber enger an eine spezielle interne Open-WebUI-Struktur gebunden.
Mit MCP entsteht stattdessen eine klar definierte Schnittstelle.
Das bringt mehrere Vorteile.
Die Tool-Schicht lässt sich unabhängig vom konkreten Sprachmodell verwenden.
Profile können unterschiedliche Tool-Berechtigungen besitzen.
Weitere MCP-fähige Clients könnten perspektivisch dieselbe Runtime verwenden.
Und der darunterliegende Ausführungsmechanismus kann verändert werden, ohne dass sämtliche Agentenprofile neu entwickelt werden müssen.
MCP wird damit zu einer Abstraktionsschicht zwischen KI und Betriebssystem.
Was daraus als Nächstes entsteht
Mit Version 2.15 ist die technische Grundlage vorhanden.
Das Sprachmodell besitzt einen standardisierten Zugriff auf lokale Werkzeuge.
Die nächste Frage ist deshalb nicht mehr, wie ein einzelner Terminalbefehl ausgeführt werden kann.
Die interessantere Frage lautet:
Wie weit lässt sich dieser vorhandene Zugriff für echte lokale Systemsteuerung nutzen, ohne dafür immer neue Spezialwerkzeuge und Dienste einzuführen?
Genau damit beschäftigt sich KI-Stack 2.16.
Dort wird aus dem MCP-Werkzeugzugriff eine allgemeine Local-Control-Schicht für Windows, PowerShell, Prozesse, Dateien, WSL, Docker und die eigenen KI-Stack-Komponenten.