Work: isolierte Arbeitsbereiche

Work ist die native Programmieragenten-Oberfläche von Libre WebUI. Jede Aufgabe verbindet eine dauerhafte Unterhaltung, eine explizite Anbieterroute und ein eigenes Dateisystem unter /workspace. Das Modell kann Dateien prüfen und bearbeiten, Befehle in einem aufgabenbezogenen Docker-Container oder Kubernetes-Pod ausführen und eine Browservorschau starten.

Work ist direkt in Libre WebUI implementiert und benötigt weder Libre Claw noch einen anderen Agent-Daemon.

Nur für vertrauenswürdige Benutzer

Jede Work-API verlangt ein authentifiziertes Konto mit Work-Zugriff. Standardmäßig sind das Administratoren; sie können Work unter Einstellungen > Benutzerverwaltung für alle aktiven Benutzer öffnen (Hostordner bleiben wegen Serverpfad-Mounts administrativ). Work lässt Modelle bewusst beliebige Shellbefehle in einer Sandbox ausführen. Aufgaben besitzen Netzwerkausgang, sofern ihre benannte Richtlinie ihn nicht deaktiviert. Behandle jeden berechtigten Benutzer als vertrauenswürdigen Laufzeitbetreiber, nicht nur als Chatbenutzer.

Versionshöhepunkte

Diese Version bietet einen vollständigen Aufgabenablauf:

• Getrennte Work- und Chat-Aktionen mit sichtbarem Modus.
• Aufgaben in der normalen Seitenleiste mit stabilen Positionen und direktem Löschen.
• Eigene Sandboxidentität und dauerhaftes Docker-Volume oder Kubernetes-PVC je Aufgabe.
• Dauerhafte Unterhaltung, Status, Werkzeugaktivität, Modellauswahl und Eigentum.
• Authentifizierter Live-Stream für Text, Anbieter-Schlussfolgern, Werkzeuge, Ergebnisse, Nutzung, Fähigkeiten und Zustandsänderungen.
• Serverseitige Worker-Fähigkeiten für effizientes Prüfen, Bearbeiten, Verifizieren und Vorschauen ohne Steuerdateien im Projekt.
• Werkzeugfähige lokale Ollama-, Ollama Cloud- und Pluginmodelle.
• Responsive Teilung von Unterhaltung und Arbeitsbereich mit Maus-/Tastatursteuerung.
• Integrierte Dateien-, Aktivität-, Git-, Terminal-, Vorschau- und Bildschirmansichten.
• Syntaxhervorhebung, Browserformatierung, Konflikterkennung und temporäre Entwürfe.
• Benutzerspezifisch verwerfbarer Hinweis bei Remote-Anbietern.
• Vollständige Übersetzung in 25 Sprachen einschließlich nativem arabischem RTL, während Code, Pfade, IDs und Ausgaben LTR bleiben.

Die dauerhafte Einheit ist der Arbeitsbereich, nicht ein ständig laufender Container. Libre WebUI startet, stoppt und ersetzt Container bei erhaltenem Volume.

Architektur

Libre WebUI wählt Namen, Image, Mount, Benutzer, Limits, Netzwerk und Port. Das Modell erhält nur:

• list_files
• read_file
• write_file
• delete_file
• move_file
• search_files
• run_command
• start_preview
• stop_preview

delete_file und move_file sind pfadgeschützt: kein Verlassen, keine Symlinkdurchquerung, explizites rekursives Löschen, kein Überschreiben. Da sie den Dateihelfer statt Shell nutzen, funktionieren sie bei laufender Vorschau, wenn run_command gesperrt ist.

Modellanfragen kommen vom Backend, nicht aus dem Container, und hängen nicht von seiner Netzwerkrichtlinie ab.

Anforderungen

Work braucht ein Sandbox-Backend:

• Docker verlangt installierten, erreichbaren Daemon und Ausführungsrecht für docker oder WORK_DOCKER_COMMAND.
• Kubernetes verlangt API-Anmeldedaten sowie Role, RoleBinding, Namensraum und NetworkPolicies, die Helm bei work.enabled=true erstellt.

Außerdem erforderlich:

• Werkzeugfähiges Modell über gesundes Ollama (einschließlich Cloud) oder aktives Chat-/Vervollständigungs-Plugin mit exaktem Modell und Anmeldedaten.
• Genügend Speicher für Image, Projekte und Abhängigkeiten.
• Authentifiziertes Konto mit Work-Zugriff; standardmäßig Administratoren.

Libre WebUI prüft Ollamas Fähigkeiten und lehnt Modelle ohne tools ab. Pluginmodelle müssen ihr Werkzeugprotokoll unterstützen. Bei Ablehnung scheitert die Ausführung ohne stillen Wechsel.

Lokal starten

Einfachste Konfiguration auf demselben Rechner:

docker info
npx libre-webui@latest

Öffne http://localhost:8080, melde dich als Administrator an, wähle Work, ein kompatibles Modell und beschreibe das Projekt.

Bei fehlendem oder unerreichbarem Docker zeigt Work Laufzeit nicht verfügbar mit Grund und deaktiviert den Editor. Befehle werden nie direkt auf dem Host ausgeführt.

Das Laufzeitimage wird beim ersten Einsatz geprüft und bei Bedarf geladen, weshalb die erste Operation länger dauern kann.

Work-Oberfläche verwenden

Aufgaben erstellen und erneut öffnen

Wähle Work neben Chat, gib eine Anweisung ein, wähle ein Modell und Ausführen. Die erste Nachricht erstellt Aufgabe, Ausführung, Anbieterroute und dauerhaften Bereich.

Aufgaben bleiben in der Hauptseitenleiste. Beim Öffnen werden Unterhaltung, Dateien, Anbieter/Modell und Bereich wiederhergestellt; ältere Nachrichten lassen sich seitenweise laden. Umbenennen und dauerhaftes Löschen sind möglich.

Pro Aufgabe kann eine Ausführung aktiv sein. Weitere Anweisungen verwenden dieselbe Unterhaltung und dasselbe Dateisystem.

Der Editor unterstützt Diktat: Eine Mikrofonschaltfläche nutzt nach Möglichkeit die Sprach-API des Browsers oder ersatzweise ein konfiguriertes Sprache-zu-Text-Modell und hängt das Transkript an vorhandenen Text an. Von einer Ausführung erstellte oder verschobene Dateien erscheinen unter der verursachenden Werkzeugaktivität als anklickbare Chips. Ein Klick öffnet die Datei im Datei-Editor (auf schmalen Bildschirmen mit Wechsel zum Arbeitsbereich). Chips stammen nur von verändernden Werkzeugen: Liest eine Ausführung zwanzig Dateien und schreibt eine, zeigt sie genau dieses eine Artefakt.

Einen Agenten einstellen

Wenn Personas vorhanden sind, bietet die Startansicht Als Agent einstellen. Wähle eine Persona, und die Aufgabe wird zu einem dauerhaft benannten Agenten statt einer einmaligen Aufgabe. Name und System-Prompt der Persona werden dem Work-System- Prompt vorangestellt; der Sandbox-Laufzeitvertrag hat immer Vorrang. Die Seitenleiste heftet Agenten in einer eigenen Gruppe Agenten über Ad-hoc-Aufgaben an, jeweils mit Avatar, Aktivitätsanzeige und einzeiligem Status. Ist die Seitenleiste kompakt, bleiben nur diese angehefteten Agenten-Avatare in der Leiste; einmalige Work-Aufgaben kehren beim Ausklappen zurück.

Der Status hat zwei Stufen. Für eingestellte Agenten bittet eine günstige werkzeuglose Modellanfrage am Ausführungsende um etwa 8 Wörter ("Inbox at zero. 2 replies ready."). Die Antwort ist auf eine Zeile mit 90 Zeichen begrenzt; Fehler oder Zeitüberschreitung fallen auf die deterministische Stufe zurück – die erste Zeile der letzten Assistentennachricht. Ad-hoc-Aufgaben und fehlgeschlagene Ausführungen nutzen nur diese Stufe; WORK_STATUS_BLURB_MODEL=0 deaktiviert die Modellanfrage. Agenten haben außerdem eine Ungelesenanzeige: Öffnen bewegt eine monotone, geräteübergreifend synchronisierte Gesehen-Markierung. Die Seitenleiste zeigt einen Punkt, wenn eine Ausführung danach einen Endzustand erreicht.

Agenten berichten auch über Benachrichtigungen, in der Anwendung und optional per Web Push: work-run-finished bei Abschluss, work-run-attention bei Eingabebedarf oder Fehler und work-takeover, sobald der Agent um Bildschirmübernahme bittet. Die Bildschirmleiste ist nur bei geöffnetem Tab sichtbar; Push erreicht dich andernorts. Jede Benachrichtigung verlinkt direkt.

Du kannst eine eigene oder freigegebene Persona einstellen; die freigegebene Ansicht offenbart nie Erinnerungen des Eigentümers. Wird die Persona später gelöscht, läuft der Agent ohne sie weiter und protokolliert eine Warnung. Die API akzeptiert personaId und isAgent; eine Aufgabe mit Persona ist automatisch Agent.

Der Agent-Tab

Der Arbeitsbereich eines Agenten öffnet einen zusätzlichen ersten Tab Agent:

• Identität: Avatar, Name, Aktivitätsanzeige und neuester Status.
• Bildschirm: Bei Work Computer eine kompakte schreibgeschützte Live-Miniatur. Sie zählt zum Viewer-Budget; Anklicken öffnet Bildschirm mit Übernahme, Anlernen und Audio.
• Routinen: An diese Aufgabe gebundene Automatisierungen. Jede Auslösung läuft in Arbeitsbereich und Unterhaltung des Agenten mit dessen Modell und Richtlinie, nicht als neue Aufgabe. Zeilen zeigen den Zeitplan in Worten und Pause/Fortsetzen; + Routine ist bereits gebunden. Bei beschäftigtem Agenten scheitert die Auslösung ehrlich als work-task-busy, statt zu warten.
• Automatische Prüfung: Der Freigabeschalter des Agenten und die gesammelten Regeln „Immer erlauben“; das Entfernen einer Regel schließt ihren Geltungsbereich wieder. Erzwingt die Richtlinie der Aufgabe die Prüfung, bleibt der Schalter fest an.
• Angelernte Fähigkeiten: Im Anlernmodus demonstrierte Verfahren mit Schalter.

Verbundene Werkzeuge (MCP- und OpenAPI-Server)

Work-Agenten können dieselben Werkzeugserver aufrufen, die für den Chat eingerichtet sind: MCP oder OpenAPI, von Administratoren unter Einstellungen → Werkzeuge registriert. Die Werkzeuge erscheinen dem Agenten unter ihrem Namensraumnamen (server__tool), und die Aufrufe laufen vom Backend von Libre WebUI über das gehärtete Werkzeug-Gateway (SSRF-geschützter Ausgang, Zugangsdaten pro Benutzer, Größen- und Zeitgrenzen), nie aus der Sandbox heraus.

Das Angebot bleibt ehrlich, was ein autonomer Lauf wirklich nutzen kann:

• Eine Aufgabe ohne Netz bietet keine an: ob der Ausgang über das Backend läuft oder nicht, eine Aufgabe ohne Netzzugang bleibt offline, aus demselben Grund wie bei web_search.
• Ein Server, der persönliche Zugangsdaten verlangt, die der Benutzer nicht hinterlegt hat, wird beim Angebot herausgefiltert, denn ein autonomer Lauf kann nicht innehalten und danach fragen. Trage die Zugangsdaten unter Einstellungen → Werkzeuge ein, dann bietet der nächste Lauf den Server an.
• Der Zugriffsmodus für Werkzeuge (nur Administratoren oder alle Benutzer) und die Sichtbarkeit je Server gelten genau wie im Chat, und die Werkzeugserver einer Persona schränken ein, welche Server der damit eingestellte Agent sieht.
• Sind Freigaben aktiv, warten verbundene Werkzeuge, die der Server als wirksam einstuft, wie jede kontrollierte Aktion auf deine Entscheidung; schreibgeschützte Werkzeuge laufen ohne Nachfrage.

Delegation zwischen Agenten (@-Erwähnungen)

Eingestellte Agenten können Arbeit weitergeben. Tippe @ im Work-Eingabefeld, um einen deiner anderen Agenten zu erwähnen: Der aktuelle Agent sieht in seinen Anweisungen die Liste seiner Kollegen mit Namen und Statuszeilen und delegiert passende Anfragen mit dem Werkzeug message_agent. Delegation koordiniert über Nachrichten und bewusst nicht über gemeinsame Computer: Jeder Agent behält Arbeitsbereich und Sandbox für sich, und das Ziel sieht die delegierende Unterhaltung nicht — die Anfrage muss ihren Kontext selbst mitbringen.

Delegation ist asynchron. Das Werkzeug kehrt sofort zurück, der Zielagent läuft in seiner eigenen Aufgabe (seine Unterhaltung zeigt die Anfrage als Delegiert von dem Absender), und wenn er fertig ist — abgeschlossen, Eingabe nötig, fehlgeschlagen oder abgebrochen —, wird seine letzte Antwort als Nachricht Bericht von diesem Agenten in die Unterhaltung des delegierenden Agenten geliefert. Läuft der Delegierende noch, erreicht der Bericht sein Modell in der nächsten Runde; ist er untätig, wartet der Bericht einfach in der Unterhaltung, denn ein Bericht startet nie von selbst einen Lauf, sodass zwei Agenten einander nicht endlos hin- und herschicken können. Ein delegierter Lauf kann nicht weiter delegieren, ein beschäftigtes Ziel lässt den Versuch ehrlich scheitern, statt ihn einzureihen, und bei aktiven Freigaben hält message_agent wie jede andere wirksame Aktion zur Prüfung an (eine Regel „Immer erlauben“ gilt dann nur für diesen einen Zielagenten).

Aktionsfreigaben (Automatische Prüfung)

Wirksame Aktionen können vor der Ausführung auf deine Entscheidung warten. Sind Freigaben für eine Aufgabe aktiv — weil ihre Work-Richtlinie Freigabe für wirksame Aktionen verlangen setzt oder der Schalter Automatische Prüfung des Agenten an ist —, hält der Lauf vor run_command, computer_act, delete_file, move_file oder message_agent an und zeigt eine Entscheidungskarte in der Unterhaltung: Einmal erlauben, Immer erlauben oder Verweigern.

• Einmal erlauben führt genau diesen Aufruf aus und fragt beim nächsten Mal wieder.
• Immer erlauben führt den Aufruf aus und speichert eine Regel an der Aufgabe: für das ganze Werkzeug bei Datei- und Computeraktionen, bei run_command begrenzt auf das Programm des Befehls (sein erstes Wort) — npm run build freizugeben genehmigt künftige npm-Befehle vorab, nicht die ganze Shell — und bei message_agent begrenzt auf den einen Zielagenten. Die Regeln stehen im Abschnitt Automatische Prüfung des Agent-Tabs und lassen sich dort entfernen.
• Verweigern lehnt den Aufruf ab. Dem Modell wird mitgeteilt, dass der Benutzer die Aktion verweigert hat und sie nicht unverändert wiederholen darf; der Lauf geht mit dieser Antwort weiter.

Eine ausstehende Freigabe löst auch eine Benachrichtigung aus (in der App und bei aktivem Web Push auch dort), denn der Lauf arbeitet womöglich schon Minuten unbeaufsichtigt, wenn er an diese Kontrolle stößt. Entscheidet niemand innerhalb von fünf Minuten, läuft die Anfrage ab, die Aktion wird nicht ausgeführt, und der Lauf endet mit Eingabe nötig und einer normalen Übergabe, statt sein Budget auszuschöpfen.

Freigaben kontrollieren Aktionen, nicht Sichtbarkeit: write_file und die schreibgeschützten Werkzeuge bleiben ungeprüft, und jede Entscheidung landet im Sicherheits-Auditprotokoll.

Aufgabenstatus verstehen

Oberfläche	Backendzustand	Farbe
Inaktiv	idle	rgb(255, 255, 255)
Denkt	preparing oder running	rgb(48, 121, 255)
Abgeschlossen	completed	rgb(76, 212, 117)
Eingabe nötig	needs_input oder cancelled	rgb(255, 204, 0)
Fehler	failed	rgb(255, 61, 129)

Stoppen setzt Eingabe nötig und bewahrt Dateien. Auch erschöpfte Runden oder Werkzeuge enden nach einer letzten werkzeuglosen Übergabe so, nie als abgeschlossen.

Nachrichten während einer Ausführung gelangen sofort in die Unterhaltung und in der nächsten Runde zum Modell; Stoppen bleibt verfügbar.

Arbeitsbereich skalieren

Am xl-Punkt teilen sich Unterhaltung und Bereich einen verschiebbaren Trenner:

• Standardbreite 45%.
• Bevorzugt 30%–70% unter Mindestbreiten.
• Verhältnis pro Benutzer und Browser gespeichert.
• Pfeile bewegen 2%, mit Umschalt 10%.
• Pos1/Ende setzen Grenzen.
• Eingabe oder Doppelklick setzt zurück.

Steuerung folgt der Schreibrichtung; Arabisch platziert Unterhaltung rechts und Bereich links. Kleinere Bildschirme nutzen den Oberflächenschalter.

Dateien

Der Tab durchsucht direkte Kinder von /workspace, öffnet nur strikt gültiges UTF-8 und speichert ins Volume. Ungültige Bytes werden abgelehnt.

Der Editor bietet:

• Syntaxhervorhebung hell/dunkel für verbreitete Sprachen;
• Cmd/Ctrl+S zum Speichern;
• Shift+Alt+F zum Formatieren;
• optimistische Konflikterkennung;
• aufgaben-/pfadbezogene Sitzungsentwürfe; und
• Navigationswarnungen bei ungespeicherten Änderungen.

Hervorhebung pausiert über 8,000 Zeichen oder 400 Zeilen. Formatierung unterstützt 100,000 Zeichen und 4,000 Zeilen für JavaScript/JSX, TypeScript/TSX, JSON, CSS/SCSS/Less, HTML, Markdown/MDX und YAML.

Ändert das Modell eine offene Datei, zeigt Dateien einen rot/grünen Diff seit Rundenbeginn mit eingeklappten unveränderten Teilen. Umschalter und +added −removed fassen zusammen. Basis ist der letzte vor der Runde gesehene Inhalt.

Browserentwürfe sind Komfort, keine Sicherung. Sie verschwinden nach Speichern, Löschen oder Sitzungsende.

Aktivität

Aktivität zeigt Werkzeugaufrufe, Ergebnisse, Dateioperationen, Ausgabe und Fehler. Ausgaben bleiben auch in RTL links nach rechts.

Während der Ausführung streamt ein authentifizierter SSE-Kanal:

• snapshot und run_state;
• reasoning_delta bei offengelegtem Schlussfolgern;
• assistant_delta;
• tool_call und tool_result;
• usage;
• skill_loaded; und
• error oder done.

Schlussfolgerung hängt von Modell und Anbieter ab. Libre zeigt nur API-Inhalt, keine verdeckte Gedankenkette. Text und Werkzeuge streamen unabhängig. Ausgabe ist bewusst begrenzt; ein abgeschnittener Wert beweist nicht, dass es nichts Weiteres gibt.

Git

Lokale Operationen für /workspace:

• Repository mit main initialisieren;
• porcelain-Status, voraus/zurück und 20 Commits prüfen;
• begrenzten Diff prüfen;
• bis 200 explizite Pfade stagen;
• mit Name/E-Mail des Administrators oder lokaler No-Reply-Adresse committen;
• nach erstem Commit Zweig erstellen; und
• bei sauberem Worktree zu lokalem Zweig wechseln.

Die Oberfläche ist nur lokal: kein clone, fetch, pull, push, Remoteverwaltung, beliebiger Git-Befehl, Token, SSH-Schlüssel oder Pull Request. Nutze einen getrennten vertrauenswürdigen Broker; speichere keine dauerhaften Git-Daten im Bereich.

Lesen ist inaktiv oder aktiv möglich. Schreiben wird bei Modell, Terminal oder Vorschau abgelehnt; Zweigwechsel verlangt sauberen Worktree.

Jeder UI-Befehl ist ein festes Argumentarray als UID/GID 1000:1000; Eingaben gehen nie durch Shell. System-/Globalkonfiguration, Prompts, Hooks, Credential Helper, Signatur, Submodule, externe Diffs, textconv und Netzprotokolle sind deaktiviert. Repositories außerhalb /workspace oder mit ausführbaren Filtern werden abgelehnt.

Diese Kontrollen schützen die API. Terminal und run_command können weiterhin gewöhnliches Git nutzen; Sandbox und Bereitstellung bleiben die Grenze.

Integrierte Worker-Fähigkeiten

Jede Ausführung erhält eine serverseitige Anleitung zu /workspace, schreibgeschützter Wurzel, temporären Prozessen und /tmp, Netzwerk, Limits und Vorschau. Sie weist an:

• Projektanweisungen, Manifeste, Sperrdateien, Skripte und Zustand zuerst zu prüfen;
• unabhängige Lesevorgänge zu bündeln und fremde Arbeit zu bewahren;
• bis zur Implementierung fortzufahren;
• fokussiert vor breit zu prüfen;
• Fehler zu diagnostizieren statt blind zu wiederholen; und
• vor der Vorschau zu verifizieren.

Sie existiert nur im Modellkontext; Libre WebUI erstellt kein AGENTS.md oder Steuerverzeichnis. Projektanweisungen überschreiben Sicherheitsgrenzen nicht.

Terminal

Terminal verbindet eine interaktive Shell mit demselben Container. Sie läuft als 1000:1000 in /workspace unter derselben Härtung und gewährt keine zusätzlichen Rechte gegenüber run_command.

• Authentifizierung: Authorization wird gegen ein kurzlebiges Einmalticket für Aufgabe und /ws/work-terminal getauscht; vor jeder Eingabe werden Konto, Zugriff und Eigentum erneut geprüft.
• Ursprung: Bei CORS_ORIGIN oder BASE_URL muss der Browser passen. Ursprunglose Clients bleiben mit Ticket und Live-Prüfung möglich.
• Zulassung: Terminal nimmt eine Lease und zählt zu WORK_MAX_ACTIVE_RUNTIMES_*.
• Containerleben: Verbindung hält den Container aktiv.
• Parallelität: WORK_TERMINAL_MAX_SESSIONS_PER_TASK ist standardmäßig 2.
• Leerlauf: WORK_TERMINAL_IDLE_TIMEOUT_MS ist standardmäßig 15 Minuten.
• Aktive Ausführung: Shell öffnet nach Rundenende.

Terminal spricht direkt mit Docker Engine: WORK_DOCKER_SOCKET, sonst DOCKER_HOST als unix:// oder unverschlüsseltes tcp:// (auch Proxy über Connection: Upgrade), sonst /var/run/docker.sock. Nicht unterstütztes ssh:// oder tcp:// mit DOCKER_TLS_VERIFY meldet den Grund. Kubernetes nutzt das exec-Unterressourcen-TTY-WebSocket ohne Docker.

Sitzungen werden nicht aufgezeichnet; Befehle erscheinen nicht in Aktivität.

Vorschau

Der Tab startet, stoppt, bettet ein und öffnet die Anwendung. Bei leerem Befehl:

• Root-package.json-dev mit Host und Port;
• Root-index.html mit integriertem statischem Server; oder
• dieselben Regeln für eine einzelne verschachtelte App.

Root hat Vorrang. Mehrere Kandidaten oder fehlender Einstieg ergeben einen hilfreichen Fehler. Benutzerdefinierte Befehle beginnen in /workspace, etwa cd apps/web && npm run dev -- --host 0.0.0.0 --port 4173. Der Prozess muss auf 0.0.0.0 und WORK_PREVIEW_PORT lauschen; Work wartet 15 Sekunden.

Das Modell kann start_preview nutzen. Nur so darf es einen Prozess laufen lassen; run_command räumt Hintergrundprozesse auf.

Bildschirm (Work Computer)

Vollständige Demonstration ansehen: eine echte, unbearbeitete Ausführung (30x, dann Echtzeit), in der ein Work-Agent NASA-Bilder durchsucht, auswählt und eine interaktive Three.js-Galerie erstellt und testet – alles aus einem Prompt.

Eine Richtlinie mit Work Computer ergänzt einen Live-Bildschirm auf einen virtuellen Desktop derselben Sandbox – Fenstermanager, Dock und Chromium auf 1280×800. Du kannst beobachten, Maus/Tastatur übernehmen, Audio hören und durch Demonstration anlernen. Der Tab startet GUI bedarfsgesteuert und verbindet einen VNC-over-WebSocket-Viewer.

Administratoren aktivieren über die Work Computer-Karte. Sie baut das integrierte GUI-Image auf dem eigenen Docker-Daemon (erstmals einige Minuten) und erstellt eine Richtlinie, ohne manuellen docker build oder auszufüllende Richtlinienfelder. Hinter gefiltertem Proxy ist Build verweigert; lade ghcr.io/libre-webui/libre-work-computer als libre-work-computer:latest auf dem Host oder baue aus deploy/work-computer/. Aufgaben brauchen Netzwerk, da der Bildschirm wie die Vorschau über einen Loopback-Port erreicht wird.

Sicherheit: VNC bindet localhost hinter je einem Lese- und Kontrollpasswort. Jeder autorisierte Viewer erhält nur Lesen, ausschließlich der Lease-Inhaber Kontrolle. Nur die WebSocket-Brücke ist auf Host-Loopback erreichbar. Einmaltickets sind an Sitzung und Aufgabe gebunden; Work-Zugriff wird bei jeder Verbindung geprüft. Bis zu vier Viewer zählen als Aufgabenaktivität. Beobachten blockiert Ausführungen nicht; es verbindet zur laufenden Sandbox und überlebt das Rundenende, auch bei externen Team-Workern. Browseranmeldungen bleiben in /workspace/.browser-profile.

Der Agent erhält computer_observe für Vollbildaufnahme, Cursor, aktives Fenster, URL, Seitenfokus, fokussiertes Element und Hash sowie computer_act für bis zu 24 Maus-/Tastaturaktionen. type/key können focus verlangen und scheitern sicher; ein Batch stoppt bei neuem Fenster, Titel- oder Fokuswechsel; erwartete Ergebnisse (Titel, URL, Region) werden adaptiv geprüft – „pending“ ist kein Erfolg. Stabilisierung erfolgt durch Abfragen. Klickbelege melden Pixeländerungen, scroll_until sucht Text oder Seitenrand, Beobachtungen nennen unveränderte Bildschirme. Ein subgoal bleibt als Kontrollpunkt. Drei identische Aktionen ohne Änderung erzeugen eine Wiederherstellungsanweisung, erneute Wiederholung fordert Eingabe; unverifizierte Erwartungen führen zur Neuausrichtung. Runden, Latenz, Aufnahmen, Schutz und Urteile werden gespeichert und zusammengefasst.

Aufnahmen erreichen Modelle auf allen Routen als echte Bilder – Ollama, Anthropic, Gemini sowie OpenAI-kompatible Chat-/Responses-Plugins. Verwende daher ein Vision-Modell. Lehnt der Anbieter Bilder ab (Nur-Text-Modell), scheitert die Ausführung nicht: Aufnahmen werden für den Rest verworfen, das Modell muss Text verwenden und das Transkript erklärt die Einschränkung. Ein blindes Modell prüft deutlich weniger; bevorzuge Vision. Nur jüngste Aufnahmen bleiben im Live-Kontext, dauerhafte Transkripte speichern nur Text. Der Browser enthält Inhaltsblockierung: uBlock Origin Lite für Werbung/Tracker (beim Imagebau versioniert und per Prüfsumme geprüft, Filtermodus per verwalteter Richtlinie) sowie automatisches Schließen von Cookie-Einwilligungen. Bekannte Werbeskripte werden uBlock-artig durch harmlose lokale Stubs ersetzt. Der Agent darf keine Anmeldedaten eingeben oder CAPTCHA/2FA lösen, sondern meldet Hindernisse. Kombiniere bei nicht vertrauenswürdigen Aufgaben die GUI-Richtlinie mit gefiltertem DNS.

Audio ist standardmäßig stumm; die Lautsprecherschaltfläche streamt es. PulseAudio spielt in eine Nullsenke, deren PCM-Monitor über eine zweite authentifizierte Loopback-WebSocket-Brücke mit demselben Ticket und Viewerlimit dient. Erfordert ein aktuelles Image aus deploy/work-computer/.

Übernehmen gibt Maus und Tastatur für Anmeldung, CAPTCHA oder verbotene Schritte; Fertig gibt zurück. Das Kontrollpasswort erhält nur der Lease-Inhaber. Die Lease läuft bei Verlassen nach zwei Minuten ab, wird bei offener Oberfläche erneuert und kann nicht entrissen werden. Richtlinien können Übernahme vollständig deaktivieren; Beobachten bleibt. Während menschlicher Kontrolle sind computer_observe und computer_act gesperrt. request_takeover zeigt Grund und wartet auf Rückgabe. Eingegebene Anmeldedaten gelangen nie zum Modell oder Transkript. Ältere Images bleiben nur lesbar.

Aufgabe anlernen zeichnet eine Demonstration mit sichtbarer Aufnahme auf. Zeiger-, Tastatur- und Scrollaktionen werden mit Koordinaten gespeichert; Klicks werden über Element-Tag, ID, sichtbares Label und URL verankert, sodass Schritte "Click "button#submit (Place order)"" nennen und Koordinaten nur Hinweise sind. Das Verfahren wird deterministisch ohne Modell erstellt: Tasten werden zu Text, 8 Pixel unterscheiden Klick/Ziehen, Pausen werden Warteaktionen, geheimnisähnlicher Text (8+ Zeichen aus drei Klassen) wird entfernt und durch request_takeover ersetzt. Es enthält Einsatz, Eingaben, Schritte, Prüfung, aus besuchten Hosts abgeleiteten erlaubten Umfang, Genehmigungsgrenzen und Stoppen/Fragen bei Fehler. Als Fähigkeit mit Präfix taught- besitzt es Versionen, Bearbeitung und Freigabe. Aktivierte Fähigkeiten werden in Computer-Ausführungen geladen. Nach Abschluss ergänzt ein Erfolg/Fehler-Klick einen datierten, begrenzten Erfahrungsverlauf als neue Version. Tippe bei der Aufnahme keine echten Passwörter.

Anbieter, Routing und Datenoffenlegung

Unterstützte Routen

Route	Validierung und Verhalten
Lokales Ollama	Gesund und exaktes Modell kündigt Werkzeugunterstützung an
Ollama Cloud	Explizit über Ollama; Cloudsuffixe zeigen Remote-Hinweis
Vervollständigungs-/Chat-Plugin	Aktiv, exaktes Modell und Anmeldedaten des aktuellen Administrators
Anthropic-Plugin	Work-Adapter für Messages und Tool Use
Gemini-Plugin	Work-Adapter für Contents und Function Calling
Andere kompatible Plugins	OpenAI-artige Nachrichten, Werkzeuge und Auswahl

Anbietertyp und Plugin-ID werden auf Aufgabe und Ausführung gespeichert. Ein Name wählt nie allein die Route; ein gleichnamiges Plugin fängt Ollama nicht ab.

Anbieterdaten

Je Runde kann der Anbieter erhalten:

• Work-System-Prompt;
• integrierte Fähigkeiten und Limits;
• letzte 30 Benutzer-/Assistentennachrichten bis 256 KB;
• Werkzeugdefinitionen;
• Aufrufverlauf; und
• Ergebnisse einschließlich Listen, Dateiinhalten, Suche, Ausgabe und Fehlern.

Das Volume wird nicht vollständig hochgeladen. Zurückgegebene Inhalte werden jedoch Teil der Modellunterhaltung. Prüfe Aufbewahrung, Training, Preise und Nutzung.

Anmeldedaten bleiben im Backend und werden nie in den Container gemountet. Anwendungsverschlüsselung ist keine Gesamtverschlüsselung: Unterhaltung und Metadaten sind Datenbankinhalt, Dateien gewöhnlicher Volume-/PVC-Inhalt. Nutze Hostzugriff und Datenträgerverschlüsselung nach Bedrohungsmodell.

Remote-Hinweis

Plugins und Ollama-Namen mit :cloud oder -cloud gelten als remote. Ein Hinweis erklärt Datenfluss und mehrere kostenpflichtige Aufrufe und wird je Benutzer verworfen.

Alle Routen nutzen WORK_MAX_AGENT_ROUNDS, standardmäßig 48. Es gibt keine 12-Runden-Pluginbegrenzung. Das Werkzeugbudget ist das größere aus 128 oder acht je Runde. Bei Erschöpfung verlangt Libre eine letzte werkzeuglose Zusammenfassung und setzt Eingabe nötig. Eine Folgeausführung setzt im selben Bereich fort.

Hostordner-Arbeitsbereiche (optional)

Docker verwendet normalerweise ein exklusives Volume. Optional kann eine Aufgabe an einen echten Hostordner gebunden werden; Kubernetes lehnt dies ab und nutzt PVC.

Setze und starte neu:

WORK_HOST_WORKSPACES_ENABLED=true
WORK_HOST_WORKSPACE_ROOTS=/Users/you/Projects

WORK_HOST_WORKSPACE_ROOTS ist eine :-getrennte Wurzelliste, standardmäßig das Home des Serverbenutzers. Bei Aktivierung erscheint Arbeitsordner; leer bedeutet normales isoliertes Volume.

Der Pfad muss absolut, vorhanden, Verzeichnis und nach Symlinkauflösung innerhalb einer Wurzel sein. .ssh, .gnupg, .aws, .config, .kube, .docker, .claude, .libre-webui und node_modules werden abgelehnt. Der aufgelöste Pfad wird gespeichert und angezeigt.

Dies schwächt die Sandbox

Das Modell liest und schreibt echte Dateien; Containerkontrollen trennen es nicht mehr von diesem Verzeichnis. Lasse die Funktion ohne Bedarf aus, nutze enge Wurzeln und versionierte Verzeichnisse.

Persistenz und Laufzeitzyklus

Libre WebUI trennt dauerhaften Zustand und Ausführung:

Zustand	Speicher	Lebensdauer
Eigentum, Titel, Anbieter, Status	Libre WebUI-Datenbank	Bis Aufgabe oder Eigentümer gelöscht wird
Ausführungen, Fehler, Nachrichten, Aktivität	Libre WebUI-Datenbank	Bis Aufgabenlöschung
Arbeitsdateien	Docker-Volume oder K8s-PVC	Überleben Abbruch, Vorschau-/Sandbox-/Anwendungsneustart
Root und temporäre Dateien	Aufgabencontainer oder -Pod	Wegwerfbar
Vorschauprozess	Laufende Sandbox	Flüchtig, nur solange gesund
Ungespeicherter Entwurf	Browsersitzung	Temporärer Komfort

Jede Aufgabe erhält eine Server-UUID. Ressourcennamen werden im Backend abgeleitet, nie vom Browser angenommen. Labels zeigen Verwaltung und Eigentum; vor Nutzung oder Löschen werden sie geprüft.

Sandboxes entstehen nach Bedarf. Dateihelfer stoppen ansonsten inaktive Container, Befehle stoppen danach, eine gesunde Vorschau kann ihn halten. Das dauerhafte Volume wird erneut gemountet.

Administratoren definieren benannte Laufzeitrichtlinien mit Image, Speicher-/CPU-/PID-Limits, Kubernetes-Größe, Leerlauf, Netzwerkstandard sowie Work Computer (GUI + Browser) und Bildschirmübernahme zulassen. Leere Felder erben globale Werte; Löschen stellt sie bei Neuerstellung wieder her. Die Härtung selbst ist nicht abschwächbar.

WORK_RUNTIME_IDLE_TIMEOUT_MS stoppt bei gesetztem Wert Sandboxes nach fehlender Aktivität und gibt Zulassung frei; der Bereich bleibt. 0 hält Vorschauen bis zum expliziten Stoppen.

Beim Backend-Start werden aktive Ausführungen fehlgeschlagen und Vorschauen gelöscht. Der Treiber listet verwaltete Ressourcen einmal, stoppt laufende bekannte, belässt ruhende und entfernt Waisen. Eigentum stammt aus Labels. Zwei Instanzen dürfen nicht dieselben Ressourcen besitzen. Ist Reinigung nicht beweisbar, bleibt Work geschlossen, versucht alle 10 Sekunden erneut und blockiert Änderungen.

Netzwerkverhalten

Ausgewählte Netzwerkrichtlinie prüfen

Aufgaben ohne benannte Richtlinie starten mit Netzwerk. Eine Richtlinie kann es standardmäßig ausschalten. Es gibt keinen unabhängigen Aufgabenschalter; Änderungen erfordern Sandbox-Neuerstellung.

Docker verbindet Netzwerkaufgaben mit dem verwalteten Bridge-Netz (libre-webui-work, WORK_NETWORK_NAME) mit deaktivierter Containerkommunikation (com.docker.network.bridge.enable_icc=false). Daher erreichen Sandboxes weder einander noch Container im Standard-Bridge-Netz, sofern sie nicht veröffentlicht sind.

Existiert ein gleichnamiges nicht verwaltetes Netz, verweigert Libre WebUI den Start.

Kubernetes-Pods tragen dasselbe Label. Helm installiert Default-Deny, nur Vorschau- Eingang und Internetausgang für aktivierte Pods unter Ausschluss von work.networkPolicy.blockedEgressCidrs. Das CNI muss NetworkPolicy erzwingen; siehe Kubernetes.

Ausgang bleibt für Pakete, Git und APIs erlaubt. Dies ist keine Ausgangsfirewall. Code kann Hostdienste, LAN, Internet und Infrastrukturmetadaten erreichen.

Ausgangsrichtlinien

Kombiniere:

• WORK_RUNTIME_DNS (Docker): Kommagetrennte IPv4/IPv6-Resolver über --dns. Ungültige Einträge werden abgelehnt und können keine Optionen injizieren.
• Host-/Upstream-Firewall auf der stabilen verwalteten Subnetzadresse.
• WORK_NETWORK_NAME auf ein vorab erstelltes Netz mit Verwaltungslabel und deaktiviertem ICC.

DNS blockiert keine direkten IPs; dafür sind Firewalls nötig. Work verhindert keine Datenübertragung. Nutze Offline-Richtlinien und nur vertrauenswürdige Benutzer.

Netzwerk fügt keine Anmeldedaten hinzu: keine SSH-/Cloud-Schlüssel, Browserprofile, Host-Home oder Docker-Socket im Container. In /workspace geschriebene Geheimnisse können dennoch übertragen werden. Modellverkehr kommt separat vom Backend.

Sandbox-Sicherheitsgrenze

Ein Docker-Work-Container:

• läuft als UID/GID 1000:1000 ohne root;
• arbeitet in /workspace;
• mountet nur das Aufgabenvolume;
• nutzt schreibgeschützte Wurzel und begrenztes /tmp;
• entfernt alle Linux-Fähigkeiten;
• setzt no-new-privileges;
• ist nicht privilegiert und nutzt init;
• begrenzt CPU, Speicher, Prozesse, Zeit und Ausgabe;
• setzt --memory-swap gleich --memory;
• nutzt das isolierte Netz oder keines; und
• veröffentlicht nur den Vorschauport auf Host-Loopback.

Alles wird vor Wiederverwendung über docker inspect geprüft und in ai.libre-webui.policy gehasht. Veraltete Richtlinien führen zur Neuerstellung.

Kubernetes nutzt äquivalent UID/GID ohne root, schreibgeschützte Wurzel, RuntimeDefault-seccomp, keine Eskalation, keine Fähigkeiten, begrenzte Ressourcen, kein ServiceAccount-Token und Aufgaben-PVC. Labels und Fingerabdruck werden geprüft.

Pfadvalidierung lehnt absolute Pfade, Traversal, Backslashes, NUL und Überlänge ab; Symlinkfluchten werden verhindert, Schreiben erfolgt atomar.

Diese Kontrollen sind keine VM oder Malwareumgebung. Container teilen den Kernel; Schwachstellen können die Grenze überschreiten.

Docker-Volumes haben keine unabhängige Quote. Überwache Wachstum und setze Hostlimits. Kubernetes-PVC-Quoten hängen vom Provisioner ab.

Docker-Produktionshärtung

Diese Liste gilt für Docker. Kubernetes-Betreiber prüfen zusätzlich RBAC, Pod-Sicherheit, Speicherklasse und CNI-NetworkPolicy gemäß Kubernetes. Die Anwendung kann Containeroptionen und Pfade prüfen, aber Hostfirewall, Speicherquoten und Daemonrechte nicht erzwingen.

1. Docker-Steuerung isolieren

Der Hauptcontainer braucht Daemonkontrolle; ein Socket ist eine Steuerungsebenen-Anmeldedatei. Kompromittierung kann den Host betreffen.

docker-compose.socket-proxy.yml hält /var/run/docker.sock aus Libre WebUI heraus und leitet intern nur Container, Images, Volumes, Netze, exec und Info weiter; swarm, Geheimnisse, configs, build, commit und System werden verweigert. DOCKER_HOST=tcp://docker-socket-proxy:2375 gilt für CLI, Terminal und Diagnose. Der Proxy begrenzt Oberfläche, nicht Schadensradius, weil Container Hostpfade mounten können. Nutze für stärkere Trennung eine eigene VM, rootless Daemon oder separaten Host.

2. Sandboxzugriff auf Hostverwaltung blockieren

ICC verhindert gegenseitigen Zugriff, nicht Hostdienste. Ermittle Bridge und Subnetz:

docker network inspect libre-webui-work \
  --format 'id={{.Id}} subnets={{range .IPAM.Config}}{{.Subnet}} {{end}}'
ss -lntup

Blockiere vom Bridge-Netz SSH, Docker-API, Datenbanken und Verwaltungsports. Teste Regeln und erlaubte Downloads. DOCKER-USER steuert Weiterleitung; Hostziele können zusätzlich INPUT benötigen.

3. Ausgangsziele beschränken

Blockiere Cloudmetadaten, private Infrastruktur und Kunden-LAN ohne ausdrücklichen Bedarf. Kombiniere WORK_RUNTIME_DNS und Firewall. Weder DNS allein (direkte IP) noch HTTP-Proxy allein (direkte Verbindungen) genügt. Pflege getrennte Richtlinien für offline, nur Paketregister und offenen Ausgang.

4. Echte Speicherquoten erzwingen

CPU-/Speicher-/PID-Limits begrenzen Volumes nicht. Nutze XFS-Projektquoten, quotierte logische Volumes oder einen Volume-/PVC-Treiber mit Größenlimit. Docker local auf ext4 erhält nicht durch Dokumentation eine Quote. Überwache ai.libre-webui.managed=true-Volumes und Docker-Datenwurzel; ein du-Check ist nur Warnung, keine Grenze.

5. Bereitgestellte Richtlinie prüfen

Prüfe nach Image-/Daemonänderungen mit docker inspect: Benutzer ohne root, schreibgeschützte Wurzel, entfernte Fähigkeiten, no-new-privileges, alle Limits, nur Aufgabenvolume und erwartetes Netz. Prüfe Hauptcontainer-Mounts und dass öffentlicher Zugriff nur über authentifizierten Proxy erfolgt.

Vorschau: Sicherheit und Erreichbarkeit

Docker veröffentlicht den Vorschauport dynamisch auf Backend-Loopback; Kubernetes zielt auf die Pod-IP. Libre WebUI signiert eine Fähigkeits-URL, prüft den Prozess und proxyt HTTP/WebSocket über /api/work/previews. Stoppen oder Neustart widerruft sie.

Antworten entfernen Anmeldedaten und Upstream-Cookies. iframe-Sandbox und CSP erlauben Skripte, Formulare, Modale und Downloads ohne Same-Origin. Erzeugter Code bleibt nicht vertrauenswürdig und kann Daten übertragen; teile die kurzlebige URL nicht.

Da der Browser den Proxy vom öffentlichen Libre WebUI-Ursprung lädt, funktionieren Remote-Browser und HTTPS ohne veröffentlichte Ports oder Mixed Content. Reverse- Proxys müssen /api/work/previews/-WebSockets erhalten.

Die Hauptanwendung erlaubt nur eigenen Ursprung und Cloudflare Turnstile als Frames. Vorschauen umgehen Helmet für Streaming und engere Sandbox-CSP; Cross-Origin- Embedder bleibt aus.

Bereitstellungsmatrix

Bereitstellung	Work-Ausführungen und Dateien	Eingebettete Vorschau
npx libre-webui lokal	Unterstützt bei installiertem, laufendem und aufrufbarem Docker.	Über signierten Anwendungsproxy.
Lokale Quellcodeentwicklung	Unter denselben Docker-/Anbieteranforderungen.	Über Entwicklungs-API auf Port 3001.
Electron-Desktopclient	Bedingt; nutzt externes Backend und liefert keine eigene Work-Laufzeit.	Über dessen signierten Proxy.
Bare-Metal-/VM-Backend remote	Funktioniert bei Docker auf diesem Host.	Bei Erhalt von HTTP/WebSocket durch öffentlichen Proxy.
Standard-Repository-Compose	Standardmäßig unter Docker Desktop: Image enthält CLI, Compose mountet Hostsocket, Work-Ports laufen über host.docker.internal. Native Docker Engine braucht zusätzlich ein erreichbares, nicht öffentliches WORK_PREVIEW_BIND.	Über denselben öffentlichen Ursprung.
Aktuelles Kubernetes/Helm	Mit --set work.enabled=true: Pods mit PVC für Ausführungen, Dateien, Befehle, git, Terminal, Work Computer-Bildschirm/Audio; Namensraum-Role und Default-Deny, kein Socket. Siehe Kubernetes.	Backend im Cluster proxyt direkt zur Pod-IP.

Work ausführen, wenn Libre WebUI in Docker läuft

Alle Compose-Dateien aktivieren Work: Image enthält CLI und mountet /var/run/docker.sock. Docker Desktop funktioniert mit den mitgelieferten Routing-Standards; native Docker Engine braucht zusätzlich ein WORK_PREVIEW_BIND auf einer nicht öffentlichen, aus Geschwistercontainern erreichbaren Hostschnittstelle, wie unten beschrieben. Aufgabencontainer sind Geschwister, erscheinen in docker ps und folgen denselben Lebenszyklen.

Der Socket gibt root-gleiche Hostkontrolle. Jeder Libre WebUI-Administrator ist praktisch Docker-Hostadministrator. Entferne die Socketzeile, um Work zu deaktivieren.

Alternativ hält docker-compose.socket-proxy.yml den Socket intern und Libre WebUI nutzt DOCKER_HOST. Siehe Docker-Steuerung isolieren.

Drei Bedingungen:

1. Docker CLI vorhanden. Offizielles Image enthält sie; eigene brauchen docker-cli oder WORK_DOCKER_COMMAND. Sonst: The "docker" CLI is not installed….
2. Socket gemountet. Sonst: No Docker daemon is reachable….
3. Backendbenutzer in Socketgruppe. Image nutzt nodejs (uid 1001), der Socket gehört normalerweise root oder docker, und Compose nutzt group_add: ['${DOCKER_GID:-0}']. Docker Desktop passt, Linux braucht Gruppen-ID. Sonst: The Docker socket is mounted but the Libre WebUI user cannot open it….

# Read the socket's group as seen INSIDE a container. A macOS host reports a
# different value, because Docker Desktop proxies the socket through a VM.
echo "DOCKER_GID=$(docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  alpine stat -c '%g' /var/run/docker.sock)" >> .env
docker compose up -d --force-recreate

Vorschauports bleiben auf Host-Loopback und werden über signierte Same-Origin-URLs mit HTTP/WebSocket exponiert. Bei Backend in Docker behalte WORK_PREVIEW_BIND=127.0.0.1 und setze WORK_DOCKER_PUBLISHED_HOST auf die vom Container erreichbare Hostadresse (host.docker.internal bei Docker Desktop). Die mitgelieferten Compose-Profile setzen beide Werte und bilden den Hostnamen ab. Native Linux-Deployments müssen WORK_PREVIEW_BIND mit dem Docker-Bridge-Gateway (oder einer anderen ausdrücklich erreichbaren, nicht öffentlichen Hostschnittstelle) überschreiben; das Abbilden von host.docker.internal allein macht einen Listener auf dem Host-Loopback nicht erreichbar. Binde diese kurzlebigen Ports niemals an 0.0.0.0.

Parallelität: WORK_MAX_ACTIVE_RUNTIMES_PER_USER standardmäßig 2, WORK_MAX_ACTIVE_RUNTIMES_GLOBAL 3. Die Fähigkeitsantwort meldet Limits und Belegung.

Für Kubernetes installiere work.enabled=true; Helm erstellt RBAC, Namensraum, Netzrichtlinien und Pod/PVC, wie unter Kubernetes beschrieben.

Laufzeitkonfiguration

Variable	Standard	Zweck
WORK_RUNTIME_BACKEND	docker	Treiber docker oder kubernetes
WORK_RUNTIME_IMAGE	node:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3	Sandboximage
WORK_DOCKER_COMMAND	docker	Docker-CLI
WORK_COMMAND_TIMEOUT_MS	120000	Standardbefehlszeit
WORK_MAX_OUTPUT_CHARS	50000	Erfasste Ausgabe
WORK_MAX_AGENT_ROUNDS	48	Rundenbudget je Ausführung
WORK_MEMORY_LIMIT	2g	Speicher je Container
WORK_CPU_LIMIT	2	CPU je Container
WORK_PIDS_LIMIT	256	Prozesse je Container
WORK_PREVIEW_PORT	4173	Interner Anwendungsport
WORK_PREVIEW_BIND	127.0.0.1	Hostschnittstelle
WORK_DOCKER_PUBLISHED_HOST	wie WORK_PREVIEW_BIND	Vom Backend angewählter veröffentlichter Host
WORK_COMPUTER_SCREEN_PORT	6080	Bildschirm-WebSocket
WORK_COMPUTER_AUDIO_PORT	6081	Audio-WebSocket
WORK_RUN_LEASE_WAIT_MS	60000	Warten auf temporäre Lease
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL	3	Gleichzeitige Aufgaben pro Instanz
WORK_MAX_ACTIVE_RUNTIMES_PER_USER	2	Gleichzeitige Aufgaben pro Administrator
WORK_MAX_TASKS_GLOBAL	500	Dauerhafte Aufgaben pro Instanz
WORK_MAX_TASKS_PER_USER	100	Dauerhafte Aufgaben pro Administrator
WORK_NETWORK_NAME	libre-webui-work	Verwaltetes Bridge-Netz
WORK_RUNTIME_DNS	nicht gesetzt	Kommagetrennte Resolver-IPs
WORK_DOCKER_SOCKET	DOCKER_HOST bei unix:// oder tcp://, sonst /var/run/docker.sock	Engine-Endpunkt für Terminal
WORK_TERMINAL_MAX_SESSIONS_PER_TASK	2	Parallele Terminals je Aufgabe
WORK_TERMINAL_IDLE_TIMEOUT_MS	900000	Terminal-Leerlauf
WORK_RUNTIME_IDLE_TIMEOUT_MS	0 (deaktiviert)	Sandbox nach Inaktivität stoppen
WORK_K8S_NAMESPACE	libre-webui-work	Pod-/PVC-Namensraum
WORK_K8S_STORAGE_CLASS	Clusterstandard	PVC-StorageClass
WORK_K8S_WORKSPACE_SIZE	5Gi	PVC-Größe je Aufgabe
WORK_K8S_POD_READY_TIMEOUT_MS	900000	Maximales Warten auf Bereitschaft
WORK_K8S_POD_GONE_TIMEOUT_MS	60000	Maximales Warten auf gelöschten Pod

Nutze in Produktion festes Image oder Digest. Zulassungsoperationen teilen dieselbe Kapazitätsrechnung; Überschreitung ergibt HTTP 429.

Feste Protokoll- und UI-Limits

Element	Limit
Neue Aufgaben-/Ausführungsnachricht	65,536 Zeichen und UTF-8-Bytes
Modell-ID bei Erstellung/Aktualisierung	500 Zeichen und UTF-8-Bytes
Pluginanbieter-ID	200 Zeichen
Aktive Ausführungen je Aufgabe	1
Befehlstext	20,000 Zeichen
Werkzeugzeitlimit	1 bis 600 Sekunden
Vorschau-Bereitschaft	15 Sekunden
Datei lesen/schreiben	2,000,000 Bytes UTF-8-Text
Direktes Verzeichnislisting	Erste 1,000 Einträge
Nachrichtenseite	Bis 200 Nachrichten und 1,000,000 Bytes
Einzelne gespeicherte Nachricht	100 KB
Modellkontext	Letzte 30 Nachrichten, bis 256 KB
Gespeicherte Werkzeugausgabe	Etwa 20,000 Quellzeichen plus Marker
Live-Hervorhebung	8,000 Zeichen und 400 Zeilen
Browserformatierung	100,000 Zeichen und 4,000 Zeilen
Git-Statusausgabe	2,000,000 Zeichen
Git-Diffausgabe	600,000 Zeichen
Git-Verlauf	20 lokale Commits
Pfade pro Git-Stage	200
Git-Commitnachricht	4,000 Zeichen
Agentenschleife	Standard 48, durch WORK_MAX_AGENT_ROUNDS
Werkzeugbudget	max(128, configured rounds × 8) Aufrufe

Dateien sind UTF-8-Text; Binärdateien und über 2 MB sind nicht im Editor verfügbar.

API-Zusammenfassung

Alle Endpunkte liegen unter /api/work und verlangen Authentifizierung und aktuellen Zugriff. Hostordner und Verwaltungsrichtlinien bleiben administrativ.

Methode	Pfad	Zweck
GET	/capabilities	Verfügbarkeit und Limits
GET	/tasks	Eigene Aufgaben
POST	/tasks	Aufgabe und erste Ausführung erstellen
GET	/tasks/:id	Zustand und Nachrichten laden
GET	/tasks/:id/messages	Ältere Nachrichten
PATCH	/tasks/:id	Umbenennen oder Modellroute ändern
DELETE	/tasks/:id	Aufgabe und Bereich entfernen
POST	/tasks/:id/runs	Folgeausführung
POST	/tasks/:id/messages	Agenten während Ausführung schreiben
GET	/tasks/:taskId/runs/:runId/events	Authentifizierte SSE-Ereignisse
POST	/tasks/:id/cancel	Aktive Ausführung abbrechen
GET	/tasks/:id/approvals	Offene Freigaben und Zustand der Automatischen Prüfung
PUT	/tasks/:id/approvals	Freigaben für die Aufgabe ein- oder ausschalten
POST	/tasks/:id/approvals/:approvalId	Offene Freigabe entscheiden (einmal, immer, verweigern)
DELETE	/tasks/:id/approval-rules/:ruleId	Regel „Immer erlauben“ entfernen
GET	/computer/setup	Work Computer-Einrichtung
POST	/computer/setup	GUI-Image bauen und Richtlinie erstellen
POST	/tasks/:id/computer/start	Sitzung starten
GET	/tasks/:id/computer/control	Aktueller Fahrer/Anfrage
POST	/tasks/:id/computer/control	Übernehmen/erneuern
DELETE	/tasks/:id/computer/control	Zurückgeben
POST	/tasks/:id/computer/teach	Demonstration speichern
POST	/tasks/:id/computer/anchor	Element unter Klick auflösen
POST	/computer/skills/:slug/trace	Erfolg/Fehler anhängen
GET	/tasks/:id/files	Verzeichnis listen
GET	/tasks/:id/file	Textdatei lesen
PUT	/tasks/:id/file	Textdatei speichern
GET	/tasks/:id/git	Git-Status/Verlauf
GET	/tasks/:id/git/diff	Begrenzten Diff lesen
POST	/tasks/:id/git/init	Git initialisieren
POST	/tasks/:id/git/stage	Pfade stagen
POST	/tasks/:id/git/commit	Änderungen committen
POST	/tasks/:id/git/branches	Zweig erstellen
POST	/tasks/:id/git/switch	Zu sauberem Zweig wechseln
POST	/tasks/:id/preview/start	Vorschau starten
POST	/tasks/:id/preview/stop	Vorschau stoppen

Aufgaben-ID wird gegen Eigentümer geprüft; Status, Rolle und Zugriff kommen bei jeder Anfrage aus der Datenbank. networkEnabled bleibt nur für interne Kompatibilität; wähle beim Erstellen eine passende Richtlinie.

Löschen, Kontoänderungen und Sicherung

Aufgabe löschen

Das Löschen ist bewusst destruktiv:

1. Backend markiert die Aufgabe als auslaufend und blockiert Änderungen.
2. Aktive Ausführung wird abgebrochen, Sandbox gestoppt.
3. Eigentumslabels werden validiert.
4. Container/Pod und Volume/PVC werden entfernt.
5. Datenbankaufgabe samt Ausführungen/Nachrichten wird gelöscht.
6. Browserentwürfe werden nach API-Erfolg gelöscht.

Schlägt Laufzeitbereinigung fehl, bleibt der Datensatz und ein Fehler erlaubt Reparatur und Wiederholung. Metadaten werden nicht bei unkontrollierten Ressourcen gelöscht. Stoppen von Ausführung oder Vorschau bewahrt Volume und Unterhaltung.

Herabstufung und Benutzerlöschung

Bei Herabstufung wird Rollenentzug vor Laufzeitbereinigung gespeichert. Jede spätere Anfrage prüft Rolle und Zugriff. Aufgaben werden suspendiert, Ausführungen abgebrochen und Sandboxes gestoppt. Fehler ändern den Entzug nicht und werden zur Reparatur gemeldet.

Beim Löschen eines anderen Benutzers werden zuerst dessen Ressourcen entfernt. Schlägt externe Reinigung fehl, bleibt der Benutzer für sichere Wiederholung erhalten.

Vollständige Aufgabe sichern

Erforderlich sind:

• Libre WebUI-Datenbank mit Eigentum, Ressourcennamen, Routing, Ausführungen, Nachrichten und Aktivität; und
• alle Docker-Volumes/Kubernetes-PVCs mit ai.libre-webui.managed=true.

Container und Vorschauprozesse brauchen keine Sicherung. Stoppe neue Aktivität und Backend für konsistente Aufnahme. Stelle Datenbank und passende Bereiche gemeinsam wieder her, unter exakten Namen und mit ai.libre-webui.task=<task UUID> sowie ai.libre-webui.managed=true. Nur Dateien bewahren Labels nicht; nur Datenbank verliert Dateien, nur Speicher verliert Eigentum und Namen. Bei verschlüsselten Anbieterdaten beachte Hauptsicherung und Schlüssel.

Lokalisierung und arabisches RTL

Work ist in 25 Sprachen übersetzt: Englisch, Arabisch, Bengalisch, Tschechisch, Dänisch, Deutsch, Spanisch, Französisch, Hindi, Indonesisch, Isländisch, Italienisch, Japanisch, Koreanisch, Malaiisch, Niederländisch, Polnisch, Portugiesisch, Russisch, Schwedisch, Thailändisch, Türkisch, Ukrainisch, Vietnamesisch und Chinesisch.

Arabisch setzt lang="ar" und dir="rtl" vor React. Seitenleiste, Teilung, Symbole, Tabs und Größenänderung folgen RTL. Technischer Inhalt bleibt LTR:

• Code und Hervorhebung;
• Dateipfade;
• Modell-IDs;
• Befehle und Vorschauprotokolle;
• Werkzeugausgabe und Metadaten; und
• Codeblockinhalt.

Natürliche Namen, Prompts, Fehler und Dateinamen nutzen automatische Richtung.

Fehlerbehebung

Laufzeit bei npx nicht verfügbar

npx libre-webui installiert Docker nicht. Führe docker info als derselbe Betriebssystembenutzer aus. Installiere/starte Docker oder korrigiere Rechte und lade Work neu. Bestätige außerdem gesundes Ollama oder ein aktives Plugin mit Modell und Anmeldedaten.

Laufzeit in Docker oder Kubernetes nicht verfügbar

Repository-Compose sollte dies nicht melden: Image enthält CLI, Compose mountet Socket. Das Panel nennt fehlende CLI, Mount oder Gruppe. Setze bei Gruppe DOCKER_GID und erstelle neu. Siehe Work ausführen, wenn Libre WebUI in Docker läuft.

Aktiviere Kubernetes mit --set work.enabled=true. Libre meldet kubernetes, prüft die API und nutzt Pods/PVC. Mounte keinen Node-Runtimesocket; siehe Kubernetes.

Keine Work-kompatiblen Modelle

Wähle in Ollama ein Modell mit tools. Bei Plugins: Typ Chat/Vervollständigung, aktiv, exaktes Modell im Mapping, nutzbarer API-Schlüssel und Werkzeugprotokoll. Work fällt nie auf anderen Anbieter zurück.

Paketinstallation oder Remote-Git schlägt fehl

Bestätige Netzwerk in der Richtlinie. Prüfe DNS, Proxy, Firewall/NetworkPolicy, Registry, Zertifikat, Image und Upstream. Git-Tab ist lokal; nutze Terminal/Modell für remote nur bei bewusster Netzwerk-/Anmeldedatenrichtlinie. Keine dauerhaften Tokens.

Ausführung stoppt an Agentengrenze

Runden- oder Werkzeugbudget kann erschöpft sein. Work fordert letzte werkzeuglose Übergabe; prüfe Arbeit und Restschritte. Zustand bleibt Eingabe nötig. Starte eine Folgeausführung oder erhöhe WORK_MAX_AGENT_ROUNDS bewusst.

HTTP 429 beim Start

Aktive Laufzeit- oder Aufgabenbegrenzung erreicht. Warte auf Stopp, lösche alte Aufgaben oder erhöhe WORK_MAX_* bei ausreichenden Ressourcen.

Vorschau wird nicht bereit

Befehl muss laufen, auf 0.0.0.0 und WORK_PREVIEW_PORT innerhalb 15 Sekunden lauschen. Automatik erkennt package.json-dev oder index.html, auch eine verschachtelte App. Bei mehreren/keiner gib einen Befehl an. Er beginnt in /workspace, etwa cd <app-directory> && ....

Vorschau funktioniert nur auf Server

Nutze Build mit signiertem Proxy und starte neu. Für Hot Reload erhalte WebSocket unter /api/work/previews/. Der Dockerport bleibt auf Loopback.

Dateien bleiben, Vorschau stoppt

Nach Abbruch, Neustart, explizitem Stopp oder Bereitschaftsfehler erwartet. Prozess ist flüchtig, Volume dauerhaft. Starte erneut.

Datei kann nicht geöffnet/gespeichert werden

API akzeptiert UTF-8 bis 2 MB. Bei Konflikt neu laden. Hervorhebung wechselt über 8,000 Zeichen/400 Zeilen zu Text; Formatierung hat 100,000/4,000 und dokumentierte Dateifamilien.

Work stellt Sandboxes wieder her

Start oder Abbau konnte Stopp nicht beweisen. Work bleibt geschlossen und versucht alle 10 Sekunden. Stelle Docker-/Kubernetes-Zugriff wieder her und prüfe Protokoll. Lösche keine Datenbankzeilen vor Ressourcenabgleich.

Löschen schlägt fehl

Prüfe Erreichbarkeit. Eine Ressource ohne erwartetes ai.libre-webui.task wird bewusst abgelehnt. Löse Namens-/Eigentumskonflikt und wiederhole.

Sicherheitszusammenfassung

• Work ist standardmäßig administrativ; Öffnung macht jedes Konto zum Sandboxbetreiber. Hostordner bleiben administrativ.
• Backend muss Docker-Daemon oder Kubernetes-Namensraum kontrollieren.
• Container sind keine VMs.
• Aufgaben ohne Offline-Richtlinie haben Ausgang; Zielbeschränkung bleibt Betreiberpflicht.
• Volumes haben keine unabhängige Quote.
• Git ist lokal; API akzeptiert keine Remote-Anmeldedaten.
• Firewall, Daemonisolation, Ausgang und Quoten werden vom Betreiber erzwungen.
• Remote-Anbieter erhalten Ergebnisse und können mehrere Aufrufe verursachen.
• Vorschauports bleiben Loopback und werden nur signiert, widerrufbar proxyt.
• Compose liefert Docker, Kubernetes/Helm Pod/PVC bei work.enabled=true.
• Vollständige Sicherung braucht Datenbank und Work-Volumes.

Verwandte Dokumentation

• Schnellstart
• Mit Modellen arbeiten
• Tastaturkürzel
• Umgebungsvariablen
• Docker
• Kubernetes
• Authentifizierung
• Fehlerbehebung