Work: geïsoleerde werkruimten

Work is het eigen oppervlak van Libre WebUI voor programmeeragenten. Elke Work-taak combineert een duurzaam gesprek, een expliciete model-providerroute en een speciaal bestandssysteem op /workspace. Het geselecteerde model kan bestanden bekijken en bewerken, opdrachten uitvoeren in een Docker-container of Kubernetes-Pod die tot de taak is beperkt, en een browserversie starten.

Work is rechtstreeks in Libre WebUI geïmplementeerd. Libre Claw of een andere agentdaemon is niet vereist.

Alleen vertrouwde gebruikers

Elke Work-API vereist een geverifieerd account met Work-toegang. Standaard zijn dat alleen beheerders; een beheerder kan Work via het tabblad Gebruikersbeheer in Settings voor alle actieve gebruikers openen (werkruimten in hostmappen blijven altijd alleen voor beheerders, omdat ze serverpaden bind-mounten). Work laat een model bewust willekeurige shellopdrachten in een sandbox uitvoeren. Taken gebruiken uitgaand netwerkverkeer, tenzij hun geselecteerde benoemde runtimebeleid dit uitschakelt. Behandel iedereen met Work-toegang als vertrouwde runtimeoperator, niet alleen als chatgebruiker.

Hoogtepunten van deze release

Deze release introduceert Work als volledige taakwerkstroom:

• Afzonderlijke acties Work en Chat in de hoofdzijbalk, met de actieve modus duidelijk geselecteerd.
• Work-taken in de normale zijbalk in plaats van een tweede takenbalk. Bestaande taakposities blijven stabiel tijdens updates en de geselecteerde taak kan rechtstreeks worden verwijderd.
• Een eigen sandboxidentiteit en duurzaam Docker-volume of Kubernetes-PVC per taak. Sandboxen kunnen worden gestopt of opnieuw gemaakt zonder taakbestanden te verwijderen.
• Duurzaam gesprek, uitvoeringsstatus, toolactiviteit, modelselectie en taakeigendom in de database van Libre WebUI.
• Een live, geverifieerde uitvoeringsstroom voor assistenttekst, door de provider getoonde redenering, toolaanroepen en resultaten, gebruik, workervaardigheden en statuswijzigingen.
• Workervaardigheden van de server die het model leren efficiënt te inspecteren, bewerken, verifiëren en voorbeelden te starten zonder besturingsbestanden in het project te schrijven.
• Lokale Ollama-modellen die tools ondersteunen, Ollama Cloud-modellen en ingestelde voltooiings- of chatproviderplugins.
• Een responsieve splitsing Gesprek/Werkruimte met versleepbare en toetsenbordtoegankelijke afmetingen op desktop en een oppervlakteschakelaar op kleinere schermen.
• Geïntegreerde weergaven Bestanden, Activiteit, Git, Terminal, Voorbeeld en Scherm — Scherm is de zichtbare en aanleerbare Work Computer-desktop.
• Syntaxismarkering in donkere en lichte modus, codeopmaak in de browser, detectie van opslagconflicten en tijdelijke niet-opgeslagen concepten.
• Een sluitbare melding per gebruiker wanneer een externe modelprovider is geselecteerd.
• Volledige Work-vertalingen voor alle 25 ondersteunde talen, inclusief eigen Arabische indeling van rechts naar links, terwijl code, paden, model-ID's en opdrachtuitvoer van links naar rechts blijven.

De duurzame eenheid is de werkruimte van de taak, niet een continu actieve container. Libre WebUI start, stopt en kan de taakcontainer naar behoefte opnieuw maken terwijl het benoemde volume behouden blijft.

Architectuur

Libre WebUI, niet het model of de browser, kiest namen van sandbox en werkruimte, image, mount, gebruiker, limieten, netwerkmodus en voorbeeldpoort. Het model krijgt alleen deze tools:

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

delete_file en move_file hebben dezelfde padbescherming als de andere bestandstools: ze weigeren de werkruimte te verlaten, volgen nooit symlinks, vereisen een expliciete recursieve vlag voor het verwijderen van een map en overschrijven nooit een verplaatsingsdoel. Omdat ze via de bestandshelper lopen in plaats van een shell, werken ze ook terwijl een voorbeeld actief is en run_command is geblokkeerd.

Modelverzoeken worden door de Libre WebUI-backend gedaan. Ze komen niet uit de Work-container en hangen niet af van het netwerkbeleid van die container.

Vereisten

Work heeft een ingestelde sandboxbackend nodig:

• De standaardbackend vereist Docker met een bereikbare daemon en toestemming voor het backendproces om docker aan te roepen (of het via WORK_DOCKER_COMMAND ingestelde uitvoerbare bestand).
• De Kubernetes-backend vereist API-referenties plus de namespacegebonden Role, RoleBinding, sandboxnamespace en NetworkPolicies die de Helm-chart maakt wanneer work.enabled=true.

Elke backend vereist daarnaast:

• Een model dat tools ondersteunt en beschikbaar is via:
  • een gezonde Ollama-service, inclusief modellen via Ollama Cloud; of
  • een actieve voltooiings-/chatplugin met exact ingesteld model en referenties voor de huidige beheerder.
• Voldoende runtimeopslag voor de image, gegenereerde projecten en projectlokale afhankelijkheden.
• Een geverifieerd account met Work-toegang. Work is standaard alleen voor beheerders; een beheerder kan het voor alle actieve gebruikers openen.

Libre WebUI controleert de door Ollama gemelde modelmogelijkheden voordat een uitvoering wordt gemaakt en weigert een Ollama-model dat tools niet meldt. Modellen via plugins moeten het toolaanroepprotocol van hun provider ondersteunen. Als een geselecteerd extern model tools weigert, mislukt de uitvoering; Work schakelt niet stil naar een ander model of een andere provider.

Lokaal starten

Voer voor de eenvoudigste ondersteunde Work-installatie Libre WebUI en Docker uit op dezelfde computer als de browser:

docker info
npx libre-webui@latest

Open http://localhost:8080, meld je aan als beheerder, selecteer Work in de zijbalk, kies een compatibel model en beschrijf het project of de wijziging.

Als Docker ontbreekt, gestopt is of niet toegankelijk is, toont Work Runtime niet beschikbaar met de reden van de backend en schakelt de uitvoeropsteller uit. Libre WebUI valt nooit terug op rechtstreekse uitvoering van Work-opdrachten op de host.

De runtime-image wordt bij het eerste gebruik geïnspecteerd en automatisch opgehaald als deze ontbreekt. De eerste bewerking kan daardoor langer duren dan latere bewerkingen.

De Work-interface gebruiken

Taken maken en opnieuw openen

Selecteer Work naast Chat in de zijbalk. Voer een instructie in, kies een model en selecteer Uitvoeren. Het eerste bericht maakt de taak, eerste uitvoering, providerroute en duurzame werkruimte.

Elke taak blijft in de hoofdzijbalk. Opnieuw openen herstelt het recente gesprek, de weergave Bestanden, huidige provider-/modelselectie en werkruimte. Oudere gespreksberichten kunnen in pagina's worden geladen. Je kunt de taak via de titel hernoemen en permanent verwijderen vanuit het menu van de geselecteerde taak of de zijbalk.

Er kan per taak maar één uitvoering actief zijn. Een latere instructie maakt een nieuwe uitvoering tegen hetzelfde gesprek en bestandssysteem.

De opsteller ondersteunt dicteren: een microfoonknop gebruikt waar beschikbaar de spraak-API van de browser, of anders een ingesteld spraak-naar-tekstmodel van een provider, en voegt het transcript toe aan wat al was getypt. Bestanden die een uitvoering maakt of verplaatst verschijnen in het gesprek als aanklikbare chips onder de verantwoordelijke toolactiviteit. Een klik opent het bestand in de Bestanden-editor en schakelt op smalle schermen naar de werkruimte. Chips komen alleen van wijzigende tools, dus een uitvoering die twintig bestanden leest en één schrijft toont precies dat ene artefact.

Een agent inhuren

Wanneer je persona's hebt, biedt de startweergave Als agent inhuren. Kies er een en de gemaakte taak wordt een duurzame benoemde agent in plaats van een eenmalige taak. Een agent behoudt de persona tussen uitvoeringen: naam en systeemprompt van de persona komen vóór de Work-systeemprompt (het runtimecontract van de sandbox heeft altijd voorrang). De zijbalk zet agenten in een eigen groep Agenten boven losse taken, elk met persona-avatar, activiteitsindicator en statusregel. Is de zijbalk compact, dan blijven alleen die vastgezette agent-avatars in de rail staan; eenmalige Work-taken keren terug zodra de zijbalk is uitgeklapt.

De statusregel heeft twee niveaus. Voor ingehuurde agenten vraagt één goedkope modelaanroep zonder tools aan het einde van een uitvoering om een status van ongeveer 8 woorden („Inbox leeg. 2 antwoorden klaar.”). Het antwoord is beperkt tot één regel van 90 tekens en bij fout of time-out wordt teruggevallen op het deterministische niveau: de eerste regel van het laatste assistentbericht. Losse taken en mislukte uitvoeringen gebruiken alleen dat niveau; WORK_STATUS_BLURB_MODEL=0 schakelt de modelaanroep geheel uit. Agenten hebben ook een ongelezenindicator: openen van de taak verplaatst een monotone, apparaatoverstijgend gesynchroniseerde gezienmarkering per taak. De zijbalk toont een stip wanneer een uitvoering daarna een eindstatus bereikt.

Agenten melden hun voortgang ook via meldingen, in de app en waar ingeschakeld via webpush: work-run-finished na voltooiing, work-run-attention wanneer invoer nodig is of een fout optreedt, en work-takeover zodra de agent om schermovername vraagt. De banner is alleen zichtbaar wanneer Scherm open is, dus de pushmelding bereikt je elders. Elke melding linkt rechtstreeks naar de agent.

Je kunt een eigen of met jou gedeelde persona gebruiken; de gedeelde weergave onthult nooit herinneringen van de eigenaar. Als de persona later wordt verwijderd, blijft de agent zonder persona werken en wordt een waarschuwing gelogd. De API accepteert personaId en isAgent bij het maken van een taak; een taak met persona is automatisch een agent.

Het tabblad Agent

Het werkruimtepaneel van een agent opent met een extra eerste tabblad, Agent — de eigen pagina van de agent:

• Identiteit: persona-avatar, naam, activiteitsindicator en laatste statusregel.
• Scherm: wanneer het taakbeleid Work Computer toestaat, een compacte live miniatuur van het scherm die alleen bekeken kan worden. Dit is een echte viewer en telt mee voor het viewerbudget; klikken opent het volledige tabblad Scherm met overname, aanleren en audio.
• Routines: automatiseringen die aan deze taak zijn gekoppeld. Elke activering draait in de eigen werkruimte en het gesprek van de agent met diens model en runtime — niet als nieuwe taak — zodat een ochtendbriefing op één plek wordt opgebouwd. Rijen tonen het schema in woorden met pauzeren/hervatten; het formulier + Routine is al aan de agent gekoppeld. Een activering terwijl de agent bezig is mislukt eerlijk als work-task-busy in plaats van in de wachtrij te gaan.
• Automatische beoordeling: de goedkeuringsschakelaar per agent en de Altijd-toestaan-regels die de agent heeft verzameld (verwijder een regel om het bereik weer te sluiten). Wanneer het taakbeleid beoordeling afdwingt, staat de schakelaar vast aan.
• Aangeleerde vaardigheden: procedures die in aanleermodus zijn gedemonstreerd, met een schakelaar per vaardigheid.

Verbonden tools (MCP- en OpenAPI-servers)

Work-agenten kunnen dezelfde toolservers aanroepen die voor chat zijn ingesteld — MCP of OpenAPI, door een beheerder geregistreerd onder Instellingen → Tools. De tools verschijnen bij de agent onder hun namespacenamen (server__tool) en de aanroepen vertrekken vanuit de backend van Libre WebUI via de geharde toolgateway (SSRF-bewaakt uitgaand verkeer, referenties per gebruiker, limieten voor omvang en tijd) — nooit vanuit de sandbox.

Het aanbod is eerlijk over wat een autonome uitvoering echt kan gebruiken:

• Een offlinetaak biedt er geen: met of zonder uitgaand verkeer vanuit de backend blijft een taak zonder netwerktoegang offline — dezelfde redenering als bij web_search.
• Een server die een persoonlijke referentie vereist die de gebruiker niet heeft opgeslagen, wordt bij het aanbod weggefilterd, omdat een autonome uitvoering niet kan pauzeren om erom te vragen. Voeg de referentie toe onder Instellingen → Tools en de volgende uitvoering biedt de server aan.
• De toegangsmodus voor tools (alleen beheerders of alle gebruikers) en de zichtbaarheid per server gelden precies zoals in chat, en de toolserverkoppelingen van een persona beperken welke servers de ingehuurde agent ziet.
• Wanneer goedkeuringen actief zijn, pauzeren verbonden tools die de server als met neveneffecten aanmerkt voor uw beslissing, net als elke bewaakte actie; alleen-lezen tools draaien zonder te vragen.

Delegatie tussen agenten (@-vermeldingen)

Ingehuurde agenten kunnen werk aan elkaar doorgeven. Typ @ in het Work-invoerveld om een van uw andere agenten te noemen; de huidige agent ziet de lijst met collega's (namen en statusregels) in zijn instructies en delegeert passende verzoeken met de tool message_agent. Delegatie is coördinatie via berichten, bewust niet via gedeelde computers: elke agent houdt zijn eigen geïsoleerde werkruimte en sandbox, en de ontvanger kan het delegerende gesprek niet zien — het verzoek moet zijn eigen context meebrengen.

Delegatie is asynchroon. De tool keert direct terug, de ontvangende agent draait in zijn eigen taak (zijn gesprek toont het verzoek met het label Gedelegeerd door de afzender) en wanneer hij klaar is — voltooid, invoer nodig, mislukt of geannuleerd — wordt zijn eindantwoord in het gesprek van de delegerende agent afgeleverd als bericht met het label Rapport van die agent. Draait de delegerende agent nog, dan bereikt het rapport zijn model bij de volgende ronde; is hij inactief, dan wacht het rapport gewoon in het gesprek — een rapport start nooit vanzelf een uitvoering, dus twee agenten kunnen niet heen en weer blijven kaatsen. Gedelegeerde uitvoeringen kunnen niet verder delegeren, een bezette ontvanger laat de poging eerlijk mislukken in plaats van hem in de wachtrij te zetten, en wanneer goedkeuringen actief zijn pauzeert message_agent voor beoordeling zoals elke andere actie met neveneffecten (een Altijd-toestaan-regel geldt alleen voor die ene doelagent).

Actiegoedkeuringen (Automatische beoordeling)

Acties met neveneffecten kunnen voor uw beslissing pauzeren voordat ze draaien. Wanneer goedkeuringen voor een taak actief zijn — het Work-beleid stelt Goedkeuring vereisen voor acties met neveneffecten in, of de schakelaar Automatische beoordeling van de agent staat aan — stopt de uitvoering vóór het uitvoeren van run_command, computer_act, delete_file, move_file of message_agent en toont een beslissingskaart in het gesprek: Eén keer toestaan, Altijd toestaan of Weigeren.

• Eén keer toestaan voert precies deze aanroep uit en vraagt het de volgende keer opnieuw.
• Altijd toestaan voert de aanroep uit en bewaart een regel op de taak: voor de hele tool bij bestands- en computeracties, beperkt tot het programma van het commando (het eerste token) bij run_command — npm run build goedkeuren keurt toekomstige npm-commando's vooraf goed, niet de hele shell — en beperkt tot die ene doelagent bij message_agent. De regels staan in de sectie Automatische beoordeling van het tabblad Agent en kunnen daar worden verwijderd.
• Weigeren wijst de aanroep af. Het model krijgt te horen dat de gebruiker de actie heeft geweigerd en die niet ongewijzigd opnieuw mag proberen; de uitvoering gaat met dat antwoord verder.

Een openstaande goedkeuring geeft ook een melding (in de app, en web push wanneer die aanstaat), omdat de uitvoering al minuten onbewaakt bezig kan zijn wanneer ze de poort bereikt. Beslist niemand binnen vijf minuten, dan verloopt het verzoek, wordt de actie niet uitgevoerd en eindigt de uitvoering als Invoer nodig met een normale overdracht in plaats van haar budget af te wachten.

Goedkeuringen bewaken acties, niet zichtbaarheid: write_file en de alleen-lezen tools blijven onbewaakt, en elke beslissing komt in het beveiligingsauditlogboek terecht.

Taakstatus begrijpen

De interface brengt duurzame backendstatussen terug tot een kleinere set voor gebruikers:

Interfacestatus	Backendstatus	Kleur van indicator
Inactief	idle	rgb(255, 255, 255)
Denken	preparing of running	rgb(48, 121, 255)
Voltooid	completed	rgb(76, 212, 117)
Invoer nodig	needs_input of cancelled	rgb(255, 204, 0)
Fout	failed	rgb(255, 61, 129)

Een actieve uitvoering stoppen verandert de status in Invoer nodig en behoudt de bestanden. Ook het uitputten van het veiligheidsbudget voor ronden of toolaanroepen eindigt na de laatste overdracht zonder tools in Invoer nodig, zodat onvoltooid werk nooit als Voltooid wordt gemarkeerd.

Een actieve uitvoering vergrendelt het gesprek niet: een bericht dat je tijdens het werk verstuurt komt direct in het gesprek en bereikt het model bij de volgende ronde. Zo kun je bijsturen, corrigeren of context toevoegen zonder te stoppen; de stopknop blijft naast verzenden beschikbaar.

De werkruimte aanpassen

Op het desktopbreekpunt xl delen Gesprek en Werkruimte een versleepbare scheiding:

• De standaardbreedte van het gesprek is 45%.
• Het voorkeursbereik is 30% tot 70%, binnen minimale inhoudsbreedten.
• De opgeslagen verhouding geldt voor de aangemelde gebruiker in die browser.
• Pijltoetsen verplaatsen de scheiding 2%; houd Shift ingedrukt voor 10%.
• Home en End kiezen het beschikbare minimum en maximum.
• Enter of dubbelklikken herstelt de scheiding.

De bediening volgt de actieve schrijfrichting. In het Arabisch staat Gesprek rechts en Werkruimte links; aanpassen met aanwijzer en pijltoetsen blijft in de verwachte visuele richting werken.

Gebruik op kleinere schermen de bediening Gesprek/Werkruimte in de taakkop om van oppervlak te wisselen.

Bestanden

Het tabblad Bestanden bekijkt rechtstreekse kinderen van /workspace, opent alleen geldige UTF-8-tekstbestanden en slaat wijzigingen terug op in het taakvolume. Ongeldige bytereeksen worden geweigerd in plaats van verliesgevend door tijdelijke tekens te worden vervangen.

De editor biedt:

• syntaxismarkering in lichte en donkere modus voor gangbare web-, systeem-, script-, gegevens- en opmaaktalen;
• Cmd/Ctrl+S om op te slaan;
• Shift+Alt+F om ondersteunde bestanden op te maken;
• optimistische detectie van opslagconflicten, zodat een oudere editorweergave een inmiddels gewijzigd bestand niet stil overschrijft;
• niet-opgeslagen concepten per taak en pad in de sessieopslag van de browser; en
• navigatiewaarschuwingen zolang een niet-opgeslagen bewerking openstaat.

Live markering pauzeert boven 8,000 tekens of 400 regels om de editor responsief te houden. Opmaak is beschikbaar tot 100,000 tekens en 4,000 regels voor JavaScript/JSX, TypeScript/TSX, JSON-varianten, CSS/SCSS/Less, HTML, Markdown/MDX en YAML.

Wanneer het model een geopend bestand wijzigt, opent Bestanden een rood/groene weergave Wijzigingen met precies wat sinds het begin van de beurt is toegevoegd en verwijderd; lange ongewijzigde stukken worden samengevouwen. Een schakelaar wisselt tussen diff en editor en de tellers +added −removed vatten de beurt samen. De vergelijkingsbasis is de laatste inhoud die je browser vóór de beurt zag; bestanden die pas erna worden geopend tonen geen diff.

Browserconcepten zijn gemakstoestand, geen back-up. Ze worden gewist na succesvol opslaan of verwijderen van de taak en verdwijnen normaal wanneer de browsersessie eindigt.

Activiteit

Het tabblad Activiteit toont toolaanroepen, resultaten, bestandsbewerkingen, opdrachtuitvoer en fouten. Toolmetagegevens kunnen in het gesprek worden uitgevouwen. Opdracht- en tooluitvoer worden van links naar rechts getoond, ook in een interface van rechts naar links.

Tijdens een actieve uitvoering opent Libre WebUI een geverifieerde server-sent-eventsstroom en toont voortgang zodra de backend deze ontvangt. De stroom kan bevatten:

• een eerste snapshot en latere wijzigingen van run_state;
• reasoning_delta wanneer de provider redenering expliciet toont;
• tekst als assistant_delta;
• activiteit tool_call en tool_result;
• metingen usage;
• meldingen skill_loaded voor door de server geleverde workerhulp; en
• afsluitende gebeurtenissen error of done.

Beschikbaarheid en detail van redenering hangen af van model en provider. Libre WebUI toont alleen redenering die de provider via de API retourneert; verborgen chain-of-thought kan niet worden teruggehaald en sommige modellen leveren geen redeneerstroom. Assistenttekst en toolactiviteit blijven waar ondersteund onafhankelijk streamen.

Uitvoer is bewust begrensd. Een afgekapt resultaat bewijst niet dat een opdracht niets meer uitvoerde; vraag het model een smaller resultaat te bekijken of een gerichtere opdracht uit te voeren.

Git

Het tabblad Git biedt lokale bronbeheerbewerkingen voor het eigen /workspace van de taak:

• een repository initialiseren met tak main;
• porcelain-status, ahead/behind-aantallen en maximaal 20 recente commits bekijken;
• een begrensde tekstuele diff voor een gewijzigd pad bekijken;
• maximaal 200 expliciet geselecteerde paden tegelijk stagen;
• gestagede wijzigingen committen met gebruikersnaam en e-mailadres van de aangemelde beheerder, of een lokaal no-reply-adres als het account geen e-mail heeft;
• na de eerste commit een lokale tak maken; en
• naar een bestaande lokale tak wisselen wanneer de worktree schoon is.

Dit oppervlak is bewust alleen lokaal. Het bevat geen bediening voor clone, fetch, pull, push, extern beheer, willekeurige Git-opdrachten, tokens, SSH-sleutels of pull requests. Daarvoor is een afzonderlijke vertrouwde referentiebroker nodig, bij voorkeur een GitHub App of gelijkwaardig installatietoken dat tot één repository en bewerking is beperkt. Plaats geen langlevende Git-referenties in /workspace, de containeromgeving of repositoryconfiguratie.

Git-leesbewerkingen kunnen bij een inactieve of actieve taak draaien. Git-schrijfbewerkingen worden geweigerd zolang een modeluitvoering, interactieve terminal of voorbeeld de taakcontainer bezit. Van tak wisselen vereist bovendien een schone worktree. Zo strijden interface, model en langlopend proces niet om dezelfde bestanden.

Elke Git-opdracht in de interface is een vaste argumentenarray die als UID/GID 1000:1000 in de taakcontainer draait; gebruikersinvoer wordt nooit door een shell geëvalueerd. Voor dit oppervlak schakelt de runtime systeem-/globale Git-configuratie, prompts, hooks, referentiehelpers, commitondertekening, submodulerecursie, externe diffdrivers, textconv en netwerkprotocollen uit. Repositories waarvan worktree niet exact /workspace is of Git-/common-map buiten /workspace valt worden geweigerd. Git-schrijfacties die bestandsinhoud kunnen verwerken worden ook geblokkeerd als een uitvoerbaar clean-, smudge- of processfilter is ingesteld.

Deze controles beschermen de Libre WebUI Git-API. Een beheerder kan via Terminal en het model via run_command nog gewone Git-opdrachten in de sandbox uitvoeren. Sandbox en implementatiegrens blijven dus de beveiliging voor willekeurige opdrachten.

Ingebouwde workervaardigheden

Elke uitvoering krijgt een werkruimtegids van de server. Die legt de duurzame grens /workspace, alleen-lezen containerroot, tijdelijke proces- en /tmp-status, netwerkbeleid, opdracht- en uitvoerlimieten en de levenscyclus van voorbeelden uit. Ingebouwde vaardigheden sturen het model om:

• projectinstructies, manifesten, lockfiles, scripts en huidige repositorystatus vóór bewerking te bekijken;
• niet-gerelateerd werk te behouden en onafhankelijke lees- of zoekbewerkingen te bundelen;
• door te gaan met implementatie in plaats van na een plan te stoppen;
• gerichte verificatie vóór bredere controles uit te voeren;
• een fout te diagnosticeren in plaats van blind opnieuw te proberen; en
• de toepassing te verifiëren voordat het voorbeeld als laatste langlopende proces start.

De gids bestaat alleen in modelcontext. Libre WebUI maakt geen AGENTS.md, vaardigheidsmap of ander besturingsbestand in de gebruikerswerkruimte. Projectinstructies blijven projecthulp en kunnen de container- of toolbeveiligingsgrens niet overschrijven.

Terminal

Het tabblad Terminal koppelt een interactieve shell aan dezelfde sandboxcontainer waarin het model werkt, zodat een beheerder status kan bekijken, handmatig een build kan uitvoeren of achtergelaten werk kan onderzoeken zonder de browser te verlaten.

De shell volgt exact hetzelfde containerbeleid als elke modeltool: gebruiker 1000:1000 zonder rechten, werkmap /workspace, in de reeds beveiligde container zonder mogelijkheden. Een terminal geeft geen recht dat run_command niet al heeft — het is een menselijke interface naar dezelfde grens, geen omweg.

Operationeel gedrag:

• Verificatie — de browser wisselt zijn gewone Authorization-header via HTTP om voor een kortlevend, eenmalig ticket dat aan het Work-terminalprotocol en de exacte taak is gebonden. Alleen ticket en taak-ID staan op de upgrade-URL /ws/work-terminal. Voor elke shellinvoer controleert Libre opnieuw accountstatus, Work-toegang, bestaan en eigendom van de taak. Intrekking sluit de shell en geeft de runtimelease direct vrij.
• Oorsprongscontroles — wanneer CORS_ORIGIN of BASE_URL is ingesteld, moeten browserupgrades overeenkomen met een van die oorsprongen. Stel minstens één in voor externe implementaties. Oorsprongloze upgrades blijven beschikbaar voor Electron en niet-browserclients, maar vereisen hetzelfde taakgebonden ticket en live autorisatie; beheer ze met TLS, firewall en reverse-proxybeleid.
• Toelating — een open terminal neemt net als opdracht of voorbeeld een runtimelease en telt mee voor WORK_MAX_ACTIVE_RUNTIMES_*.
• Containerduur — een gekoppelde terminal houdt de container actief en voorkomt stoppen wegens inactiviteit tijdens de sessie.
• Gelijktijdigheid — WORK_TERMINAL_MAX_SESSIONS_PER_TASK (standaard 2) begrenst shells per taak.
• Time-out bij inactiviteit — WORK_TERMINAL_IDLE_TIMEOUT_MS (standaard 15 minuten) sluit een onaangeraakte sessie en geeft de lease vrij.
• Tijdens een actieve uitvoering — het tabblad legt uit dat het model de container bezit en opent de shell wanneer de beurt eindigt.

De terminal spreekt rechtstreeks met de Docker Engine-API, omdat een TTY-sessie een overgenomen bidirectionele stroom vereist die de Docker CLI alleen aan een echte besturingsterminal geeft. Deze gebruikt WORK_DOCKER_SOCKET, anders DOCKER_HOST — een unix://-socket of HTTP zonder TLS via tcp://, zoals een socketproxy waarvan HTTP-bewuste doorsturing de stroom door een standaardtunnel Connection: Upgrade voert — en anders /var/run/docker.sock. Een niet-ondersteunde DOCKER_HOST (ssh://, of tcp:// met DOCKER_TLS_VERIFY) meldt de terminal met reden als niet beschikbaar in plaats van elders aan te koppelen; de rest van Work blijft werken. Op Kubernetes loopt dezelfde sessie als TTY-WebSocket via de exec-subresource van de API-server, inclusief resizeframes en zonder Docker-eindpunt.

Terminalsessies zijn interactief en worden niet opgenomen. Opdrachten verschijnen niet in de tijdlijn Activiteit.

Voorbeeld

Het tabblad Voorbeeld start, stopt, sluit in en opent de gegenereerde webtoepassing. Bij een leeg opdrachtveld inspecteert Libre WebUI de werkruimte en:

• voert een dev-script in de hoofd-package.json uit met vereiste host en poort;
• serveert een hoofd-index.html met een meegeleverde statische server zonder afhankelijkheden; of
• gebruikt dezelfde regels voor één app in een geneste map.

Hoofdtoepassingen hebben voorrang. Bij meerdere even waarschijnlijke geneste apps of zonder ondersteund ingangspunt retourneert Work een bruikbare fout in plaats van een niet-gerelateerde npm-opdracht. Voer voor andere indelingen of servers een aangepaste opdracht in vóór Voorbeeld starten. Aangepaste opdrachten starten in /workspace; neem zo nodig de relatieve map op, bijvoorbeeld cd apps/web && npm run dev -- --host 0.0.0.0 --port 4173. Een proces moet luisteren op 0.0.0.0 en de ingestelde WORK_PREVIEW_PORT. Work wacht maximaal 15 seconden tot de poort gereed is.

Het model kan het voorbeeld ook via start_preview starten. Alleen zo kan een model een proces actief achterlaten. Gewone run_command-aanroepen ruimen achtergronddescendants op wanneer de opdracht eindigt.

Scherm (de Work Computer)

Bekijk de volledige demonstratie: een echte, onbewerkte uitvoering (30x, daarna realtime) van een Work-agent die op zijn eigen scherm NASA-beeldgalerieën bekijkt, foto's kiest en vervolgens vanuit één prompt een interactieve Three.js-galerie bouwt en test.

Een taak waarvan het beleid Work Computer inschakelt krijgt een tabblad Scherm: een live venster op een virtuele desktop in dezelfde sandbox — vensterbeheer, dock en Chromium-browser op een scherm van 1280×800. Je kunt de agent volgen, muis en toetsenbord overnemen, naar computeraudio luisteren en taken voordoen. Het tabblad start de GUI-sessie op verzoek (niets draait totdat iemand kijkt) en koppelt een VNC-over-WebSocket-viewer.

Inschakelen kost één klik voor een beheerder: de Work-startpagina toont een kaart Work Computer met Inschakelen. Deze bouwt de meegeleverde GUI-image op de eigen Docker-daemon (de eerste build duurt enkele minuten) en maakt een gebruiksklaar beleid Work Computer — geen handmatige docker build of beleidsvelden. Achter een gefilterde Docker API-proxy is het build-eindpunt bewust geweigerd; haal de gepubliceerde image op de Docker-host op (ghcr.io/libre-webui/libre-work-computer, getagd als libre-work-computer:latest) of bouw hem daar vanuit deploy/work-computer/. Inschakelen slaat daarna de build over en maakt alleen het beleid. Taken met dit beleid moeten netwerktoegang hebben; het scherm wordt net als het voorbeeld via een op loopback gepubliceerde containerpoort bereikt.

Beveiligingsmodel: de VNC-server in de container luistert op localhost achter twee wachtwoorden per sessie — één alleen-lezen voor elke toegestane kijker en één met volledige bediening, uitsluitend voor de huidige houder van de overnamelease. De VNC-server maakt zo invoer van alle anderen zelf inert. De WebSocket-bridge is het enige bereikbare oppervlak, gepubliceerd op loopback van de Docker-host en nooit rechtstreeks blootgesteld. Elke viewer verifieert zich met een eenmalig ticket voor sessie en taak, hetzelfde mechanisme als Terminal; actuele Work-toegang wordt bij elke verbinding opnieuw gecontroleerd, zodat intrekking schermen onmiddellijk verbreekt. Maximaal vier gelijktijdige viewers kunnen kijken en kijken telt als taakactiviteit voor de inactiviteitscontrole.

Kijken en uitvoeren concurreren nooit: Scherm openen tijdens een uitvoering koppelt aan de eigen sandbox van die uitvoering, een bekeken scherm blokkeert de volgende uitvoering niet en de sessie overleeft het einde van een uitvoering — ook in teamimplementaties waar een afzonderlijk workerproces uitvoert. Het browserprofiel blijft in /workspace/.browser-profile, zodat aanmeldingen containerherstarts overleven.

Besturing door de agent: Work Computer voegt twee tools toe. computer_observe retourneert een volledig desktopscreenshot met cursorpositie, actieve vensteridentiteit, huidige browser-URL, of de pagina (in plaats van browserinterface) toetsenbordfocus heeft, een compacte beschrijving van het gefocuste element en een screenshothash. Semantische signalen komen van een DevTools-eindpunt op containerloopback en ontbreken bij oudere GUI-images. computer_act voert een batch van maximaal 24 muis- en toetsenbordacties uit (verplaatsen, klikken, dubbelklikken, rechtsklikken, typen, toetscombinaties, scrollen, wachten) en retourneert het gestabiliseerde screenshot.

Drie runtimebeveiligingen houden batches betrouwbaar: acties type/key kunnen een focus-verklaring hebben en mislukken veilig als het genoemde veld geen toetsenbordfocus heeft, zodat tekst niet stil in de omnibox belandt; een batch stopt vroeg als een venster verschijnt, de titel verandert of focus halverwege verschuift, omdat resterende coördinaten voor het vorige scherm waren; en een batch kan een verwachte uitkomst (titel, URL of gewijzigd schermgebied) declareren die met adaptieve deadline wordt geverifieerd — „pending” betekent nog niet waargenomen, nooit verondersteld gelukt.

Na een batch stabiliseert het scherm adaptief door te pollen tot het niet meer verandert, niet na vaste vertraging. Elk resultaat bevat bewijs dat het model moet lezen: klikken op expliciete coördinaten melden of nabije pixels veranderden, scroll_until scrolt naar doeltekst of paginarand en meldt zichtbaarheid, en elke observatie wordt met de vorige vergeleken zodat een onveranderd scherm expliciet wordt genoemd. Batches kunnen een eenregelige subgoal als checkpoint bewaren en in herstelprompts herhalen. De agentcyclus herkent groundingstagnatie (drie identieke acties tegen een onveranderd scherm geven één herstelmelding; nog een herhaling beëindigt de uitvoering met een vraag om invoer in plaats van resterende ronden te verspillen) en oplopende dubbelzinnigheid (opeenvolgende niet-geverifieerde verwachtingen geven één melding om opnieuw te gronden). Cyclustelemetrie — ronden, toollatentie, screenshots, beveiligingen en verwachtingsuitspraken — wordt op elk duurzaam toolrecord gestempeld en aan het einde samengevat.

Screenshots bereiken het model als echte beeldinhoud op elke providerroute — Ollama, Anthropic, Gemini en OpenAI-compatibele chat- en Responses-plugins — dus gebruik bij voorkeur een visionmodel. Als de provider beeldinvoer weigert (een tekstmodel), mislukt de uitvoering niet: screenshots worden voor de rest van de uitvoering weggelaten, het model moet op tekstobservaties vertrouwen en een transcriptnotitie legt de beperking uit. Een model zonder zicht verifieert veel minder, dus kies vision voor computertaken. Alleen recente screenshots blijven in live modelcontext; duurzame taaktranscripten bewaren alleen tekstobservatie, nooit beeldbytes.

De browser bevat ingebouwde inhoudsblokkering — uBlock Origin Lite voor advertenties en trackers (vastgezet en via checksum gecontroleerd bij de imagebuild, filtermodus via beheerd beleid vastgezet) en automatische sluiting van cookie-toestemmingsbanners — omdat advertenties en toestemmingsmuren screenshots, tokens en klikken verspillen. Advertentieverzoeken worden in uBlock-stijl geneutraliseerd: bekende advertentiescripts worden onschadelijke lokale stubs, zodat pagina's blijven werken. De agent krijgt opdracht nooit referenties in te voeren of CAPTCHA-/2FA-uitdagingen te voltooien en meldt de blokkade. Combineer voor niet-vertrouwde taken GUI-beleid met een filterende DNS-resolver; een desktopbrowser maakt uitgaand netwerkbeleid belangrijker, niet minder.

Audio: Scherm is standaard gedempt (browserregel: audio vereist een klik); de luidsprekerknop streamt computergeluid live. PulseAudio speelt in de sandbox naar een null sink, waarvan de monitor als onbewerkte PCM wordt vastgelegd en via een tweede geverifieerde, op loopback gepubliceerde WebSocket-bridge wordt geleverd — met hetzelfde ticket, toegangscontrole en viewermaximum. Vereist een GUI-image die in deze of latere versie vanuit deploy/work-computer/ is gebouwd.

Overname: Overnemen geeft je muis en toetsenbord voor aanmelden, CAPTCHA of een stap die de agent niet mag doen; Ik ben klaar geeft het scherm terug. Eén VNC-sessie bedient beide rollen: de server bewaart een volledig en alleen-lezen wachtwoord (per sessie gegenereerd, nooit gelogd), kijkers krijgen alleen leeswachtwoord en de bedieningsleasehouder exclusief het volledige wachtwoord. De lease heeft een TTL (verlaten overname vervalt binnen twee minuten), wordt vernieuwd zolang de interface openstaat en kan niet van een ander worden afgepakt.

Beleid kan overname volledig uitschakelen via Schermovername toestaan: Overnemen en Aanleren verdwijnen, het eindpunt weigert en request_takeover meldt dat niemand kan overnemen; kijken blijft werken. Tijdens menselijke bediening zijn computer_observe en computer_act geblokkeerd, zodat de agent niet tegenwerkt of vastlegt wat je typt. De agent kan via request_takeover een banner met reden plaatsen en wachten tot je overneemt en teruggeeft. Referenties gaan rechtstreeks van toetsenbord naar pagina, nooit via model of transcript. Overname vereist een actuele image uit deploy/work-computer/; oudere sessies blijven zichtbaar maar voor iedereen alleen-lezen.

Aanleermodus: Een taak aanleren neemt een demonstratie op — jij bedient het echte scherm met zichtbare opname-indicator terwijl aanwijzer-, toetsenbord- en scrollacties op schermcoördinaten worden vastgelegd. Elke klik wordt ook verankerd: een alleen-lezen probe bepaalt tag, ID en zichtbaar label van het element en huidige pagina-URL. Stappen benoemen zo hun doel, bijvoorbeeld „Klik op "button#submit (Place order)"”, met coördinaten alleen als hint van de demonstratiepositie.

Opslaan bouwt het playbook deterministisch, zonder model in de lus: toetsaanslagen worden getypte reeksen, klik versus slepen gebruikt een drempel van 8 pixels, pauzes worden expliciete wachtstappen en tekst met geheime termen of referentievorm (8+ tekens uit drie tekenklassen) wordt geredigeerd en vervangen door request_takeover. Het playbook is een procedure in natuurlijke taal — eerst verankerde doelen, coördinaten als hints, opnieuw geïnterpreteerd met computer_observe — met gebruiksmoment, invoer, stappen, verificatie, toegestaan bereik afgeleid uit werkelijk bezochte hosts (afspelen moet stoppen en vragen vóór het die verlaat; een aangeleerde procedure erft nooit meer bevoegdheid dan getoond), goedkeuringsgrenzen en stop-en-vraag-foutafhandeling.

Het playbook wordt als gewone vaardigheid opgeslagen (slugvoorvoegsel taught-) en verschijnt in Vaardigheden met versies, bewerking en delen. Work-uitvoeringen met computer laden ingeschakelde aangeleerde vaardigheden van de eigenaar in hun systeemprompt en tonen ze in de vaardighedenlijst; afspelen is een normale uitvoering waarvan het verzoek bij de procedure past. Na afloop bieden vaardigheidschips met één klik een beoordeling gelukt/mislukt die een gedateerde regel toevoegt aan Track record (nieuwste eerst, begrensd, elke regel een gewone vaardigheidsversie), zodat geschiedenis bij de procedure blijft. Typ geen echte wachtwoorden tijdens opname: demonstreer tot de aanmelding, sla op en laat request_takeover tijdens afspelen referenties verwerken.

Providers, routering en gegevensverstrekking

Ondersteunde providerroutes

Route	Validatie en gedrag
Lokale Ollama	Ollama moet gezond zijn en het exacte model moet toolondersteuning melden.
Ollama Cloud	Expliciet via Ollama gerouteerd; modellen met cloudachtervoegsel tonen de externe melding.
Voltooiings-/chatplugin	Plugin moet actief zijn, het exacte model vermelden en referenties voor de huidige beheerder hebben.
Anthropic-plugin	Gebruikt Works adapter voor Anthropic-berichten en toolgebruik.
Gemini-plugin	Gebruikt Works adapter voor Gemini-inhoud en functieaanroepen.
Andere compatibele plugins	Gebruiken de OpenAI-vorm voor berichten, tools en toolkeuze.

Providertype en plugin-ID staan zowel op taak als uitvoering. Een modelnaam kiest nooit zelf de route. Een plugin activeren met dezelfde modelnaam als Ollama kan een bestaande taak niet onderscheppen.

Wat een provider ontvangt

Per modelronde kan de geselecteerde provider ontvangen:

• de Work-systeemprompt;
• ingebouwde workervaardigheden en huidige runtimelimieten;
• maximaal de laatste 30 gebruikers-/assistentberichten, begrensd tot 256 KB;
• Work-tooldefinities;
• geschiedenis van assistenttoolaanroepen; en
• toolresultaten, mogelijk met directorylijsten, opgevraagde bestandsinhoud, zoekresultaten, opdrachtuitvoer en fouten.

Het benoemde volume wordt niet als geheel geüpload. Bestandsinhoud of opdrachtuitvoer uit een tool wordt wel deel van het modelgesprek en naar de provider gestuurd. Controleer bewaar-, trainings-, prijs- en gebruiksbeleid van externe providers voor gevoelige broncode.

Providerreferenties blijven op de Libre WebUI-backend, zowel implementatiebreed als per gebruiker. Ze worden voor backendmodelverzoeken gebruikt en nooit in de Work-container gemount.

Versleuteling van referenties op toepassingsniveau is geen versleuteling van de hele taak. Gesprekken, toolresultaten, opdrachtuitvoer en taakmetagegevens zijn gewone database-inhoud; werkruimtebestanden en afhankelijkheden zijn gewone bestanden in Docker-volume of Kubernetes-PVC. Gebruik hosttoegangscontrole en schijfversleuteling wanneer het dreigingsmodel versleuteling in rust vereist.

Melding over externe providers

Work behandelt pluginmodellen en Ollama-namen met :cloud of -cloud als extern. Selectie opent een sluitbare melding over gegevensstroom en meerdere factureerbare aanroepen. De voorkeur wordt per Libre WebUI-gebruiker onthouden.

Alle routes gebruiken hetzelfde budget WORK_MAX_AGENT_ROUNDS, standaard 48 ronden. Er is geen afzonderlijke pluginlimiet van 12. Het veiligheidsbudget voor toolaanroepen is het grootste van 128 of acht per ingestelde ronde. Bij uitputting vraagt Libre WebUI één laatste overdracht zonder tools over voltooid werk, controles, blokkades en resterende stappen. De uitvoering eindigt als Invoer nodig, niet met een ruwe limietfout of onterechte voltooiing. Een vervolguitvoering gaat in dezelfde duurzame werkruimte verder. Eén Work-uitvoering kan nog steeds veel factureerbare providerverzoeken doen.

Werkruimten in hostmappen (optioneel)

Op Docker is /workspace normaal een benoemd volume dat alleen voor de taak bestaat, zodat het model echte bestanden niet bereikt. Een Docker-implementatie kan een taak in plaats daarvan aan een echte hostmap binden. Kubernetes weigert hostmappen en gebruikt een taakeigen PVC.

Stel beide variabelen in en start de backend opnieuw:

WORK_HOST_WORKSPACES_ENABLED=true
WORK_HOST_WORKSPACE_ROOTS=/Users/you/Projects

WORK_HOST_WORKSPACE_ROOTS is een met : gescheiden lijst van roots; standaard de thuismap van de servergebruiker. Bij inschakeling verschijnt een optioneel veld Werkruimtemap op de Work-startpagina. Leeg laten behoudt het geïsoleerde volume.

Een pad moet absoluut zijn, bestaan, een map zijn en via symlinks binnen een ingestelde root uitkomen. Mappen .ssh, .gnupg, .aws, .config, .kube, .docker, .claude, .libre-webui en node_modules worden altijd geweigerd. Het bepaalde pad wordt opgeslagen en in de taakkop getoond, zodat zichtbaar blijft waar de taak werkt.

Dit verkleint de sandbox

Een hostwerkruimte laat het model echte bestanden lezen en schrijven; andere containerbeveiligingen — gebruiker zonder rootrechten, verwijderde mogelijkheden, resourcelimieten — staan niet langer tussen model en map. Laat dit uit tenzij gewenst, houd roots zo smal mogelijk en gebruik bij voorkeur versiebeheer.

Persistentie en runtimelevenscyclus

Libre WebUI scheidt duurzame status van uitvoeringsstatus:

Status	Opslag	Levensduur
Taakeigendom, titel, provider en status	Libre WebUI-database	Tot taak of eigenaar wordt verwijderd
Uitvoeringen, fouten, berichten en activiteit	Libre WebUI-database	Tot de taak wordt verwijderd
Werkruimtebestanden	Taakvolume van Docker of K8s-PVC	Overleven annuleren, voorbeeldstop en herstarts van sandbox en app
Rootbestandssysteem en tijdelijke bestanden	Taakcontainer of Pod	Vervangbaar; kan stoppen of opnieuw worden gemaakt
Voorbeeldproces	Actieve taaksandbox	Tijdelijk; alleen behouden zolang gezond geverifieerd
Niet-opgeslagen editorconcept	Browsersessieopslag	Tijdelijk gemak tijdens de browsersessie

Elke taak krijgt een server-UUID. Sandbox- en werkruimtenamen worden door de backend afgeleid en nooit uit browserverzoeken geaccepteerd. Resources krijgen beheerde en eigendomslabels. Vóór hergebruik of verwijdering wordt het eigendomslabel gecontroleerd; een resource van een andere taak wordt geweigerd.

Sandboxen worden op verzoek voorbereid. Bestandshelpers stoppen een verder inactieve sandbox, opdrachten stoppen na voltooiing en een gezond voorbeeld kan actief blijven voor inspectie. De duurzame werkruimte wordt bij herstart of vervanging opnieuw gemount.

Beheerders kunnen via het tabblad Gebruikersbeheer in Settings benoemd runtimebeleid maken: presets met runtime-image, geheugen-/CPU-/PID-limieten, Kubernetes-werkruimtegrootte, inactiviteitstime-out, netwerkstandaard en twee functieschakelaars. Work Computer (GUI + browser) geeft een virtuele desktop en Scherm; Schermovername toestaan bepaalt of mensen mogen overnemen en, omdat aanleren via overname opneemt, of aanleermodus bestaat. Een taak gebruikt het gekozen beleid; lege velden erven globale implementatiewaarden en verwijderen laat taken bij volgende containervervanging terugvallen op globaal. Beleid wijzigt alleen resources en functies — het beveiligingsprofiel (niet-root, alleen-lezen rootfs, mogelijkheden verwijderd, netwerkisolatie) kan per beleid niet worden verzwakt.

WORK_RUNTIME_IDLE_TIMEOUT_MS begrenst de tolerantie voor voorbeelden: wanneer ingesteld stopt een sweep sandboxen zonder activiteit — geen afgeronde opdracht, gekoppelde terminal of voorbeeldverzoek via ondertekende proxy — na zoveel milliseconden en geeft het toelatingsslot vrij. Stoppen is goedkoop en de werkruimte blijft. Standaard (0) behoudt huidig gedrag: voorbeelden draaien tot expliciet gestopt.

Bij backendstart worden actieve uitvoeringen mislukt gemarkeerd en voorbeeldstatus gewist; agentcyclus en proxy stierven met het proces. De driver vermeldt beheerde containers of Pods in één gelabelde query. Actieve sandboxen van bekende taken stoppen omdat een onderbroken opdracht zonder toezichthouder kan doorlopen; reeds gestopte blijven staan; beheerde sandboxen zonder taakrij worden verwijderd. Eigendom komt altijd uit het taaklabel, niet de resourcenaam. Opruimen veronderstelt één Libre WebUI-instantie per runtimenamespace of daemon. Richt geen twee instanties op dezelfde resources. Als opruimen niet bewezen kan worden blijft Work veilig gesloten, probeert elke 10 seconden opnieuw en blokkeert nieuwe wijzigingen tot runtimeherstel.

Netwerkgedrag

Controleer het geselecteerde netwerkbeleid

Taken zonder benoemd beleid beginnen met netwerk ingeschakeld. Een beheerder kan beleid met standaard uitgeschakeld netwerk maken en de maker kiest dit bij taakcreatie. Er is geen onafhankelijke netwerkschakelaar per taak; beleidswijziging vereist sandboxvervanging voordat die actief wordt.

Op Docker koppelen netwerktaken aan een speciale beheerde bridge (libre-webui-work standaard, WORK_NETWORK_NAME) met communicatie tussen containers uit (com.docker.network.bridge.enable_icc=false). Daardoor:

• kan een Work-sandbox geen andere Work-sandbox bereiken; en
• kan deze geen containers op de gedeelde standaardbridge bereiken, zoals een niet-bewust gepubliceerde database of Ollama-container.

Libre WebUI weigert een netwerktaak als een netwerk met de ingestelde naam bestaat maar niet het beheerde netwerk is, in plaats van stil aan een operatornetwerk te koppelen.

Op Kubernetes draagt de Pod hetzelfde netwerklabel. Helm installeert standaard-weigeren-NetworkPolicy, alleen-voorbeeld-ingress en internetegress voor netwerk-Pods, met uitsluiting van work.networkPolicy.blockedEgressCidrs. Dit werkt alleen wanneer de CNI NetworkPolicy afdwingt; zie Kubernetes.

Uitgaand verkeer blijft toegestaan voor pakketdownloads, externe Git en API's. Dit is geen uitgaande firewall. Code kan mogelijk bereiken:

• services op de Docker-host;
• systemen op het lokale hostnetwerk;
• internetdiensten; en
• infrastructuurmetagegevens, afhankelijk van implementatie.

Haken voor uitgaand beleid

Combineer voor een strengere grens:

• WORK_RUNTIME_DNS (Docker) — kommagescheiden IPv4-/IPv6-resolvers die via --dns op elke netwerk-sandbox worden afgedwongen. Een filterende resolver biedt naamgebaseerde toestaan-/weigerenlijsten. Niet-adressen worden geweigerd en gelogd, zodat geen Docker-vlaggen kunnen worden geïnjecteerd.
• Host- of upstreamfirewallregels (Docker) op het stabiele subnet van de beheerde bridge.
• WORK_NETWORK_NAME (Docker) naar een vooraf gemaakt netwerk met eigen driveropties — Libre WebUI vereist het beheerde label en ICC uit, dus maak het met beide.

DNS-filtering beperkt naamresolutie, niet direct IP-verkeer. Gegarandeerd geen direct-IP-egress vereist ook host-, cluster- of upstreamfirewallregels.

Veronderstel niet dat code in Work geen gegevens kan verzenden. Geef alleen vertrouwde gebruikers toegang. Gebruik benoemd offlinebeleid wanneer een taak offline moet starten; geen implementatiebrede omgevingsvariabele verandert de standaard.

Netwerktoegang voegt geen referenties toe. Libre WebUI mount geen SSH-sleutels, cloudreferenties, browserprofielen, thuismap of Docker-socket in taken. Code kan wel geheimen verzenden die gebruiker of model in /workspace schrijft.

Sandboxverkeer staat los van modelverkeer. Ollama- en pluginverzoeken gaan altijd vanuit de backend naar de expliciet gekozen providerroute.

Beveiligingsgrens van de sandbox

Een Docker Work-container:

• draait als niet-root UID/GID 1000:1000;
• gebruikt /workspace als werkmap;
• mount alleen het benoemde volume van de taak op /workspace;
• gebruikt een alleen-lezen rootbestandssysteem en begrensd tijdelijk /tmp;
• verwijdert alle Linux-mogelijkheden;
• schakelt no-new-privileges in;
• is niet privileged en gebruikt een initproces;
• past CPU-, geheugen-, proces-, opdrachtduur- en uitvoerlimieten toe;
• zet swap gelijk aan geheugen (--memory-swap gelijk aan --memory), zodat swap het geheugenmaximum niet omzeilt;
• koppelt aan het beheerde netwerk zonder onderlinge containercommunicatie, of aan geen netwerk; en
• publiceert alleen de voorbeeldpoort naar een door Docker toegewezen hostpoort op loopback.

Dit alles wordt vóór hergebruik via docker inspect gecontroleerd en gehasht in containerlabel ai.libre-webui.policy. Een container met beleid van vóór een upgrade wordt vernietigd en opnieuw gemaakt, zodat beveiligingswijzigingen bestaande taken bereiken.

Kubernetes past een gelijkwaardige Pod-securitycontext toe: niet-root UID/GID, alleen-lezen root, seccomp RuntimeDefault, geen privilege-escalatie, alle mogelijkheden verwijderd, begrensde tijdelijke opslag, resourcelimieten, geen ServiceAccount-token en taakeigen PVC op /workspace. Labels en beleidsvingerafdruk worden vóór hergebruik of verwijdering gecontroleerd.

Padvalidatie weigert absolute paden, traversalsegmenten, backslashes, NUL-tekens en te lange paden. Bestandshelpers bepalen echte paden en weigeren symlinkontsnapping. Schrijven gebruikt een tijdelijk bestand en atomische hernoeming.

Deze controles beperken onbedoelde hostblootstelling; ze maken Work geen virtuele machine of veilige malwareanalyseomgeving. Containers delen de hostkernel. Kwetsbaarheden in Docker, Kubernetes, runtime, image, afhankelijkheid of kernel kunnen de grens overschrijden.

Docker-volumes hebben geen onafhankelijke schijfquota. Projecten of pakketinstallaties kunnen Docker-opslag vullen; bewaak groei en pas hostlimieten toe. Kubernetes vraagt PVC-grootte; handhaving hangt af van de storageprovisioner.

Controlelijst voor Docker-productiebeveiliging

Deze lijst geldt voor Docker. Kubernetes-operators moeten ook namespace-RBAC, Pod-securitycontext, storageclass en CNI-handhaving van NetworkPolicy uit de Kubernetes-handleiding valideren.

De toepassing kan containervlaggen zetten, werkruimtepaden valideren en eigen API beveiligen. Ze kan geen hostfirewall, storagequota of privilegeniveau van de Docker-daemon afdwingen. Behandel dit als expliciet implementatiewerk.

1. Docker-besturing isoleren

De hoofdcontainer heeft daemonbesturing nodig om Work-containers te maken. Een gemounte socket is een besturingsreferentie, geen gegevensmount: compromittering van de webapp kan de Docker-host compromitteren.

docker-compose.socket-proxy.yml houdt de socket buiten Libre WebUI. Een proxy houdt /var/run/docker.sock op een intern netwerk en stuurt alleen gebruikte API-secties door — containers, images, volumes, netwerken, exec, info — terwijl swarm, secrets, configs, build, commit en systeem worden geweigerd. DOCKER_HOST=tcp://docker-socket-proxy:2375 verwijst Libre WebUI ernaar zonder socketmount of groepslidmaatschap; CLI, terminal en diagnose volgen dit. De proxy verkleint het oppervlak, niet de impact: wie containers kan maken kan hostpaden bind-mounten.

Gebruik voor sterkere productiebeveiliging een speciale VM zonder andere workloads. Sterker nog: een speciale rootless Docker-daemon of aparte runtimehost die alleen aan Libre WebUI wordt aangeboden. Test eigendom, voorbeeldroutering, opruimen en terminal. Dezelfde rootful socket alleen-lezen mounten maakt de API niet alleen-lezen.

2. Beheertoegang van sandbox naar host blokkeren

Uitgeschakelde onderlinge communicatie blokkeert andere sandboxen, niet hostservices. Inspecteer bridge en subnet:

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

Gebruik de permanente hostfirewall om verkeer van de bridge naar beheerservices te weigeren, vooral SSH, Docker API, databases en monitor-/beheerpoorten. Test vanuit een tijdelijke container op libre-webui-work, test toegestane downloads en maak regels duurzaam. DOCKER-USER beheert doorgestuurd verkeer; verkeer naar de host zelf kan ook een INPUT-/inputhookregel op de bridgeinterface vereisen.

3. Uitgaande bestemmingen beperken

Blokkeer cloudmetagegevens, privé-infrastructuur- en client-LAN-bereiken tenzij nodig. Combineer WORK_RUNTIME_DNS met host-/upstreamfirewall. Letterlijke IP's omzeilen DNS; een HTTP-proxy alleen is ook onvoldoende zolang opdrachten directe verbindingen openen. Dwing routering buiten de container af.

Onderhoud benoemd beleid voor verschillende clients, bijvoorbeeld offline, alleen pakketregisters en open egress. Beleid bepaalt netwerkkoppeling; firewall/proxy handhaven bestemmingen.

4. Echte opslagquota afdwingen

CPU-, geheugen-, swap- en PID-limieten begrenzen volumes niet. Kies voor meerdere clients opslag met quota per werkruimte, zoals XFS-projectquota, logische volumes met quota of volume-/PVC-driver met grootte. Docker local op gewone ext4 krijgt geen betrouwbare quota door alleen een grootte te documenteren.

Bewaak elk volume ai.libre-webui.managed=true en de Docker-dataroot, waarschuw vóór vol en test de foutmodus. Een UI-teller of periodieke du waarschuwt maar handhaaft niet; een container kan tussen controles de rest vullen.

5. Het geïmplementeerde beleid verifiëren

Maak na image- of daemonbeleidswijziging een tijdelijke Work-taak en controleer via docker inspect: niet-root UID, alleen-lezen root, mogelijkheden verwijderd, no-new-privileges, geheugen/swap/CPU/PID, alleen taakvolume en verwacht netwerk. Controleer ook mounts van Libre WebUI en dat openbare toegang via geverifieerde proxy/tunnel komt, niet per ongeluk via Docker- of voorbeeldpoort.

Beveiliging en bereikbaarheid van voorbeelden

Docker publiceert de voorbeeldpoort dynamisch op backendloopback; Kubernetes richt op de Pod-IP. Model en browser kiezen geen willekeurige upstream. Libre WebUI ondertekent een capability-URL voor exacte taak en eindpunt, controleert bij elk verzoek dat het voorbeeld draait en proxyt HTTP/WebSocket via /api/work/previews. Stoppen of herstarten trekt de oude URL in.

Antwoorden verwijderen Libre WebUI-referenties en upstreamcookies. HTML wordt beperkt door iframe-sandbox en CSP die scripts, formulieren, modals en downloads toestaat zonder same-origin. CSP beschermt ook een apart tabblad. Gegenereerde code blijft onbetrouwbaar en kan via egress alles uit werkruimte of browserinvoer verzenden. Behandel de URL als kortlevend geheim.

Omdat de browser de proxy op de openbare Libre WebUI-oorsprong laadt, werken externe browsers en HTTPS-proxy's zonder Dockerpoorten/Pod-IP's en mixed-content. Reverse proxy's moeten WebSocket-upgrades voor /api/work/previews/ behouden; de geleverde Nginx-configuratie doet dit.

De hoofdapp staat alleen eigen oorsprong en Cloudflare Turnstile als frames toe. Voorbeeldantwoorden omzeilen hoofd-Helmet zodat body’s kunnen streamen en smaller sandboxbeleid geldt. Cross-origin embedderbeleid blijft uit omdat devservers zelden passende headers leveren.

Implementatiematrix

Work-beschikbaarheid volgt machine en proces van de backend, niet alleen browser of desktopinterface.

Implementatie	Work-uitvoeringen en bestanden	Ingesloten voorbeeld
npx libre-webui lokaal	Ondersteund wanneer Docker is geïnstalleerd, actief en aanroepbaar door de backendgebruiker.	Via ondertekende proxy op toepassingsoorsprong.
Lokale bronontwikkeling	Ondersteund met dezelfde Docker- en providervereisten.	Via ontwikkel-API-oorsprong op poort 3001.
Electron-desktopclient	Voorwaardelijk. Electron gebruikt een externe Libre WebUI-backend en levert geen aparte Work-runtime.	Via ondertekende proxy-URL van die backend.
Bare-metal-/VM-backend op externe host	Uitvoeringen, bestanden en providers werken als Docker daar beschikbaar is.	Als openbare proxy HTTP en WebSocket behoudt.
Standaard Docker Compose uit repository	Standaard ondersteund op Docker Desktop: image bevat Docker CLI, Compose mount hostsocket en Work-poorten lopen via host.docker.internal. Native Docker Engine heeft daarnaast een bereikbare niet-publieke WORK_PREVIEW_BIND nodig.	Via dezelfde openbare Libre WebUI-oorsprong.
Huidige Kubernetes-/Helm-implementatie	Ondersteund met --set work.enabled=true: sandboxen als Pods met PVC's (uitvoeringen, bestanden, opdrachten, Git, terminals en Work Computer-scherm/audio op Pod-IP), namespace-Role en standaard-weigeren-NetworkPolicies — nergens een Docker-socket. Zie Kubernetes.	Backend in het cluster richt ondertekende proxy rechtstreeks op Pod-IP.

Work uitvoeren wanneer Libre WebUI zelf in Docker draait

Elk Compose-bestand in de repository schakelt Work in: image bevat Docker CLI en Compose mount /var/run/docker.sock. Docker Desktop werkt met de meegeleverde routeringsstandaarden. Native Docker Engine heeft daarnaast WORK_PREVIEW_BIND nodig op een niet-publieke hostinterface die vanuit zustercontainers bereikbaar is, zoals hieronder beschreven.

Work bestuurt de hostdaemon via de socket; taakcontainers zijn siblings van Libre WebUI, geen kinderen. Ze staan in docker ps en volgen dezelfde levenscyclus.

Een Docker-socket in een webapp geeft root-equivalente hostbesturing. Work kan zonder niet werken, dus Libre WebUI schakelt het in in plaats van stil niets te doen. Gevolg: elke Libre WebUI-beheerder is feitelijk Docker-hostbeheerder. Operators dragen verantwoordelijkheid voor daemonbeveiliging, netwerk, levenscyclus, back-up en toegang. Verwijder /var/run/docker.sock uit Compose om Work uit te schakelen; niets anders hangt ervan af.

Gebruik docker-compose.socket-proxy.yml om Work zonder socket in de webapp te houden. De proxy bezit de socket en stuurt gebruikte secties door via DOCKER_HOST. Zie Docker-besturing isoleren.

Drie voorwaarden moeten gelden; Work noemt de mislukte:

1. Docker CLI moet bestaan. De officiële image bevat deze; een aangepaste image vereist docker-cli of WORK_DOCKER_COMMAND. Anders: The "docker" CLI is not installed….
2. De socket moet gemount zijn. Anders: No Docker daemon is reachable….
3. De backendgebruiker moet in de socketgroep zitten. De image draait als nodejs (uid 1001), socket meestal root of docker, dus Compose gebruikt group_add: ['${DOCKER_GID:-0}']. Standaard past bij Docker Desktop; Linux vereist eigen groeps-ID. Anders: 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

Voorbeeldpoorten blijven op hostloopback. Libre WebUI biedt elk voorbeeld via ondertekende same-origin proxy-URL met HTTP en WebSocket. Dit werkt achter HTTPS/tunnels zonder poorten te openen; sandboxbeleid geldt en stoppen/herstarten trekt de URL in.

Wanneer de backend in Docker draait, kunnen publicatie en verbinding andere adressen gebruiken. Houd WORK_PREVIEW_BIND=127.0.0.1 en stel WORK_DOCKER_PUBLISHED_HOST in op een vanuit de backend bereikbare host (host.docker.internal op Docker Desktop). De meegeleverde Compose-profielen stellen beide waarden in en koppelen de hostnaam. Linux moet WORK_PREVIEW_BIND overschrijven met de Docker-bridge-gateway (of een andere expliciet bereikbare, niet-openbare hostinterface); alleen hostmapping maakt hostloopback niet bereikbaar. Bind deze ruwe tijdelijke poorten nooit aan 0.0.0.0.

Gelijktijdigheid is apart begrensd: WORK_MAX_ACTIVE_RUNTIMES_PER_USER standaard 2, WORK_MAX_ACTIVE_RUNTIMES_GLOBAL 3, zodat een tweede taak kan draaien. Het capabilities-antwoord meldt limieten en bezetting. Verhoog alleen bij voldoende geheugen/CPU.

Installeer Kubernetes met work.enabled=true, niet met een nodesocket. De chart maakt RBAC, namespace, netwerkbeleid en Pod/PVC uit Kubernetes.

Runtimeconfiguratie

Work leest deze variabelen in het backendproces:

Variabele	Standaard	Doel
WORK_RUNTIME_BACKEND	docker	Sandboxdriver: docker of kubernetes
WORK_RUNTIME_IMAGE	node:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3	Image voor taaksandboxen
WORK_DOCKER_COMMAND	docker	CLI-uitvoerbaar bestand van Docker-backend
WORK_COMMAND_TIMEOUT_MS	120000	Standaardtime-out voor opdrachten
WORK_MAX_OUTPUT_CHARS	50000	Maximale vastgelegde opdracht-/zoekuitvoer
WORK_MAX_AGENT_ROUNDS	48	Provideronafhankelijk model-/toolrondenbudget per uitvoering
WORK_MEMORY_LIMIT	2g	Geheugenlimiet per container
WORK_CPU_LIMIT	2	CPU-limiet per container
WORK_PIDS_LIMIT	256	Proceslimiet per container
WORK_PREVIEW_PORT	4173	Poort waarop app in container moet luisteren
WORK_PREVIEW_BIND	127.0.0.1	Hostinterface waarop voorbeeld wordt gepubliceerd
WORK_DOCKER_PUBLISHED_HOST	hetzelfde als WORK_PREVIEW_BIND	Host/IP die backend gebruikt voor Docker-gepubliceerde Work-poorten
WORK_COMPUTER_SCREEN_PORT	6080	WebSocket-poort van schermbridge in container
WORK_COMPUTER_AUDIO_PORT	6081	WebSocket-poort van audiobridge in container
WORK_RUN_LEASE_WAIT_MS	60000	Wachttijd op tijdelijke houder van runtimelease
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL	3	Gelijktijdige containertaken per Libre WebUI-instantie
WORK_MAX_ACTIVE_RUNTIMES_PER_USER	2	Gelijktijdige containertaken per beheerder
WORK_MAX_TASKS_GLOBAL	500	Duurzame Work-taken per Libre WebUI-instantie
WORK_MAX_TASKS_PER_USER	100	Duurzame Work-taken per beheerder
WORK_NETWORK_NAME	libre-webui-work	Beheerde bridge voor netwerktaken
WORK_RUNTIME_DNS	niet ingesteld	Kommagescheiden resolver-IP's voor netwerktaken
WORK_DOCKER_SOCKET	DOCKER_HOST als unix:// of tcp://, anders /var/run/docker.sock	Docker Engine-eindpunt voor interactieve terminals
WORK_TERMINAL_MAX_SESSIONS_PER_TASK	2	Gelijktijdige terminals per taak
WORK_TERMINAL_IDLE_TIMEOUT_MS	900000	Inactiviteitstime-out voor terminalsessie
WORK_RUNTIME_IDLE_TIMEOUT_MS	0 (uitgeschakeld)	Stop sandbox na inactiviteit (ook voorbeelden)
WORK_K8S_NAMESPACE	libre-webui-work	Namespace voor Kubernetes-Pods/PVC's
WORK_K8S_STORAGE_CLASS	clusterstandaard	StorageClass voor Kubernetes-werkruimte-PVC's
WORK_K8S_WORKSPACE_SIZE	5Gi	Standaard PVC-grootte per taak
WORK_K8S_POD_READY_TIMEOUT_MS	900000	Maximale wachttijd op gereedheid van sandbox-Pod
WORK_K8S_POD_GONE_TIMEOUT_MS	60000	Maximale wachttijd tot verwijderde Pod verdwenen is

Gebruik in productie een vaste imageversie of digest. Een veranderlijke tag kan opdrachtregeltools en beveiligingsgrens veranderen zonder wijziging van Libre WebUI.

Uitvoering, voorbeeld, bestandshelper, opdracht en sandboxvervanging delen dezelfde capaciteitsboekhouding in het proces. Geneste bewerkingen op een al getelde taak tellen niet opnieuw. Verzoeken boven taak- of runtimelimiet retourneren HTTP 429.

Vaste protocol- en interfacelimieten

Item	Limiet
Nieuw taak- of uitvoeringsbericht	65,536 tekens en UTF-8-bytes
Model-ID bij maken/bijwerken taak	500 tekens en UTF-8-bytes
Pluginprovider-ID	200 tekens
Actieve uitvoeringen per taak	1
Opdrachttekst	20,000 tekens
Door tool gevraagde opdrachttime-out	1 tot 600 seconden
Gereedheid voorbeeld	15 seconden
Bestand lezen/schrijven	2,000,000 bytes UTF-8-tekst
Directe directorylijst	Eerste 1,000 vermeldingen
Berichtenpagina	Maximaal 200 berichten en 1,000,000 bytes
Duurzaam individueel bericht	100 KB
Gesprekscontext naar model	Laatste 30 gebruikers-/assistentberichten, maximaal 256 KB
Duurzame tooluitvoer	Ongeveer 20,000 brontekens plus markering
Live editormarkering	8,000 tekens en 400 regels
Opmaak in browser	100,000 tekens en 4,000 regels
Git-statusuitvoer	2,000,000 vastgelegde tekens
Git-diffuitvoer	600,000 vastgelegde tekens
Git-geschiedenis	20 lokale commits
Paden in één Git-stageverzoek	200
Git-commitbericht	4,000 tekens
Agentcyclus, elke providerroute	Standaard 48 ronden, ingesteld via WORK_MAX_AGENT_ROUNDS
Veiligheidsbudget toolaanroepen	max(128, configured rounds × 8) aanroepen

Bestandstoegang is voor UTF-8-tekst. De editor is geen binaire editor en bestanden groter dan 2 MB kunnen niet via de Work-bestands-API worden geopend.

API-overzicht

Alle eindpunten staan onder /api/work en vereisen verificatie plus actuele Work-toegang uit de database. Work is standaard alleen voor beheerders; een beheerder kan gewone taakbewerkingen voor actieve gebruikers openen. Hostmapselectie en beheerdersbeleid/-toegang blijven alleen voor beheerders.

Methode	Pad	Doel
GET	/capabilities	Beschikbaarheid en limieten van runtime/provider
GET	/tasks	Taken van huidige beheerder vermelden
POST	/tasks	Taak en eerste asynchrone uitvoering maken
GET	/tasks/:id	Taakstatus en recente berichten laden
GET	/tasks/:id/messages	Oudere berichten pagineren
PATCH	/tasks/:id	Hernoemen of expliciete modelroute wijzigen
DELETE	/tasks/:id	Taak en duurzame werkruimte verwijderen
POST	/tasks/:id/runs	Vervolguitvoering starten
POST	/tasks/:id/messages	Agent tijdens actieve uitvoering berichten
GET	/tasks/:taskId/runs/:runId/events	Live gebeurtenissen geverifieerd via SSE streamen
POST	/tasks/:id/cancel	Actieve uitvoering annuleren
GET	/tasks/:id/approvals	Openstaande goedkeuringen plus de status van Automatische beoordeling
PUT	/tasks/:id/approvals	Goedkeuringen per taak in- of uitschakelen
POST	/tasks/:id/approvals/:approvalId	Een openstaande goedkeuring beslissen (eenmalig/altijd toestaan, weigeren)
DELETE	/tasks/:id/approval-rules/:ruleId	Een Altijd-toestaan-regel verwijderen
GET	/computer/setup	Installatiestatus Work Computer (beheerder)
POST	/computer/setup	GUI-image bouwen en beleid maken (beheerder)
POST	/tasks/:id/computer/start	Work Computer-sessie starten
GET	/tasks/:id/computer/control	Schermbestuurder; overnameverzoek van agent
POST	/tasks/:id/computer/control	Scherm overnemen of bediening vernieuwen
DELETE	/tasks/:id/computer/control	Scherm aan agent teruggeven
POST	/tasks/:id/computer/teach	Opgenomen demonstratie als vaardigheid opslaan
POST	/tasks/:id/computer/anchor	Element onder opgenomen klik bepalen
POST	/computer/skills/:slug/trace	Gelukt/mislukt-regel aan vaardigheid toevoegen
GET	/tasks/:id/files	Werkruimtemap vermelden
GET	/tasks/:id/file	Tekstbestand lezen
PUT	/tasks/:id/file	Tekstbestand opslaan
GET	/tasks/:id/git	Beveiligde lokale Git-status/geschiedenis lezen
GET	/tasks/:id/git/diff	Begrensde lokale diff lezen
POST	/tasks/:id/git/init	Lokale Git initialiseren
POST	/tasks/:id/git/stage	Expliciete werkruimtepaden stagen
POST	/tasks/:id/git/commit	Gestagede wijzigingen committen
POST	/tasks/:id/git/branches	Lokale tak maken
POST	/tasks/:id/git/switch	Naar bestaande schone lokale tak wisselen
POST	/tasks/:id/preview/start	Beheerd voorbeeld starten
POST	/tasks/:id/preview/stop	Beheerd voorbeeld stoppen

De taak-ID wordt altijd tegen de geverifieerde eigenaar gecontroleerd. Accountstatus, rol en Work-toegangsbeleid worden per verzoek uit de database gelezen, zodat intrekking ook werkt bij een ouder JWT met verouderde rolclaims.

Het taakupdateschema behoudt intern een veld networkEnabled voor compatibiliteit. De Work-interface toont geen onafhankelijke schakelaar. Selecteer bij taakcreatie benoemd beleid met de gewenste netwerkstandaard; gebruik het ruwe veld niet als duurzame configuratie-API.

Verwijderen, accountwijzigingen en back-up

Een taak verwijderen

Een taak verwijderen is bewust destructief:

1. De backend markeert de taak als uitfaserend, zodat geen wijzigende bewerking kan starten.
2. Een actieve uitvoering wordt geannuleerd en de sandbox gestopt.
3. Libre WebUI valideert eigendomslabels op runtimeresources.
4. Container/Pod en benoemd volume/PVC worden verwijderd.
5. De databasetaak wordt verwijderd, met cascaderende uitvoeringen en berichten.
6. Browserconcepten worden na succes van de API gewist.

Als runtimeopruiming mislukt, behoudt Libre WebUI de databaserij en retourneert een fout, zodat Docker of Kubernetes kan worden hersteld en opnieuw geprobeerd. Metagegevens worden niet stil verwijderd terwijl een niet-gevolgde sandbox of werkruimte achterblijft.

Een uitvoering of voorbeeld stoppen is anders: uitvoering stopt, volume en gesprek blijven.

Een beheerder degraderen en een gebruiker verwijderen

Bij degradatie slaat Libre WebUI de rolintrekking op vóór afhankelijkheid van runtimeopruiming. Elk later Work-verzoek controleert rol en toegangsmodus. De backend schort taken op wanneer de nieuwe rol geen toegang heeft en probeert actieve uitvoeringen en sandboxen te stoppen. Bij mislukte opruiming blijft toegang ingetrokken en meldt de rolupdate de fout, zodat een operator kan herstellen en opnieuw proberen.

Een andere gebruiker verwijderen ruimt eerst alle beheerde Work-resources op. Als externe opruiming mislukt, blijft de gebruikersrij behouden, zodat eigendomsmetagegevens niet verloren gaan en opnieuw proberen veilig blijft.

Een volledige taak back-uppen

Een volledige Work-back-up vereist:

• de Libre WebUI-database met eigendom, Docker-/Kubernetes-resourcenamen, providerroutering, uitvoeringen, berichten en activiteit; en
• elk Docker-volume of Kubernetes-PVC met ai.libre-webui.managed=true, dat Work-bestanden bevat.

Tijdelijke containers en voorbeeldprocessen hoeven niet. Stop nieuwe Work-activiteit en backend voor een consistente opname en volg de procedure van Docker-volume of Kubernetes-storageprovider.

Herstel database en passende werkruimten samen. Maak elk volume/PVC onder exact de databasenaam en herstel eigendomsmetagegevens ai.libre-webui.task=<task UUID> en ai.libre-webui.managed=true. Alleen bestanden kopiëren behoudt labels niet. Alleen database geeft taken zonder bestanden; alleen opslag verliest eigendom en gegenereerde namen die Libre WebUI voor vinden en valideren gebruikt.

Volg bij versleutelde providerreferenties ook de hoofdhandleiding voor gegevensmap en versleutelingssleutel.

Lokalisatie en Arabische RTL

De volledige Work-interface is vertaald in alle 25 ondersteunde talen: Engels, Arabisch, Bengaals, Tsjechisch, Deens, Duits, Spaans, Frans, Hindi, Indonesisch, IJslands, Italiaans, Japans, Koreaans, Maleis, Nederlands, Pools, Portugees, Russisch, Zweeds, Thai, Turks, Oekraïens, Vietnamees en Chinees.

Arabisch past lang="ar" en dir="rtl" toe vóór React. De zijbalk gaat rechts, Gesprek rechts van de desktopsplitsing, Werkruimte links, directionele pictogrammen spiegelen, tabnavigatie volgt RTL en slepen/toetsenbord gebruiken visuele RTL-semantiek.

Technische inhoud blijft links-naar-rechts waar richting belangrijk is:

• code en syntaxismarkering;
• bestandspaden;
• model-ID's;
• opdrachten en voorbeeldlogs;
• tooluitvoer en metagegevens; en
• inhoud van codeblokken.

Taaknamen, natuurlijke prompts, fouten, bestandsnamen en voorbeeldopdrachten gebruiken waar passend automatische tekstrichting.

Problemen oplossen

Runtime niet beschikbaar met npx

npx libre-webui voert de backend op de host uit maar installeert Docker niet. Voer docker info uit als dezelfde besturingssysteemgebruiker. Installeer/start Docker of herstel daemonrechten als de opdracht ontbreekt of faalt en herlaad Work.

Controleer ook een gezonde Ollama of minstens één actieve voltooiings-/chatplugin met model en referentie voor de huidige beheerder.

Runtime niet beschikbaar in Docker of Kubernetes

Een Compose-implementatie uit de repository hoort dit niet te melden: image bevat CLI en Compose mount socket. Het paneel noemt de oorzaak — ontbrekende CLI in aangepaste image, ontbrekende socketmount of gebruiker niet in socketgroep. Stel voor de laatste DOCKER_GID in en maak container opnieuw. Zie Work uitvoeren wanneer Libre WebUI zelf in Docker draait.

Schakel op Kubernetes de eigen runtime in met --set work.enabled=true. Libre meldt kubernetes, bevraagt de API en draait Pods met PVC's. Mount geen containerruntimesocket van een node; zie Kubernetes.

Geen Work-compatibele modellen

Kies bij Ollama een model dat tools meldt. Controleer voor plugins:

• type is completion of chat;
• actief;
• exact model staat in modelmap;
• huidige beheerder heeft bruikbare API-sleutel; en
• extern model implementeert toolaanroepen van de provider.

Work valt nooit terug op een andere provider.

Pakketinstallatie of externe Git-opdracht mislukt

Controleer of benoemd runtimebeleid netwerk inschakelt; er is geen losse schakelaar per taak. Bekijk daarna DNS, proxy, firewall/NetworkPolicy, register, certificaat, runtime en upstreamservice en of de image de opdracht bevat.

Git is alleen lokaal. Gebruik Terminal of modelopdrachten alleen als netwerk- en referentiebeleid externe Git bewust toestaat. Plak geen langlevend toegangstoken in de werkruimte.

Een uitvoering stopt bij een agentlimiet

Het ronde- of afgeleide toolbudget kan uitgeput zijn. Work vraagt vóór einde een overdracht zonder tools; bekijk voltooid werk en resterende stappen. Invoer nodig is eindstatus voor die uitvoering zonder voltooiing te claimen. Start een vervolg of verhoog bewust WORK_MAX_AGENT_ROUNDS voor alle providers als host- en kostenbeleid langere uitvoeringen toestaan.

HTTP 429 bij het starten van werk

Instantie of beheerder heeft runtime- of taaktoelatingslimiet bereikt. Wacht tot uitvoering/voorbeeld stopt, verwijder oude taken of verhoog passende WORK_MAX_* bij voldoende resources.

Het voorbeeld wordt niet gereed

Controleer dat opdracht actief blijft, aan 0.0.0.0 bindt en binnen 15 seconden op WORK_PREVIEW_PORT luistert. Leeg veld detecteert een dev-script in package.json of index.html, ook één geneste app. Voer bij meerdere apps of geen ingangspunt een expliciete opdracht in. Aangepaste opdrachten starten in /workspace; gebruik cd <app-directory> && ... voor geneste apps.

Het voorbeeld werkt op de server maar niet extern

Controleer een build met ondertekende Work-proxy en herstart om oude loopback-URL te vervangen. Als pagina's laden maar hot reload niet, moet proxy/tunnel WebSocket-upgrades op /api/work/previews/ toestaan. De Dockerpoort blijft op backendloopback en heeft geen firewallopening nodig.

Bestanden blijven maar het voorbeeld stopte

Dit is verwacht na annulering, backendherstart, expliciete stop of mislukte gereedheidscontrole. Proces is tijdelijk, volume duurzaam. Open taak en start opnieuw.

Een bestand kan niet worden geopend of opgeslagen

De API accepteert UTF-8-tekst tot 2 MB. Als het bestand na openen veranderde, herlaad vóór bewerking om wijzigingen van model/browser niet te overschrijven.

Syntaxismarkering wordt platte tekst boven 8,000 tekens of 400 regels. Opmaak heeft aparte limiet 100,000 tekens en 4,000 regels en ondersteunt alleen gedocumenteerde families.

Work meldt herstel van sandboxen

Opstart of afbraak kon niet bewijzen dat sandboxen stopten. Work blijft veilig gesloten en probeert elke 10 seconden. Herstel Docker-/Kubernetes-toegang en bekijk backendlog. Verwijder geen taakrijen zolang gelabelde resources moeten worden verzoend.

Taak verwijderen mislukt

Zorg dat runtime bereikbaar is. Een conflicterende resource zonder verwacht label ai.libre-webui.task wordt geweigerd, niet verwijderd. Los naam/eigendom voorzichtig op en probeer opnieuw.

Beveiligingsoverzicht

Onthoud vóór inschakelen:

• Work is standaard alleen voor beheerders; openen voor iedereen maakt elk actief account sandboxoperator. Hostmappen blijven altijd alleen voor beheerders.
• Backend moet de ingestelde Docker-daemon of Kubernetes-namespace besturen.
• Containers beperken bestandstoegang maar zijn geen VM's.
• Taken zonder benoemd offlinebeleid hebben egress; beleid kiest standaard, bestemmingsbeperking blijft operatorverantwoordelijkheid.
• Work-volumes hebben geen onafhankelijke schijfquota.
• Git is alleen lokaal; externe referenties worden niet gemount of geaccepteerd.
• Hostfirewall, daemonisolatie, uitgaande beperkingen en echte quota blijven operatorcontroles.
• Externe providers ontvangen gevraagde toolresultaten en kunnen meerdere aanroepen per uitvoering kosten.
• Voorbeeldpoorten blijven op loopback en zijn alleen via ondertekende, intrekbare proxy-URL's beschikbaar.
• Standaard Docker Compose levert Docker-runtime; Kubernetes/Helm levert Pod/PVC met work.enabled=true.
• Volledige back-up vereist database én Work-volumes.

Gerelateerde documentatie

• Snel aan de slag
• Werken met modellen
• Sneltoetsen
• Omgevingsvariabelen
• Docker
• Kubernetes
• Verificatie
• Problemen oplossen