Work: isolerade arbetsytor

Work är Libre WebUI:s inbyggda yta för kodagenter. Varje Work-uppgift kombinerar ett beständigt samtal, en uttrycklig rutt till modellleverantören och ett särskilt filsystem på /workspace. Den valda modellen kan granska och redigera filer, köra kommandon i en Docker-container eller Kubernetes Pod som avgränsats till uppgiften och starta en förhandsvisning i webbläsaren.

Work är implementerat direkt i Libre WebUI. Det kräver inte Libre Claw eller någon annan agentdemon.

Endast betrodda användare

Varje Work-API kräver ett autentiserat konto med Work-åtkomst. Som standard innebär det endast administratörer. En administratör kan öppna Work för alla aktiva användare från fliken User Management i Inställningar (arbetsytor i värdmappar förblir alltid endast för administratörer, eftersom de bind-monterar serversökvägar). Work låter avsiktligt en modell köra godtyckliga skalkommandon i en sandlåda. Uppgifter har utgående nätverksåtkomst om inte den valda namngivna körtidspolicyn inaktiverar den. Behandla alla som får Work-åtkomst som betrodda körtidsoperatörer, inte bara som chattanvändare.

Viktiga nyheter i versionen

Den här versionen introducerar Work som ett komplett uppgiftsflöde:

• Separata åtgärder för Work och Chat i huvudsidofältet, med aktivt läge tydligt markerat.
• Work-uppgifter i det vanliga sidofältet i stället för ett andra uppgiftsfält. Befintliga uppgiftspositioner förblir stabila medan körningar uppdateras och den valda uppgiften kan raderas direkt.
• En särskild sandlådeidentitet och beständig Docker-volym eller Kubernetes PVC för varje uppgift. Sandlådor kan stoppas eller återskapas utan att uppgiftsfiler raderas.
• Beständigt samtal, körningstillstånd, verktygsaktivitet, modellval och uppgiftsägarskap i Libre WebUI:s databas.
• En direkt, autentiserad körningsström för assistenttext, leverantörsexponerat resonemang, verktygsanrop och resultat, användning, workerfärdigheter och tillståndsändringar.
• Serverägda workerfärdigheter som lär den valda modellen att granska, redigera, verifiera och förhandsvisa effektivt utan att skriva kontrollfiler i projektet.
• Lokala Ollama-modeller med verktygsstöd, Ollama Cloud-modeller och konfigurerade leverantörsplugin för komplettering eller chatt.
• En responsiv uppdelning mellan Conversation och Workspace med dragbar, tangentbordstillgänglig storlek på datorer och fokuserad ytväxling på mindre skärmar.
• Integrerade vyer för Files, Activity, Git, Terminal, Preview och Screen — Screen-vyn är den observerbara, lärbara Work Computer-skrivbordsmiljön.
• Syntaxmarkering i mörkt och ljust läge, kodformatering i webbläsaren, identifiering av sparningskonflikter och tillfälliga osparade utkast.
• Ett avfärdningsbart meddelande per användare när en fjärrmodellleverantör väljs.
• Fullständiga Work-översättningar för alla 25 språk som stöds, inklusive inbyggd arabisk layout från höger till vänster, medan kod, sökvägar, modellidentifierare och kommandoutdata förblir vänster till höger.

Den beständiga enheten är uppgiftens arbetsyta, inte en container som kör kontinuerligt. Libre WebUI startar, stoppar och kan återskapa uppgiftens container efter behov samtidigt som den namngivna volymen behålls.

Arkitektur

Libre WebUI, inte modellen eller webbläsaren, väljer namn på sandlåda och arbetsyta, avbildning, montering, användare, gränser, nätverksläge och förhandsvisningsport. Modellen får endast följande verktyg:

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

delete_file och move_file har sökvägsskydd precis som övriga filverktyg: de vägrar lämna arbetsytan, följer aldrig symboliska länkar, kräver en uttrycklig rekursiv flagga innan en katalog tas bort och skriver aldrig över en flyttdestination. Eftersom de körs genom filhjälpens sökväg i stället för ett skal fungerar de även medan en förhandsvisning körs, när run_command är blockerat.

Modellförfrågningar görs av Libre WebUI:s backend. De kommer inte från Work-containern och är inte beroende av containerns nätverkspolicy.

Krav

Work behöver en konfigurerad sandlådebackend:

• Standardbackend kräver att Docker är installerat, att demonen kan nås och att backendprocessen får anropa docker (eller körfilen som konfigurerats genom WORK_DOCKER_COMMAND).
• Kubernetes-backend kräver API-uppgifter samt den namnrymdsavgränsade Role, RoleBinding, sandlådenamnrymden och NetworkPolicies som Helm-diagrammet skapar när work.enabled=true.

Varje backend behöver dessutom:

• En modell med verktygsstöd som exponeras genom:
  • en frisk Ollama-tjänst, inklusive modeller som nås via Ollama Cloud; eller
  • ett aktivt kompletterings-/chattplugin med exakt konfigurerad modell och uppgifter för den aktuella administratören.
• Tillräckligt med körtidslagring för avbildningen, genererade projekt och lokala projektberoenden.
• Ett autentiserat konto med Work-åtkomst. Work är endast för administratörer som standard; en administratör kan öppna det för alla aktiva användare.

Libre WebUI kontrollerar Ollamas annonserade modellfunktioner före en körning och avvisar en Ollama-modell som inte annonserar tools. Pluginbaserade modeller måste stödja leverantörens protokoll för verktygsanrop. Om en vald fjärrmodell avvisar verktyg misslyckas körningen. Work byter inte modell eller leverantör i tysthet.

Starta lokalt

För den enklaste Work-konfigurationen som stöds kör du Libre WebUI och Docker på samma dator som webbläsaren:

docker info
npx libre-webui@latest

Öppna http://localhost:8080, logga in som administratör, välj Work i sidofältet, välj en kompatibel modell och beskriv projektet eller ändringen.

Om Docker saknas, har stoppats eller inte kan nås visar Work Runtime unavailable med backendens orsak och inaktiverar Run-redigeraren. Libre WebUI kör aldrig Work-kommandon direkt på värden som reservlösning.

Körtidsavbildningen granskas vid första användning och hämtas automatiskt om den saknas. Den första åtgärden kan därför ta längre tid än senare åtgärder.

Använd Work-gränssnittet

Skapa och återöppna uppgifter

Välj Work bredvid Chat i sidofältet. Skriv en instruktion, välj en modell och välj Run. Det första meddelandet skapar uppgiften, dess första körning, leverantörsrutten och den beständiga arbetsytan.

Varje uppgift finns kvar i det primära sidofältet. När den öppnas igen återställs det senaste samtalet, Files-vyn, aktuellt leverantörs-/modellval och arbetsytan. Äldre samtalsmeddelanden kan läsas in sidvis. Du kan byta namn från titeln och radera uppgiften permanent från menyn för vald uppgift eller sidofältet.

Endast en körning kan vara aktiv per uppgift. En senare instruktion skapar en ny körning mot samma samtal och filsystem.

Redigeraren stöder diktering: en mikrofonknapp använder webbläsarens tal-API där det finns, eller en konfigurerad tal-till-text-modell som reserv, och lägger till transkriptet efter redan inskriven text. I samtalet visas filer som en körning skapade eller flyttade som klickbara brickor under den verktygsaktivitet som skapade dem. Ett klick öppnar filen i arbetsytans Files-redigerare (och växlar till arbetsytan på smala skärmar). Brickor kommer endast från ändrande verktyg, så en körning som läste tjugo filer men skrev en visar exakt den artefakten.

Anlita en agent

Startvyn erbjuder Hire as an agent när du har personas. Välj en så blir den skapade uppgiften en beständig namngiven agent i stället för en engångsuppgift. Agenten behåller sin persona mellan körningar — personans namn och systemprompt läggs före Work-systemprompten (sandlådans körtidskontrakt åsidosätter dem alltid) — och sidofältet fäster agenter i en egen grupp Agents ovanför tillfälliga uppgifter, med personaavatar, aktivitetsindikator och en statusrad. När sidofältet är hopfällt är det bara dessa fästa agentavatarer som blir kvar i listen; engångsuppgifter i Work kommer tillbaka när sidofältet fälls ut igen.

Statusraden har två nivåer. För anlitade agenter begär ett billigt modellrop utan verktyg i slutet av körningen en status på cirka åtta ord ("Inbox at zero. 2 replies ready."). Svaret begränsas till en rad på 90 tecken. Fel eller timeout faller tillbaka till den deterministiska nivån — första raden i assistentens slutmeddelande. Tillfälliga uppgifter och misslyckade körningar använder endast den deterministiska nivån, och WORK_STATUS_BLURB_MODEL=0 inaktiverar modellförfrågan helt. Agenter har också en olästindikator. När uppgiften öppnas flyttas en monoton sedd-markör per uppgift (synkroniserad mellan enheter), och sidofältet visar en punkt när en körning nådde slutstatus efter markören.

Agenter rapporterar också genom aviseringar — i appen och, när det är aktiverat, via webbpush: work-run-finished när en körning slutförs, work-run-attention när den stannar för indata eller misslyckas och work-takeover när agenten ber en människa ta över skärmen. Bannern syns endast medan fliken Screen är öppen, så pushen når dig på andra platser. Varje avisering länkar direkt till agenten.

Du kan anlita under en persona du äger eller en som delats med dig. Den delade vyn avslöjar aldrig ägarens personaminnen. Om personan senare raderas fortsätter agenten utan den och en varning loggas. API:et accepterar personaId och isAgent när uppgiften skapas. En uppgift som skapas med en persona blir automatiskt en agent.

Fliken Agent

En agents arbetsytepanel öppnas med en extra första flik, Agent — agentens egen sida:

• Identity: personaavatar, namn, aktivitetsindikator och senaste statusrad.
• Screen: när uppgiftens policy ger Work Computer, en kompakt, direkt och skrivskyddad miniatyr av agentens skärm. Det är en verklig visare (räknas mot uppgiftens visningsbudget). Ett klick öppnar hela Screen-fliken där övertagande, undervisning och ljud finns.
• Routines: automatiseringar bundna till uppgiften. Varje körning sker i agentens egen arbetsyta och samtal med agentens modell och körtid — inte som en ny uppgift — så en morgonbriefing samlas på ett ställe. Rader visar schemat i ord med ett paus-/återupptagningsreglage och formuläret + Routine är redan bundet till agenten. En förekomst som utlöses medan agenten är upptagen misslyckas ärligt som work-task-busy i stället för att köas.
• Auto Review: agentens godkännandereglage och de Always-allow-regler agenten har samlat på sig (ta bort en regel för att stänga dess omfång igen). När uppgiftens policy tvingar fram granskning är reglaget låst i påslaget läge.
• Taught skills: procedurer som demonstrerats i undervisningsläge, med ett aktiveringsreglage per färdighet.

Anslutna verktyg (MCP- och OpenAPI-servrar)

Work-agenter kan anropa samma verktygsservrar som konfigurerats för chatten — MCP eller OpenAPI, registrerade av en administratör under Inställningar → Verktyg. Verktygen visas för agenten under sina namnrymdade namn (server__tool) och anropen körs från Libre WebUI:s backend genom den härdade verktygsgatewayen (SSRF-skyddad utgående trafik, uppgifter per användare, storleks- och tidsgränser) — aldrig inifrån sandlådan.

Utbudet är ärligt om vad en autonom körning faktiskt kan använda:

• En offlineuppgift erbjuds inga alls: oavsett att trafiken går via backend förblir en uppgift utan nätverksåtkomst offline — samma skäl som för web_search.
• En server som kräver personliga uppgifter som användaren inte har sparat filtreras bort redan när verktygen erbjuds, eftersom en autonom körning inte kan pausa för att fråga efter dem. Lägg till uppgifterna under Inställningar → Verktyg, så erbjuder nästa körning servern.
• Åtkomstläget för verktyg (endast administratörer eller alla användare) och synligheten per server gäller precis som i chatten, och en personas bindningar till verktygsservrar begränsar vilka servrar dess anlitade agent ser.
• När godkännanden är aktiva pausar anslutna verktyg som servern klassar som sidoeffektsverktyg för ditt beslut, precis som varje annan grindad åtgärd; skrivskyddade verktyg körs utan att fråga.

Delegering mellan agenter (@-omnämnanden)

Anlitade agenter kan lämna över arbete till varandra. Skriv @ i Work-fältet för att nämna en av dina andra agenter; den aktuella agenten ser sin kollegielista (namn och statusrader) i sina instruktioner och delegerar matchande förfrågningar med verktyget message_agent. Delegering är samordning via meddelanden, medvetet inte via delade datorer: varje agent behåller sin egen isolerade arbetsyta och sandlåda, och mottagaren kan inte se det delegerande samtalet — förfrågan måste bära sin egen kontext.

Delegering är asynkron. Verktyget svarar direkt, målagenten kör i sin egen uppgift (dess samtal visar förfrågan märkt Delegated by avsändaren), och när den är klar — slutförd, behöver indata, misslyckad eller avbruten — levereras dess slutliga svar tillbaka i den delegerande agentens samtal som ett meddelande märkt Report from den agenten. Om delegeraren fortfarande kör når rapporten dess modell i nästa runda; är den inaktiv väntar rapporten helt enkelt i samtalet — en rapport startar aldrig en körning av sig själv, så två agenter kan inte studsa fram och tillbaka. Delegerade körningar kan inte delegera vidare, ett upptaget mål misslyckas ärligt i stället för att köas, och när godkännanden är aktiva pausar message_agent för granskning som varje annan åtgärd med sidoeffekt (en Always-allow-regel gäller bara den enda målagenten).

Åtgärdsgodkännanden (Auto Review)

Åtgärder med sidoeffekter kan pausa för ditt beslut innan de körs. När godkännanden är aktiva för en uppgift — dess Work-policy sätter Require approval for side-effecting actions, eller agentens reglage Auto Review är på — stannar körningen innan den kör run_command, computer_act, delete_file, move_file eller message_agent och visar ett beslutskort i samtalet: Allow once, Always allow eller Deny.

• Allow once kör exakt det här anropet och frågar igen nästa gång.
• Always allow kör anropet och sparar en regel på uppgiften: hela verktyget för fil- och datoråtgärder, begränsat till kommandots program (dess första token) för run_command — att godkänna npm run build förhandsgodkänner framtida npm-kommandon, inte hela skalet — och begränsat till den enda målagenten för message_agent. Reglerna listas i Agent-flikens Auto Review-avsnitt och kan tas bort där.
• Deny avvisar anropet. Modellen får veta att användaren nekade åtgärden och att den inte får försöka igen som den är; körningen fortsätter med det svaret.

Ett väntande godkännande utlöser också en avisering (i appen, och webbpush när det är aktiverat), eftersom körningen kan vara flera minuter in i obevakat arbete när den når grinden. Om ingen beslutar inom fem minuter förfaller begäran, åtgärden körs inte, och körningen avslutas som Needs input med ett normalt överlämnande i stället för att vänta ut sin budget.

Godkännanden grindar åtgärder, inte insyn: write_file och de skrivskyddade verktygen förblir ogrindade, och varje beslut hamnar i säkerhetsrevisionsloggen.

Förstå uppgiftsstatus

Gränssnittet mappar beständiga backendtillstånd till en mindre användaruppsättning:

Status i gränssnittet	Backendtillstånd	Indikatorfärg
Inaktiv	idle	rgb(255, 255, 255)
Tänker	preparing eller running	rgb(48, 121, 255)
Slutförd	completed	rgb(76, 212, 117)
Behöver indata	needs_input eller cancelled	rgb(255, 204, 0)
Fel	failed	rgb(255, 61, 129)

Om en aktiv körning stoppas ändras den till Needs input och filerna bevaras. Om säkerhetsbudgeten för rundor eller verktygsanrop tar slut avslutas den också som Needs input efter det sista överlämnandet utan verktyg, så ofullständigt arbete märks aldrig Complete.

En aktiv körning låser inte samtalet. Ett meddelande som skickas medan agenten arbetar läggs omedelbart till och når modellen i nästa runda, så du kan styra, korrigera eller lägga till kontext utan att stoppa körningen. Stoppknappen finns kvar bredvid skicka.

Ändra arbetsytans storlek

Vid skrivbordsbrytpunkten xl delar Conversation och Workspace en dragbar delning:

• Standardsbredden för samtalet är 45 %.
• Det föredragna intervallet är 30–70 %, med hänsyn till minsta innehållsbredder.
• Det sparade förhållandet gäller den inloggade användaren i den webbläsaren.
• Piltangenter flyttar avdelaren med 2 %; håll Skift för 10 %.
• Home och End väljer tillgängligt minimum respektive maximum.
• Enter eller dubbelklick återställer delningen.

Kontrollerna följer aktiv skrivriktning. På arabiska ligger Conversation till höger och Workspace till vänster, och storleksändring med pekare och piltangenter fortsätter i förväntad visuell riktning.

På mindre skärmar används kontrollen Conversation/Workspace i uppgiftshuvudet för att växla yta.

Filer

Fliken Files visar direkta barn till /workspace, öppnar strikt giltiga UTF-8-textfiler och sparar ändringar till uppgiftsvolymen. Ogiltiga bytesekvenser avvisas i stället för att ersättas med informationsförlorande platshållartecken.

Redigeraren erbjuder:

• syntaxmarkering i ljust och mörkt läge för vanliga webb-, system-, skript-, data- och märkspråk;
• Cmd/Ctrl+S för att spara;
• Shift+Alt+F för att formatera filer som stöds;
• optimistisk identifiering av sparningskonflikter, så en äldre redigerarvy inte tyst kan skriva över en fil som ändrats sedan den öppnades;
• osparade utkast avgränsade till uppgift och sökväg i webbläsarens sessionslagring; och
• navigeringsvarningar när en osparad redigering är öppen.

Direkt syntaxmarkering pausas över 8 000 tecken eller 400 rader för att behålla responsen. Formatering finns upp till 100 000 tecken och 4 000 rader för JavaScript/JSX, TypeScript/TSX, JSON-varianter, CSS/SCSS/Less, HTML, Markdown/MDX och YAML.

När modellen ändrar en fil som var öppen visar Files en röd/grön ändringsvy med exakt vad som lades till och togs bort sedan turen började, och långa oförändrade delar fälls ihop. Ett reglage i verktygsfältet växlar mellan diff och redigerare, och räknarna +added −removed sammanfattar turen. Jämförelsebasen är det senaste innehållet webbläsaren såg före turen, så filer som öppnas första gången efter turen visar ingen diff.

Webbläsarutkast är bekvämlighetstillstånd, inte en säkerhetskopia. De rensas efter en lyckad sparning eller uppgiftsradering och försvinner normalt när webbläsarsessionen slutar.

Aktivitet

Fliken Activity visar verktygsanrop, verktygsresultat, filåtgärder, kommandoutdata och fel. Verktygsmetadata kan expanderas i samtalet. Kommando- och verktygsutdata visas vänster till höger även när det omgivande gränssnittet är höger till vänster.

Medan en körning är aktiv öppnar Libre WebUI en autentiserad server-sent event-ström och visar framsteg när backend tar emot dem. Strömmen kan innehålla:

• en första snapshot och senare ändringar av run_state;
• reasoning_delta när den valda leverantören uttryckligen visar resonemang;
• text i assistant_delta;
• aktivitet i tool_call och tool_result;
• mätningar i usage;
• aviseringar skill_loaded för serverlevererad workervägledning; och
• sluthändelser error eller done.

Tillgång till och detaljnivå för resonemang beror på modell och leverantör. Libre WebUI visar endast resonemangsinnehåll som leverantören returnerar genom sitt API. Det kan inte återskapa dold tankekedja, och vissa modeller ger ingen resonemangsström. Assistenttext och verktygsaktivitet strömmas ändå när de stöds oberoende av resonemang.

Utdata begränsas avsiktligt. Ett avkortat resultat bevisar inte att ett kommando inte skapade mer utdata. Be modellen granska ett smalare resultat eller köra ett mer fokuserat kommando.

Git

Fliken Git erbjuder lokala versionshanteringsåtgärder för uppgiftens eget /workspace:

• initiera ett arkiv med grenen main;
• granska porcelain-status, ahead/behind-antal och upp till 20 senaste commits;
• granska en begränsad textdiff för en ändrad sökväg;
• stagea upp till 200 uttryckligen valda sökvägar åt gången;
• committa stageade ändringar med den inloggade administratörens användarnamn och e-post, eller en instanslokal no-reply-adress när kontot saknar e-post;
• skapa en lokal gren efter första commit; och
• byta till en befintlig lokal gren när arbetskopian är ren.

Den här ytan är avsiktligt endast lokal. Den har inga kontroller för clone, fetch, pull, push, fjärrhantering, godtyckliga Git-kommandon, token, SSH-nycklar eller pull requests. Dessa åtgärder behöver en separat betrodd uppgiftsförmedlare, helst en GitHub App eller motsvarande installationstoken som avgränsas till ett arkiv och en åtgärd. Placera inte långlivade Git-uppgifter i /workspace, uppgiftscontainerns miljö eller arkivkonfigurationen.

Git-läsningar kan köras när uppgiften i övrigt är inaktiv eller aktiv. Git-skrivningar avvisas medan en modellkörning, interaktiv terminal eller förhandsvisning äger uppgiftscontainern. Grenbyte kräver dessutom en ren arbetskopia. Detta förhindrar att gränssnittet tävlar med modellen eller en långlivad process om samma filer.

Varje Git-kommando i gränssnittet är en fast argumentarray som körs som UID/GID 1000:1000 i uppgiftscontainern. Användarindata utvärderas aldrig av ett skal. Körtiden inaktiverar system-/global Git-konfiguration, promptar, hooks, uppgiftshjälpare, commit-signering, rekursion i submoduler, externa diffdrivrutiner, textconv och nätverksprotokoll för den här ytan. Den vägrar arkiv vars arbetskopia inte är exakt /workspace eller vars Git-/gemensamma katalog löses utanför /workspace. Git-skrivningar som kan behandla filinnehåll blockeras även när arkivkonfigurationen anger ett körbart clean-, smudge- eller processfilter.

Dessa kontroller skyddar Libre WebUI:s Git-API. En administratör kan fortfarande använda Terminal och modellen kan använda run_command för att köra vanliga Git-kommandon i sandlådan. Sandlådan och distributionsgränsen förblir därför säkerhetskontrollerna för godtyckliga kommandon.

Inbyggda workerfärdigheter

Varje körning får en serverägd arbetsyteguide. Den förklarar den beständiga gränsen /workspace, skrivskyddad containerrot, tillfälligt process- och /tmp-tillstånd, nätverkspolicy, kommando- och utdatasgränser samt förhandsvisningens livscykel. Dess inbyggda färdigheter instruerar modellen att:

• granska projektinstruktioner, manifest, låsfiler, skript och aktuellt arkivtillstånd före redigering;
• bevara orelaterat arbete och samla oberoende läsningar eller sökningar;
• fortsätta med implementeringen i stället för att stanna efter en plan;
• köra fokuserad verifiering före bredare kontroller;
• diagnostisera ett fel i stället för att försöka igen blint; och
• verifiera programmet innan förhandsvisningen startas som den slutliga långlivade processen.

Guiden finns endast i modellkontexten. Libre WebUI skapar ingen AGENTS.md, färdighetskatalog eller annan kontrollfil i användarens arbetsyta. Projektets egna instruktioner förblir projektvägledning och kan inte åsidosätta containerns eller verktygens säkerhetsgräns.

Terminal

Fliken Terminal ansluter ett interaktivt skal till samma sandlådecontainer som modellen arbetar i. En administratör kan granska tillstånd, köra ett bygge manuellt eller felsöka det en körning lämnade utan att lämna webbläsaren.

Skalet kör under identisk containerpolicy som varje modellverktyg: den oprivilegierade användaren 1000:1000, arbetskatalogen /workspace, i den redan härdade containern med borttagna funktioner. En terminal ger ingen behörighet som modellens verktyg run_command inte redan har. Den är ett mänskligt gränssnitt till samma gräns, inte en väg runt den.

Driftbeteende:

• Autentisering — webbläsaren byter sin vanliga Authorization-rubrik via HTTP mot en kortlivad engångsbiljett som binds till Work-terminalprotokollet och exakt uppgift. Endast biljetten och uppgifts-ID:t visas i uppgraderings-URL:en /ws/work-terminal. Före varje skalindata kontrollerar Libre åter kontostatus, Work-åtkomst, uppgiftens existens och ägarskap. Återkallelse stänger skalet och släpper körtidslåset omedelbart.
• Ursprungskontroller — när CORS_ORIGIN eller BASE_URL är konfigurerad måste webbläsaruppgraderingar matcha ett av ursprungen. Konfigurera minst ett för fjärrdistributioner. Uppgraderingar utan ursprung är tillgängliga för Electron och andra icke-webbläsarklienter, men kräver samma uppgiftsbundna biljett och aktuella behörighetskontroller. Använd TLS, brandvägg och omvänd proxy för att styra klienterna.
• Tillträde — en öppen terminal tar ett körtidslås precis som ett kommando eller en förhandsvisning och räknas mot WORK_MAX_ACTIVE_RUNTIMES_*.
• Containerns livstid — en ansluten terminal håller containern igång och hindrar tomgångsstoppet från att ta bort den mitt i sessionen.
• Samtidighet — WORK_TERMINAL_MAX_SESSIONS_PER_TASK (standard 2) begränsar samtidiga skal per uppgift.
• Tomgångstimeout — WORK_TERMINAL_IDLE_TIMEOUT_MS (standard 15 minuter) stänger en orörd session och släpper dess lås.
• Medan en körning är aktiv — fliken förklarar att modellen äger containern och öppnar skalet när turen är klar.

Terminalen talar direkt med Docker Engine API eftersom en TTY-session kräver en kapad dubbelriktad ström som Docker CLI endast tillhandahåller till en riktig styrterminal. Den använder WORK_DOCKER_SOCKET, annars DOCKER_HOST — en unix://-socket eller en vanlig HTTP-tcp://-slutpunkt som en socketproxy, vars HTTP-medvetna vidarebefordran bär den kapade strömmen över en vanlig Connection: Upgrade-tunnel — och annars /var/run/docker.sock. En DOCKER_HOST som klienten inte kan tala med (ssh:// eller tcp:// med DOCKER_TLS_VERIFY angiven) gör terminalen otillgänglig med orsaken i stället för att ansluta någon annanstans. Resten av Work fortsätter fungera. På Kubernetes-backend går samma session via exec-underresursen som en TTY-WebSocket genom API-servern — inklusive storleksändringsramar — utan någon Docker-slutpunkt.

Terminalsessioner är interaktiva och spelas inte in. Kommandon som skrivs där visas inte i uppgiftens Activity-tidslinje.

Förhandsvisning

Fliken Preview startar, stoppar, bäddar in och öppnar den genererade webbapplikationen. När kommandofältet är tomt granskar Libre WebUI arbetsytan och:

• kör skriptet dev i en package.json i roten med nödvändig värd och port;
• serverar en index.html i roten med en medföljande statisk server utan beroenden; eller
• använder samma regler för en enda app i en underkatalog.

Rotprogram har företräde. Om flera lika sannolika kapslade appar hittas, eller om ingen startpunkt som stöds finns, returnerar Work ett åtgärdbart fel i stället för att försöka med ett orelaterat npm-kommando. Ange ett anpassat kommando innan Start preview väljs för andra projektlayouter eller servrar. Anpassade kommandon startar i /workspace, så inkludera relativ katalog vid behov, till exempel cd apps/web && npm run dev -- --host 0.0.0.0 --port 4173. En anpassad process måste lyssna på 0.0.0.0 och konfigurerad WORK_PREVIEW_PORT. Work väntar upp till 15 sekunder på att porten ska bli redo.

Modellen kan också starta förhandsvisningen genom verktyget start_preview. Det är det enda sättet som stöds för en modell att lämna en process igång. Vanliga run_command-anrop rensar bakgrundsunderprocesser när kommandot är klart.

Skärm (Work Computer)

Se hela demonstrationen: en verklig, oredigerad körning (30× och sedan realtid) där en Work-agent bläddrar i NASA:s bildgallerier på sin egen skärm, väljer foton och därefter bygger och testar ett interaktivt Three.js-galleri — allt från en enda prompt.

En uppgift vars policy aktiverar Work Computer får en Screen-flik: ett direktfönster till ett virtuellt skrivbord i samma sandlåda — fönsterhanterare, docka och Chromium på en skärm med 1280×800. Du kan se agenten arbeta, ta över mus och tangentbord, lyssna på datorns ljud och lära ut uppgifter genom demonstration. När fliken öppnas startas GUI-sessionen vid behov (ingenting körs förrän någon tittar) och en VNC-visare över WebSocket ansluts.

En administratör aktiverar den med ett klick. Work-startsidan visar ett kort för Work Computer med knappen Enable. Knappen bygger den medföljande GUI-avbildningen på installationens egen Docker-demon (det första bygget tar några minuter) och skapar en färdig policy för Work Computer — inget manuellt docker build och inga policyfält krävs. Bakom en filtrerad Docker API-proxy är byggslutpunkten avsiktligt nekad. Hämta den publicerade avbildningen på Docker-värden i stället (ghcr.io/libre-webui/libre-work-computer, taggad libre-work-computer:latest) eller bygg den därifrån från deploy/work-computer/. Enable hoppar då över bygget och skapar endast policyn. Uppgifter med policyn måste ha nätverksåtkomst — skärmen nås genom en loopback-publicerad containerport, precis som förhandsvisningen.

Säkerhetsmodell: VNC-servern i containern binder till localhost bakom två lösenord per session — ett skrivskyddat som ges till varje behörig tittare och ett med full kontroll som endast släpps till den aktuella innehavaren av övertagandelåset. VNC-servern håller därför alla andras indata inaktiv. WebSocket-bryggan är den enda nåbara ytan, publicerad på Docker-värdens loopback och aldrig exponerad direkt. Varje tittare autentiserar med en engångsbiljett bunden till sessionen och uppgiften — samma mekanism som Terminal — och aktuell Work-åtkomst kontrolleras på varje anslutning, så en återkallelse bryter skärmarna omedelbart. Upp till fyra samtidiga tittare kan se en skärm, och tittande räknas som uppgiftsaktivitet för tomgångsrensningen. Tittande och körning konkurrerar aldrig. Om skärmen öppnas mitt i agentens körning ansluts den till körningens egen sandlåda, en visad skärm blockerar inte nästa körning och sessionen överlever att körningen slutar — även i teaminstallationer där körningar sker i en separat workerprocess. Webbläsarprofilen sparas i /workspace/.browser-profile, så inloggningar inuti datorn överlever containeromstarter.

Agentstyrning: en uppgift med Work Computer ger också modellen två ytterligare verktyg. computer_observe returnerar en fullständig skärmbild av skrivbordet tillsammans med markörposition, aktivt fönster, webbläsarens aktuella URL, om sidan (i stället för webbläsarens eget gränssnitt) har tangentbordsfokus, en kompakt beskrivning av fokuserat element och en skärmbildshash. De semantiska signalerna kommer från en DevTools-slutpunkt som binds till containerns loopback och saknas för GUI-avbildningar som byggdes innan den fanns. computer_act utför en omgång med upp till 24 mus- och tangentbordsåtgärder (flytta, klicka, dubbelklicka, högerklicka, skriva, tangentkombinationer, rulla, vänta) och returnerar skärmbilden efter att de stabiliserats.

Tre körtidsspärrar håller omgångarna ärliga. Åtgärderna type/key kan bära ett focus-påstående och misslyckas säkert om fältet inte har tangentbordsfokus (så text inte hamnar i adressfältet i tysthet). En omgång stoppas tidigt om ett fönster visas, titeln ändras eller fokus flyttas mitt i omgången, eftersom återstående koordinater riktades mot föregående skärm. En omgång kan också ange ett förväntat utfall (titel, URL eller ändrad skärmdel) som körtiden verifierar med en adaptiv tidsgräns — "pending" betyder ännu inte observerat, aldrig antagen framgång. Efter en omgång får skärmen stabiliseras adaptivt (genom frågor tills den slutar ändras) i stället för efter en fast fördröjning.

Varje resultat innehåller dessutom bevis som modellen instrueras att läsa. Klick på uttryckliga koordinater returnerar ett kvitto som anger om bildpunkter nära klicket ändrades. scroll_until rullar mot en måltext eller sidkant och rapporterar om den blev synlig. Varje observation jämförs med den föregående, så en oförändrad skärm anges uttryckligen. Omgångar kan deklarera ett enradigt subgoal som sparas med resultatet som en kontrollpunkt och återges i återställningspromptar.

Agentloopen upptäcker låsningar i förankringen (tre identiska åtgärder mot en oförändrad skärm utlöser ett återställningsmeddelande, och en upprepning avslutar körningen och ber om indata i stället för att förbruka återstående rundor) och växande tvetydighet (upprepade overifierade förväntningar utlöser ett meddelande om ny förankring). Looptelemetri — rundor, verktygslatens, skärmbilder, spärrar och förväntningsbedömningar — stämplas på varje beständig verktygspost och sammanfattas när körningen slutar.

Skärmbilder når modellen som verkligt bildinnehåll på varje leverantörsrutt — Ollama, Anthropic, Gemini samt OpenAI-kompatibla chatt- och Responses-plugin — så modellen som driver uppgiften bör vara en bildmodell. Om leverantören avvisar bildindata (en modell med endast text) misslyckas inte körningen. Skärmbilder släpps under resten av körningen, modellen instrueras att förlita sig på textobservationerna och en anteckning i transkriptet förklarar försämringen. En modell som inte kan se skärmen verifierar dock mycket mindre, så föredra en bildmodell för datoruppgifter. Endast de senaste skärmbilderna finns i modellens aktuella kontext, och beständiga uppgiftstranskript sparar endast textobservationen, aldrig bilddata.

Webbläsaren levereras med inbyggd innehållsblockering — uBlock Origin Lite för annonser och spårare (låst och kontrollsummaverifierad vid avbildningsbygget, med filtreringsläge låst genom hanterad policy) samt automatisk stängning av cookie-samtyckesbannrar — eftersom annonser och samtyckesväggar slösar agentens skärmbilder, token och klick. Annonsförfrågningar neutraliseras på uBlock-sätt: kända annonsskript löses till ofarliga lokala stubbar så att sidor fortsätter fungera. Agenten instrueras att aldrig skriva in uppgifter eller slutföra CAPTCHA-/2FA-utmaningar; den rapporterar hindret i stället. För opålitliga uppgifter bör en GUI-policy kombineras med en filtrerande DNS-resolver. En skrivbordswebbläsare gör policyn för utgående nätverk viktigare, inte mindre.

Ljud: skärmen är avstängd som standard (en webbläsarregel — ljud kräver ett klick). Högtalarknappen i Screen-panelen strömmar datorns ljud direkt. I sandlådan spelar PulseAudio till en null-sink vars monitor fångas som rå PCM och serveras över en andra autentiserad, loopback-publicerad WebSocket-brygga — med samma biljett, åtkomstkontroll och tittargräns per uppgift som skärmen. Detta kräver en GUI-avbildning byggd från deploy/work-computer/ i denna version eller senare.

Övertagande: knappen Take over i Screen-panelen ger dig mus och tangentbord — för inloggning, hantering av CAPTCHA eller andra steg som agenten inte får utföra — och I'm done lämnar tillbaka skärmen. En VNC-session betjänar båda rollerna: servern i containern har ett lösenord med full kontroll och ett skrivskyddat lösenord (genererade per session, aldrig loggade). Tittare får bara skrivskyddslösenordet, och kontrollösenordet släpps endast till den aktuella innehavaren av ett kontrollås. Låset har TTL (ett övergivet övertagande upphör inom två minuter), förnyas medan övertagandegränssnittet är öppet och är samarbetsbaserat — det kan inte tas från en annan användare.

En policy kan inaktivera övertagande helt (Allow screen takeover i policyredigeraren). Uppgifter med policyn döljer Take over- och Teach-kontrollerna, övertagandeslutpunkten vägrar och agentens request_takeover rapporterar att kontroll inte kan lämnas över. Tittande förblir tillgängligt. Medan en människa har kontroll blockeras både computer_observe och computer_act, så agenten kan varken motarbeta din indata eller ta skärmbilder av det du skriver. Agenten kan också be om dig: verktyget request_takeover visar en banner i Screen-panelen med orsaken och väntar tills du tar över och lämnar tillbaka. Uppgifter som skrivs under ett övertagande går direkt från ditt tangentbord till sidan — de passerar aldrig modellen eller uppgiftstranskriptet. Övertagande kräver en GUI-avbildning byggd från deploy/work-computer/ i denna version eller senare. Sessioner från äldre avbildningar kan visas men är skrivskyddade för alla.

Undervisningsläge: Teach a task i Screen-panelen spelar in en demonstration. Du styr den riktiga skärmen (kontrollen tas precis som vid övertagande, med synlig inspelningsindikator) medan pekar-, tangentbords- och rullningsåtgärder registreras i skärmkoordinater. Varje klick förankras också. En skrivskyddad kontroll identifierar det interaktiva elementet under pekaren (tagg, ID och synlig etikett) och sidans aktuella URL, så playbooksteg namnger sina mål — "Click "button#submit (Place order)"" — och koordinaterna degraderas till ledtrådar om var kontrollen fanns under demonstrationen.

När demonstrationen sparas byggs en playbook deterministiskt, utan en modell i loopen. Tangenttryckningar grupperas till inskrivna strängar, klick kontra drag avgörs med en tröskel på 8 bildpunkter, pauser blir uttryckliga väntesteg, och inskriven text som nämner hemlighetsord eller ser ut som uppgifter (minst 8 tecken som blandar tre teckenklasser) redigeras bort och ersätts med en instruktion att använda request_takeover i det steget.

Playbooken är en procedur på naturligt språk — förankrade mål först, koordinater som ledtrådar, tolkade på nytt med computer_observe — med när den ska användas, indata, steg, verifiering, ett tillåtet omfång som härleds från värdarna demonstrationen faktiskt besökte (uppspelningen måste stoppa och fråga innan den lämnar dem; en inlärd procedur ärver aldrig mer behörighet än det som visades), godkännandegränser samt stopp- och-fråga-hantering av fel. Den sparas som en vanlig färdighet (slugprefix taught-), så den visas på Skills-sidan med versionering, redigering och delning.

Work-körningar med datorstöd läser in ägarens aktiverade inlärda färdigheter i systemprompten och rapporterar dem i körningens färdighetslista. Att spela upp en inlärd uppgift är därför en vanlig körning vars förfrågan matchar proceduren. Efter en slutförd körning erbjuder färdighetsbrickorna en ettklicksgranskning för lyckad/misslyckad som lägger till en daterad rad i färdighetens avsnitt Track record (nyaste först, begränsat, varje rad en vanlig färdighetsversion). Procedurens historik stannar med proceduren. Skriv inte riktiga lösenord under inspelning. Demonstrera fram till inloggningen, spara och låt request_takeover hantera uppgifter vid uppspelning.

Leverantörer, dirigering och datautlämning

Leverantörsrutter som stöds

Rutt	Validering och beteende
Lokal Ollama	Ollama måste fungera och den exakta modellen måste ange att den stöder verktyg.
Ollama Cloud	Dirigeras uttryckligen genom Ollama; modeller med molnsuffix visar informationen om fjärrleverantören.
Plugin för komplettering/chatt	Pluginet måste vara aktivt, ange den exakta modellen och ha autentiseringsuppgifter för aktuell administratör.
Anthropic-plugin	Använder Works adapter för Anthropic-meddelanden och verktygsanvändning.
Gemini-plugin	Använder Works adapter för Gemini-innehåll och funktionsanrop.
Andra kompatibla plugin	Använder begäransformatet för meddelanden, verktyg och verktygsval enligt OpenAI-stil.

Leverantörstyp och plugin-ID lagras både för uppgiften och för varje körning. Ett modellnamn väljer aldrig rutten på egen hand. Ett plugin som aktiveras med samma modellnamn som en Ollama-modell kan inte fånga upp en befintlig uppgift.

Vad en leverantör tar emot

För varje modellomgång kan den valda leverantören ta emot:

• Works systemprompt;
• de inbyggda agentfärdigheterna och de aktuella körtidsgränserna;
• upp till de senaste 30 samtalsmeddelandena från användaren och assistenten, begränsade till 256 kB;
• Works verktygsdefinitioner;
• historik över assistentens verktygsanrop; samt
• verktygsresultat, som kan innehålla kataloglistor, begärt filinnehåll, sökresultat, kommandoutdata och fel.

Den namngivna volymen laddas inte upp i sin helhet. Allt filinnehåll och all kommandoutdata som ett verktyg returnerar blir dock en del av modellsamtalet och skickas till den valda leverantören. Granska fjärrleverantörernas policyer för lagring, träning, prissättning och användning innan du arbetar med känslig källkod.

Leverantörernas autentiseringsuppgifter stannar i Libre WebUI:s serverdel, oavsett om de har konfigurerats för hela driftsättningen eller för en enskild användare. De används för modellbegäranden från serverdelen och monteras aldrig i Work-containern.

Kryptering av autentiseringsuppgifter på programnivå krypterar inte hela uppgiften. Work-samtal, verktygsresultat, kommandoutdata och uppgiftsmetadata är vanligt databasinnehåll, medan arbetsytefiler och beroenden är vanliga filer i uppgiftens Docker-volym eller Kubernetes-PVC. Använd värdens åtkomstkontroller och diskkryptering när driftsättningens hotmodell kräver kryptering i vila.

Information om fjärrleverantörer

Work betraktar pluginmodeller och Ollama-namn som slutar med :cloud eller -cloud som fjärrmodeller när information ska visas. Om du väljer en sådan modell öppnas ett meddelande som kan avfärdas och som förklarar leverantörens dataflöde samt möjligheten till flera debiterbara anrop. Inställningen att avfärda meddelandet sparas per Libre WebUI-användare.

Alla leverantörsrutter använder samma budget i WORK_MAX_AGENT_ROUNDS, som standard 48 omgångar. Det finns ingen separat gräns på 12 omgångar för plugin. Säkerhetsbudgeten för verktygsanrop är det högsta av 128 anrop eller åtta anrop per konfigurerad omgång. När omgångsbudgeten är slut ber Libre WebUI modellen att göra en sista överlämning utan verktyg som beskriver slutfört arbete, kontroller, hinder och återstående steg. Därefter registreras slutkörningen som Needs input i stället för att visa ett obearbetat undantag för omgångsgränsen eller markera ofullständigt arbete som slutfört. En uppföljande körning fortsätter i samma beständiga arbetsyta. En enda Work-körning kan fortfarande göra många debiterbara leverantörsbegäranden.

Arbetsytor med värdmappar (valfritt)

Med Docker-serverdelen är en uppgifts /workspace normalt en namngiven volym som bara finns för den uppgiften, så modellen kan inte nå dina riktiga filer. En Docker-driftsättning kan i stället tillåta att en uppgift binds till en verklig mapp på värden. Kubernetes avvisar arbetsytor med värdmappar och använder en uppgiftsägd PVC.

Ange båda variablerna och starta sedan om serverdelen:

WORK_HOST_WORKSPACES_ENABLED=true
WORK_HOST_WORKSPACE_ROOTS=/Users/you/Projects

WORK_HOST_WORKSPACE_ROOTS är en :-avgränsad lista över rotkataloger. Som standard används serveranvändarens hemkatalog. När funktionen är aktiverad får Works startsida det valfria fältet Workspace folder. Lämna det tomt så fungerar uppgiften precis som tidigare, med en egen isolerad volym.

Innan en sökväg godtas måste den vara absolut, finnas, vara en katalog och, även efter att eventuella symboliska länkar har följts, peka på en plats i någon av de konfigurerade rotkatalogerna. Kataloger med namnen .ssh, .gnupg, .aws, .config, .kube, .docker, .claude, .libre-webui eller node_modules avvisas alltid. Den upplösta sökvägen lagras med uppgiften och visas i uppgiftshuvudet, så det framgår alltid vilken mapp en uppgift arbetar i.

Detta försvagar sandlådans avgränsning

En arbetsyta på värden innebär att modellen läser och skriver dina verkliga filer. Containerns övriga skydd — användare utan rotbehörighet, borttagna kapaciteter och resursgränser — står då inte längre mellan modellen och den katalogen. Låt funktionen vara inaktiverad om du inte behöver den, håll rotkatalogerna så snäva som möjligt och föredra kataloger som versionshanteras.

Beständighet och körtidens livscykel

Libre WebUI skiljer beständigt tillstånd från körningstillstånd:

Tillstånd	Lagring	Livslängd
Uppgiftsägare, titel, leverantör och status	Libre WebUI-databasen	Tills uppgiften eller den ägande användaren raderas
Körningar, fel, meddelanden och verktygsaktivitet	Libre WebUI-databasen	Tills uppgiften raderas
Arbetsytefiler	Uppgiftsspecifik Docker-volym eller K8s-PVC	Överlever avbruten körning, stoppad förhandsvisning, omstart av sandlådan och programmet
Rotfilsystem och tillfälliga filer	Uppgiftsspecifik container eller Pod	Förbrukningsbara; kan stoppas eller återskapas
Förhandsvisningsprocess	Uppgiftens aktiva sandlåda	Tillfällig; behålls bara så länge den har verifierats som fungerande
Osparat redigeringsutkast	Webbläsarsessionens lagring	Tillfälligt bekvämlighetstillstånd för webbläsarsessionen

Varje uppgift får ett servergenererat UUID. Namnen på sandlådan och arbetsytan härleds i serverdelen och godtas aldrig från en webbläsarbegäran. Libre WebUI skapar körtidsresurserna med etiketter för hantering och uppgiftsägarskap. Innan en resurs återanvänds eller raderas verifieras uppgiftsägaretiketten, och en resurs vars etikett tillhör en annan uppgift avvisas.

Sandlådor förbereds vid behov. Filhjälpåtgärder stoppar en annars inaktiv sandlåda, kommandon stoppar sandlådan när de har slutförts och en verifierad förhandsvisning kan hålla den igång så att användaren kan granska programmet. Den beständiga arbetsytan monteras på nytt när samma uppgiftssandlåda startas om eller återskapas.

Administratörer kan definiera namngivna körtidspolicyer på fliken User Management i Inställningar: förinställningar som kombinerar en körtidsavbildning, minnes-/CPU-/PID-gränser, en arbetsytestorlek (Kubernetes), en tidsgräns för inaktivitet, ett nätverksstandardvärde och två funktionsomkopplare — Work Computer (GUI + browser), som ger policyns uppgifter ett virtuellt skrivbord och fliken Screen, samt Allow screen takeover, som avgör om en människa får ta över skärmarna (och, eftersom undervisning spelas in genom ett övertagande, om undervisningsläget är tillgängligt). En uppgift som skapas under en policy körs med den konfigurationen. Varje fält som policyn lämnar tomt ärver driftsättningens globala värden, och om en policy raderas återgår dess uppgifter till dessa globala värden nästa gång deras containrar återskapas. Policyer justerar bara resurser och dessa funktionsomkopplare. Härdningsprofilen (utan rotbehörighet, skrivskyddat rotfilsystem, borttagna kapaciteter och nätverksisolering) är inte ett policyfält och kan inte försvagas per policy.

WORK_RUNTIME_IDLE_TIMEOUT_MS begränsar hur länge förhandsvisningens respit varar. När variabeln är angiven stoppar en återkommande kontroll alla sandlådor där ingen aktivitet har förekommit — inget kommando har slutförts, ingen terminal har anslutits och ingen förhandsvisning har begärts via den signerade proxyn — under så många millisekunder, vilket frigör deras platser. Ett stopp är billigt och arbetsytan består, så en förhandsvisning som blivit inaktiv startar helt enkelt om vid nästa användning. Standardvärdet (0) behåller det nuvarande beteendet: en förhandsvisning körs tills den stoppas uttryckligen.

När serverdelen startar markeras aktiva körningar som misslyckade och förhandsvisningstillståndet rensas — agentloopen och förhandsvisningsproxyn dog med processen och kan inte återupptas. Den valda drivrutinen listar därefter sina hanterade containrar eller Pod-resurser i en enda etiketterad fråga. Körande sandlådor som ägs av kända uppgifter stoppas eftersom ett avbrutet kommando fortfarande kan köras utan övervakare. Sandlådor som redan är stoppade lämnas oförändrade, och hanterade sandlådor vars uppgiftsrad inte längre finns tas bort. Ägarskapet kommer från uppgiftsetiketten, aldrig från resursnamnet. Borttagning av föräldralösa resurser förutsätter att en enda Libre WebUI-instans äger ett körtidsnamnområde eller en Docker-demon. Rikta inte två instanser mot samma Work-resurser. Om drivrutinen inte kan bevisa att städningen är slutförd förblir Work låst i säkert läge, försöker igen var tionde sekund och blockerar nya ändrande åtgärder tills körtidsåtkomsten har återställts.

Nätverksbeteende

Kontrollera den valda nätverkspolicyn

Uppgifter utan en namngiven körtidspolicy startar med nätverk aktiverat. En administratör kan definiera en namngiven policy vars standardvärde för nätverk är avstängt, och den som skapar uppgiften kan välja den policyn. Det finns ingen oberoende nätverksomkopplare per uppgift, och om policyn ändras senare måste sandlådan återskapas innan den nya körtidskonfigurationen börjar gälla.

Med Docker-serverdelen ansluts nätverksaktiverade uppgifter till ett särskilt hanterat bryggnätverk (libre-webui-work som standard, WORK_NETWORK_NAME) som skapas med kommunikation mellan containrar inaktiverad (com.docker.network.bridge.enable_icc=false). Det får två följder:

• en Work-sandlåda kan inte öppna anslutningar till en annan Work-sandlåda; och
• en Work-sandlåda kan inte nå driftsättningens egna containrar på Dockers gemensamma standardbrygga, däribland en samlokaliserad databas- eller Ollama-container som inte avsiktligt har publicerats.

Libre WebUI vägrar starta en nätverksaktiverad uppgift om ett nätverk med det konfigurerade namnet redan finns men inte är det hanterade nätverket, i stället för att tyst ansluta sandlådor till operatörens nätverk.

I Kubernetes har sandlådans Pod samma etikett för nätverksaktivering. Helm-diagrammet installerar en NetworkPolicy som nekar allt som standard, endast tillåter inkommande trafik för förhandsvisning och bara tillåter internettrafik utåt för nätverksaktiverade Pod-resurser, med undantag för konfigurerade work.networkPolicy.blockedEgressCidrs. NetworkPolicy fungerar bara när klustrets CNI verkställer den. Se Kubernetes-guiden.

Utgående trafik till omvärlden är fortfarande tillåten eftersom paketnedladdningar, Git-åtgärder på fjärrsystem och externa API:er gör Work användbart. Det här är ingen brandvägg för utgående trafik. Genererad kod kan fortfarande nå:

• tjänster på Docker-värden;
• system i värdens lokala nätverk;
• internettjänster; och
• slutpunkter för infrastrukturmetadata, beroende på driftsättningen.

Kopplingspunkter för utgående trafikpolicy

Använd följande i kombination för en striktare gräns:

• WORK_RUNTIME_DNS (Docker) — kommaavgränsade IPv4-/IPv6-adresser till resolverare som tvingas på varje nätverksaktiverad sandlåda (--dns). Genom att peka detta på en filtrerande resolverare får du namnpolicyns listor över tillåtna och nekade adresser utan att ändra Libre WebUI. Poster som inte är adresser avvisas och loggas, så värdet kan aldrig injicera ytterligare Docker-flaggor.
• Brandväggsregler på värden eller uppströms (Docker) för det hanterade bryggnätverkets undernät, vilket är stabilt eftersom nätverket är namngivet och hanterat.
• WORK_NETWORK_NAME (Docker) pekat på ett nätverk som du skapar i förväg med egna drivrutinsalternativ. Libre WebUI kontrollerar att nätverket har både den hanterade etiketten och alternativet som inaktiverar ICC, så skapa det med båda.

DNS-filtrering begränsar namnuppslagning, inte utgående trafik till rena IP-adresser. En driftsättning som måste garantera att direkt utgående IP-trafik blockeras behöver även brandväggsregler på värd-, kluster- eller uppströmsnivå.

Utgå inte från att kod i Work hindras från att överföra data. Ge bara betrodda användare åtkomst till Work. Använd en namngiven körtidspolicy med nätverket inaktiverat när en uppgift ska starta utan nätverk. Det finns ingen miljövariabel för hela driftsättningen som ändrar standardpolicyn.

Nätverksåtkomst tillför inga autentiseringsuppgifter. Libre WebUI monterar inte SSH-nycklar, molnautentiseringsuppgifter, webbläsarprofiler, värdens hemkatalog eller Docker-socketen i uppgiftscontainrar. Kod kan ändå överföra autentiseringsuppgifter eller hemligheter som en användare eller modell skriver i /workspace.

Denna sandlådetrafik är skild från modelltrafiken. Begäranden till Ollama och plugin skickas alltid av Libre WebUI:s serverdel till den uttryckligen valda leverantörsrutten.

Sandlådans säkerhetsgräns

En Docker-container för Work:

• körs som UID/GID 1000:1000 utan rotbehörighet;
• använder /workspace som arbetskatalog;
• monterar endast den valda uppgiftens namngivna volym på /workspace;
• använder ett skrivskyddat rotfilsystem och ett begränsat tillfälligt filsystem på /tmp;
• tar bort alla Linux-kapaciteter;
• aktiverar no-new-privileges;
• är oprivilegierad och använder en init-process;
• tillämpar gränser för CPU, minne, processer, kommandotid och utdata;
• låser växlingsutrymmet till minnesgränsen (--memory-swap är lika med --memory), så minnestaket inte kan kringgås genom växling;
• ansluter till det hanterade sandlådenätverket med kommunikation mellan containrar inaktiverad, eller inte till något nätverk alls; och
• publicerar endast den konfigurerade förhandsvisningsporten till en loopback-port på värden som Docker tilldelar.

Allt detta verifieras på nytt mot docker inspect innan en container återanvänds, och hela uppsättningen hashas i containeretiketten ai.libre-webui.policy. En container vars policy är äldre än en Libre WebUI-uppgradering förstörs och återskapas i stället för att återanvändas, så en härdningsändring når befintliga uppgifter automatiskt.

Kubernetes-drivrutinen tillämpar motsvarande säkerhetskontext för Pod-resursen: UID/GID utan rotbehörighet, skrivskyddat rotfilsystem, RuntimeDefault-seccomp, ingen behörighetseskalering, alla kapaciteter borttagna, begränsad tillfällig lagring, resursgränser, ingen ServiceAccount-token och en uppgiftsägd PVC på /workspace. Den verifierar uppgiftsetiketter och policyfingeravtrycket innan en Pod eller PVC återanvänds eller raderas.

Sökvägsvalideringen avvisar absoluta sökvägar, traverseringssegment, omvända snedstreck, NUL-tecken och alltför långa sökvägar. Filhjälparna följer verkliga sökvägar och avvisar symboliska länkar som tar sig ut. Skrivningar använder en tillfällig fil och atomärt namnbyte.

Dessa kontroller minskar risken för oavsiktlig exponering av värden, men de gör inte Work till en virtuell dator eller en säker miljö för analys av skadlig kod. Containrar delar körtidsvärdens kärna. En sårbarhet i Docker, Kubernetes, körtiden, avbildningen, ett beroende eller kärnan kan passera den avsedda gränsen.

Dockers namngivna volymer har ingen oberoende diskkvot. Ett genererat projekt eller en paketinstallation kan fylla Dockers lagring, så övervaka volymtillväxten och tillämpa lagringsgränser på värdnivå. Kubernetes begär en PVC-storlek; den faktiska kvotverkställigheten beror på den valda lagringsetableraren.

Checklista för Docker-härdning i produktion

Den här checklistan gäller särskilt Docker-serverdelen. Kubernetes-operatörer bör även validera Helm-diagrammets namnrymdsavgränsade RBAC, Pod-säkerhetskontext, lagringsklass och CNI-verkställighet av NetworkPolicy enligt beskrivningen i Kubernetes-guiden.

Programmet kan ange containerflaggor, validera sökvägar till arbetsytor och skydda sitt eget API. Det kan inte verkställa värdens brandväggspolicy, kvoter i lagringsdrivrutinen eller behörighetsnivån hos Docker-demonen som det får åtkomst till. Behandla detta som uttryckligt driftsättningsarbete för en privat klientinstans.

1. Isolera Docker-kontrollen

Libre WebUI:s huvudcontainer behöver styra demonen för att skapa och inspektera Work-containrar. En monterad Docker-socket är därför en autentiseringsuppgift för kontrollplanet, inte en vanlig datamontering: om webbprogrammet komprometteras kan även Docker-värden komprometteras.

Den första riskminskningen ingår i detta kodförråd: docker-compose.socket-proxy.yml håller socketen helt utanför Libre WebUI-containern. En socketproxy håller /var/run/docker.sock på ett internt nätverk och vidarebefordrar endast de API-delar som Work använder — containrar, avbildningar, volymer, nätverk, exekvering och information — medan slutpunkter för swarm, hemligheter, konfigurationer, bygge, incheckning och system nekas innan de når demonen. Libre WebUI pekas dit med DOCKER_HOST=tcp://docker-socket-proxy:2375 och behöver varken socketmontering eller medlemskap i socketgruppen. Kommandoradsgränssnittet, den interaktiva terminalen och Docker-diagnostiken använder alla den slutpunkten. Proxyn begränsar API-ytan, men inte spridningseffekten för de slutpunkter som den vidarebefordrar: den som kan skapa containrar kan fortfarande bind-montera värdsökvägar, så gränsen nedan är fortfarande viktig.

För en starkare produktionsgräns bör Libre WebUI och dess Work-demon köras på en särskild virtuell dator utan andra arbetslaster. Ännu starkare är att ge Work en egen rotlös Docker-demon eller en separat körtidsvärd och endast exponera den demonen för Libre WebUI. Verifiera filägarskap, förhandsvisningsdirigering, städning och terminalstöd mot den demonen före lansering. Att bara montera samma rotbehöriga värdsocket som skrivskyddad gör inte Docker-API:et skrivskyddat.

2. Blockera hanteringsåtkomst från sandlåda till värd

Om kommunikation mellan containrar inaktiveras hindras Work-sandlådor från att nå varandra, men det hindrar dem inte från att nå tjänster som lyssnar på Docker-värden. Inspektera den faktiska hanterade bryggan och dess undernät i stället för att anta en adress:

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

Använd värdens beständiga brandväggshanterare för att neka trafik som kommer från bryggan till värdens hanteringstjänster, särskilt SSH, Docker-API:et, databaser och övervaknings-/administrationsportar. Testa regeln från en förbrukningsbar container som är ansluten till libre-webui-work, testa tillåtna paketnedladdningar och gör därefter regeln beständig. Dockers kedja DOCKER-USER styr vidarebefordrad trafik. Trafik vars destination är själva Docker-värden kan dessutom behöva en regel för INPUT eller en indatakoppling på bryggans gränssnitt.

3. Begränsa utgående destinationer

Blockera slutpunkter för molnmetadata, privata infrastrukturnät och klienternas lokala nätverk från Work-undernätet om inte ett projekt uttryckligen behöver dem. Kombinera en filtrerande resolverare via WORK_RUNTIME_DNS med brandväggsregler på värden eller uppströms. DNS-filtrering kan kringgås med en bokstavlig IP-adress. En HTTP-proxy räcker inte heller när godtyckliga kommandon kan öppna direkta nätverksanslutningar; verkställ dirigeringspolicyn utanför containern.

Behåll separata namngivna körtidspolicyer när klienter behöver olika beteenden, till exempel en körtid utan nätverk, en körtid som bara når paketregister och en körtid med öppen utgående trafik. Den namngivna policyn styr om Libre ansluter sandlådenätverket. Externa brandväggs- och proxyregler verkställer fortfarande begränsningar på destinationsnivå för en nätverksaktiverad policy.

4. Verkställ verkliga lagringskvoter

Gränser för CPU, minne, växlingsutrymme och PID begränsar inte den namngivna volymen. Innan flera klienter betjänas ska du välja ett lagringssystem med verkställbara kvoter per arbetsyta, till exempel XFS-projektkvoter, kvotstödda logiska volymer eller en volym-/PVC-drivrutin med storleksgräns. Dockers vanliga local-drivrutin på ett normalt ext4-filsystem får inte en tillförlitlig kvot per volym bara för att ett storleksvärde dokumenteras.

Övervaka både varje volym med ai.libre-webui.managed=true och Dockers datarot, varna innan filsystemet är fullt och testa feltillståndet. En räknare i gränssnittet eller en regelbunden du-kontroll kan varna, men utgör ingen verkställande gräns eftersom en container kan förbruka det återstående diskutrymmet mellan kontrollerna.

5. Verifiera den driftsatta policyn

Efter varje ändring av en avbildnings- eller demonpolicy ska du skapa en förbrukningsbar Work-uppgift och verifiera det faktiska tillståndet med docker inspect: UID utan rotbehörighet, skrivskyddad rot, alla kapaciteter borttagna, no-new-privileges, minnes-/växlings-/CPU-/PID-gränser, endast uppgiftsvolymen monterad och förväntat nätverk. Kontrollera också att Libre WebUI:s huvudcontainer bara har de avsedda monteringarna och att offentlig inkommande trafik når programmet genom den autentiserade omvända proxyn eller tunneln — inte genom en oavsiktligt publicerad Docker- eller förhandsvisningsport.

Förhandsvisningens säkerhet och nåbarhet

För en Docker-uppgift publicerar drivrutinen den konfigurerade förhandsvisningsporten till en dynamiskt tilldelad port på serverdelens loopback. För Kubernetes riktar serverdelen i klustret sig direkt till sandlådans Pod-IP. Modellen och webbläsaren kan inte välja ett godtyckligt uppströmsmål. Libre WebUI signerar en behörighets-URL för den exakta uppgiften och slutpunkten, verifierar vid varje begäran att förhandsvisningen fortfarande körs och proxar HTTP- och WebSocket-trafik genom /api/work/previews. Om förhandsvisningen stoppas eller startas om återkallas den gamla URL:en.

Svar från förhandsvisningen tar bort Libre WebUI-autentiseringsuppgifter och cookies från uppströmsservern. HTML begränsas både av en iframe-sandlåda och svarens CSP, som tillåter skript, formulär, modala dialogrutor och nedladdningar utan att ge åtkomst till samma ursprung. CSP:n skyddar även en förhandsvisning som öppnas i en separat flik. Genererad programkod är fortfarande opålitlig och kan använda utgående nätverkstrafik för att överföra allt den kan läsa från sin egen arbetsyta eller webbläsarens indata. Behandla URL:en till en aktiv förhandsvisning som en kortlivad hemlighet och dela den inte.

Eftersom webbläsaren läser in proxyn på Libre WebUI:s eget offentliga ursprung fungerar fjärrwebbläsare och omvända HTTPS-proxyservrar utan att Docker-portar eller Pod-IP:n exponeras och utan att blockering av blandat innehåll utlöses. Omvända proxyservrar måste bevara WebSocket-uppgraderingar för /api/work/previews/; den medföljande Nginx-konfigurationen gör det.

Huvudprogrammet tillåter endast sitt eget ursprung och Cloudflare Turnstile som ramkällor. Förhandsvisningssvar går förbi huvudprogrammets Helmet-policy så att de kan strömma begärandetexter och tillämpa den snävare sandlådepolicyn som beskrivs ovan. Policyn för inbäddning över ursprungsgränser förblir inaktiverad eftersom genererade utvecklingsservrar normalt inte skickar kompatibla resurshuvuden.

Driftsättningsmatris

Tillgängligheten för Work beror på datorn och processen som kör Libre WebUI:s serverdel, inte enbart på webbläsaren eller skrivbordsgränssnittet.

Driftsättning	Work-körningar och filer	Inbäddad förhandsvisning
npx libre-webui på en lokal dator	Stöds när Docker är installerat, körs och kan anropas av serverdelsanvändaren.	Stöds genom den signerade proxyn på programmets ursprung.
Källkodsutveckling på en lokal dator	Stöds med samma krav på Docker och leverantör.	Stöds genom utvecklings-API:ets ursprung på port 3001.
Electron-skrivbordsklient	Villkorligt. Electron använder en extern Libre WebUI-serverdel och tillhandahåller ingen separat Work-körtid.	Stöds genom den serverdelens signerade proxy-URL.
Serverdel på fysisk server eller VM på fjärrvärd	Körningar, filer och leverantörsanrop fungerar när Docker är tillgängligt på värden.	Stöds när den offentliga omvända proxyn bevarar HTTP- och WebSocket-trafik.
Standardkonfigurationen Docker Compose i kodförrådet	Stöds som standard på Docker Desktop: avbildningen innehåller Dockers kommandoradsgränssnitt, Compose monterar värdens Docker-socket och Work-portarna går via host.docker.internal. Inbyggd Docker Engine behöver dessutom en nåbar icke-offentlig WORK_PREVIEW_BIND.	Stöds genom samma offentliga Libre WebUI-ursprung.
Aktuell Kubernetes-/Helm-driftsättning	Stöds med --set work.enabled=true: sandlådor körs som Pod-resurser med PVC-arbetsytor (körningar, filer, kommandon, Git, interaktiva terminaler samt Work Computer-skärm och ljud på Pod-IP-adressen), under en namnrymdsavgränsad Role och NetworkPolicy-regler som nekar som standard — ingen Docker-socket någonstans. Se Kubernetes-guiden.	Stöds när serverdelen körs i klustret: den signerade proxyn riktas direkt mot sandlådans Pod-IP.

Köra Work när Libre WebUI självt finns i Docker

Alla Compose-filer i kodförrådet aktiverar Work: avbildningen innehåller Dockers kommandoradsgränssnitt och Compose-filen monterar /var/run/docker.sock. Docker Desktop fungerar med de medföljande routningsstandarderna. Inbyggd Docker Engine behöver dessutom att WORK_PREVIEW_BIND anges till ett icke-offentligt värdgränssnitt som kan nås från syskoncontainrar, så som beskrivs nedan.

Work styr värddemonen genom den socketen, så uppgiftscontainrarna är syskon till Libre WebUI-containern och inte dess barn. De visas i docker ps på värden och städas enligt samma livscykelregler som vid en inbyggd installation.

Om Docker-socketen monteras i ett webbprogram får containern kontroll över Docker-värden som motsvarar rotbehörighet. Work kan inte fungera utan den, så Libre WebUI aktiverar detta i stället för att leverera en funktion som tyst inte gör någonting. Följden är uttrycklig: varje Libre WebUI-administratör är i praktiken administratör för Docker-värden. Operatörerna ansvarar för följderna för demonens säkerhet, nätverk, livscykel, säkerhetskopiering och åtkomstkontroll. Ta bort raden /var/run/docker.sock från Compose-filen för att stänga av Work; inget annat är beroende av den.

Om du vill behålla Work utan att ge socketen till webbprogrammet ska du i stället driftsätta med docker-compose.socket-proxy.yml: en socketproxy på ett internt nätverk håller socketen och vidarebefordrar endast de API-delar som Work använder, och Libre WebUI når den genom DOCKER_HOST. Se Isolera Docker-kontrollen för vad denna gräns omfattar och inte omfattar.

Tre villkor måste vara uppfyllda, och Work-panelen anger vilket som inte är det:

1. Dockers kommandoradsgränssnitt måste finnas i avbildningen. Det ingår i den officiella avbildningen. En anpassad avbildning behöver docker-cli eller att WORK_DOCKER_COMMAND pekar på ett sådant. Annars visas: The "docker" CLI is not installed….
2. Socketen måste vara monterad. Annars visas: No Docker daemon is reachable….
3. Serverdelsanvändaren måste tillhöra socketens grupp. Avbildningen körs som nodejs (uid 1001) och socketen ägs normalt av root eller docker, så Compose skickar group_add: ['${DOCKER_GID:-0}']. Standardvärdet passar Docker Desktop; en Linux-värd behöver sitt eget grupp-ID. Annars visas: 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

Uppgifternas förhandsvisningsportar förblir bundna till Docker-värdens loopback. Libre WebUI exponerar varje aktiv förhandsvisning genom en signerad proxy-URL med samma ursprung, inklusive HTTP-resurser och WebSocket-uppgraderingar. Detta fungerar bakom HTTPS och fjärrtunnlar utan att tillfälliga Docker-portar öppnas mot nätverket. Förhandsvisningsdokument får en restriktiv sandlådepolicy i webbläsaren, och om en förhandsvisning stoppas eller startas om återkallas dess tidigare URL.

När serverdelen själv körs i Docker kan olika adresser användas för publicering och anslutning. Behåll WORK_PREVIEW_BIND=127.0.0.1 så att de tillfälliga portarna inte exponeras, och ange WORK_DOCKER_PUBLISHED_HOST som adressen till Docker-värden som kan nås från serverdelscontainern (host.docker.internal i Docker Desktop). De medföljande Compose-profilerna anger båda värdena och mappar värdnamnet. Inbyggda Linux-driftsättningar måste åsidosätta WORK_PREVIEW_BIND med Docker-bryggans gateway (eller ett annat uttryckligen nåbart, icke-offentligt värdgränssnitt). Enbart mappning av host.docker.internal gör inte en lyssnare på värdens loopback nåbar. Bind aldrig dessa råa tillfälliga portar till 0.0.0.0.

Samtidigheten har separata tak: WORK_MAX_ACTIVE_RUNTIMES_PER_USER har standardvärdet 2 och WORK_MAX_ACTIVE_RUNTIMES_GLOBAL har 3, så en administratör kan köra en andra uppgift medan den första är upptagen. Funktionssvaret rapporterar både gränserna och den aktuella beläggningen. Höj dem om värden har tillräckligt med minne och CPU.

För Kubernetes installerar du diagrammet med work.enabled=true i stället för att exponera en nods körtidssocket. Diagrammet skapar avgränsad RBAC, sandlådans namnrymd, nätverkspolicyer och Pod-/PVC-konfigurationen som beskrivs i Kubernetes-guiden.

Körtidskonfiguration

Work läser följande variabler i serverdelsprocessen:

Variabel	Standardvärde	Syfte
WORK_RUNTIME_BACKEND	docker	Sandlådedrivrutin: docker eller kubernetes
WORK_RUNTIME_IMAGE	node:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3	Avbildning som används för uppgiftssandlådor
WORK_DOCKER_COMMAND	docker	Körbar fil för Docker-serverdelens kommandoradsgränssnitt
WORK_COMMAND_TIMEOUT_MS	120000	Standardtidsgräns för kommandon
WORK_MAX_OUTPUT_CHARS	50000	Största mängd insamlade kommando-/sökutdata
WORK_MAX_AGENT_ROUNDS	48	Leverantörsoberoende budget för modell-/verktygsomgångar per körning
WORK_MEMORY_LIMIT	2g	Minnesgräns per container
WORK_CPU_LIMIT	2	CPU-gräns per container
WORK_PIDS_LIMIT	256	Processgräns per container
WORK_PREVIEW_PORT	4173	Port som programmet måste lyssna på inuti containern
WORK_PREVIEW_BIND	127.0.0.1	Värdgränssnitt där förhandsvisningsporten publiceras
WORK_DOCKER_PUBLISHED_HOST	samma som WORK_PREVIEW_BIND	Värd/IP som serverdelen anropar för Docker-publicerade Work-portar
WORK_COMPUTER_SCREEN_PORT	6080	WebSocket-port i containern för skärmbryggan
WORK_COMPUTER_AUDIO_PORT	6081	WebSocket-port i containern för ljudbryggan
WORK_RUN_LEASE_WAIT_MS	60000	Hur länge en körning väntar ut en tillfällig innehavare av körtidslåset
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL	3	Samtidiga containerstödda uppgifter per Libre WebUI-instans
WORK_MAX_ACTIVE_RUNTIMES_PER_USER	2	Samtidiga containerstödda uppgifter per administratör
WORK_MAX_TASKS_GLOBAL	500	Gräns för beständiga Work-uppgifter per Libre WebUI-instans
WORK_MAX_TASKS_PER_USER	100	Gräns för beständiga Work-uppgifter per administratör
WORK_NETWORK_NAME	libre-webui-work	Hanterat sandlådebryggnätverk för nätverksaktiverade uppgifter
WORK_RUNTIME_DNS	inte angivet	Kommaavgränsade resolverar-IP:n som tvingas på nätverksuppgifter
WORK_DOCKER_SOCKET	DOCKER_HOST om unix:// eller tcp://, annars /var/run/docker.sock	Docker Engine-slutpunkt för interaktiva terminaler
WORK_TERMINAL_MAX_SESSIONS_PER_TASK	2	Samtidiga interaktiva terminaler per uppgift
WORK_TERMINAL_IDLE_TIMEOUT_MS	900000	Inaktivitetstid innan en terminalsession stängs
WORK_RUNTIME_IDLE_TIMEOUT_MS	0 (inaktiverat)	Stoppa en sandlåda efter så lång inaktivitet (även förhandsvisningar)
WORK_K8S_NAMESPACE	libre-webui-work	Kubernetes-namnrymd för sandlådans Pod/PVC
WORK_K8S_STORAGE_CLASS	klustrets standardvärde	StorageClass för Kubernetes-arbetsytans PVC
WORK_K8S_WORKSPACE_SIZE	5Gi	Standardstorlek per Kubernetes-PVC för varje uppgift
WORK_K8S_POD_READY_TIMEOUT_MS	900000	Längsta väntan på att en sandlåde-Pod blir klar
WORK_K8S_POD_GONE_TIMEOUT_MS	60000	Längsta väntan på att en raderad sandlåde-Pod försvinner

Använd en fast avbildningsversion eller ett innehållssammandrag i produktion. En ändringsbar avbildningstagg kan ändra både tillgängliga kommandoradsverktyg och säkerhetsgränsen utan att Libre WebUI ändras.

Åtgärder för körning, förhandsvisning, filhjälpare, kommandon och återskapande av sandlådor delar samma kapacitetsräkning i processen. En kapslad åtgärd på en uppgift som redan räknas räknas inte som ytterligare en uppgift. Begäranden över en gräns för uppgifts- eller körtidstillträde returnerar HTTP 429.

Fasta protokoll- och gränssnittsgränser

Post	Gräns
Meddelande för ny uppgift eller körning	65 536 tecken och UTF-8-byte
Modellidentifierare när uppgift skapas/uppdateras	500 tecken och UTF-8-byte
Pluginleverantörens ID	200 tecken
Aktiva körningar per uppgift	1
Kommandotext	20 000 tecken
Kommandotidsgräns som ett verktyg begär	1 till 600 sekunder
Förhandsvisningens beredskap	15 sekunder
Filläsning/-skrivning	2 000 000 byte UTF-8-text
Direkt kataloglista	De första 1 000 posterna
Meddelandesida	Upp till 200 meddelanden och 1 000 000 byte
Enskilt beständigt meddelande	100 kB
Samtalskontext som skickas till en modell	De senaste 30 användar-/assistentmeddelandena, upp till 256 kB
Beständiga verktygsutdata	Cirka 20 000 tecken från källan plus en markör
Direkt syntaxmarkering i redigeraren	8 000 tecken och 400 rader
Formatering i webbläsaren	100 000 tecken och 4 000 rader
Utdata från Git-status	2 000 000 insamlade tecken
Utdata från Git-diff	600 000 insamlade tecken
Git-historik	20 lokala incheckningar
Sökvägar i en Git-begäran om mellanlagring	200
Git-incheckningsmeddelande	4 000 tecken
Agentloop, varje leverantörsrutt	48 omgångar som standard, konfigureras med WORK_MAX_AGENT_ROUNDS
Säkerhetsbudget för verktygsanrop	max(128, configured rounds × 8) anrop

Filåtkomst gäller UTF-8-text. Den integrerade redigeraren är inte avsedd för binära filer, och en fil som är större än 2 MB kan inte öppnas genom Works fil-API.

API-sammanfattning

Alla slutpunkter finns under /api/work och kräver autentisering samt aktuell Work-åtkomst från databasen. Som standard är Work endast tillgängligt för administratörer; en administratör kan öppna vanliga uppgiftsåtgärder för aktiva användare. Val av värdmapp och administrativa slutpunkter för policy/åtkomst förblir endast tillgängliga för administratörer.

Metod	Sökväg	Syfte
GET	/capabilities	Tillgänglighet och gränser för vald körtid/leverantör
GET	/tasks	Lista den aktuella administratörens uppgifter
POST	/tasks	Skapa en uppgift och dess första asynkrona körning
GET	/tasks/:id	Läs in uppgiftstillstånd och senaste meddelanden
GET	/tasks/:id/messages	Sidindela äldre meddelanden
PATCH	/tasks/:id	Byt namn eller ändra den uttryckliga modellrutten
DELETE	/tasks/:id	Ta bort uppgiften och den beständiga arbetsytan
POST	/tasks/:id/runs	Starta en uppföljande körning
POST	/tasks/:id/messages	Skicka ett meddelande till agenten under aktiv körning
GET	/tasks/:taskId/runs/:runId/events	Strömma autentiserade livehändelser för körningen via SSE
POST	/tasks/:id/cancel	Avbryt den aktiva körningen
GET	/tasks/:id/approvals	Väntande godkännanden plus uppgiftens Auto Review-status
PUT	/tasks/:id/approvals	Slå på eller av godkännanden per uppgift
POST	/tasks/:id/approvals/:approvalId	Avgör ett väntande godkännande (tillåt en gång/alltid, neka)
DELETE	/tasks/:id/approval-rules/:ruleId	Ta bort en Always-allow-regel
GET	/computer/setup	Konfigurationsstatus för Work Computer (administratör)
POST	/computer/setup	Bygg GUI-avbildningen och skapa policyn (administratör)
POST	/tasks/:id/computer/start	Starta uppgiftens Work Computer-session
GET	/tasks/:id/computer/control	Vem som styr skärmen; agentens begäran om övertagande
POST	/tasks/:id/computer/control	Ta över skärmen (eller förnya kontrollen)
DELETE	/tasks/:id/computer/control	Lämna tillbaka skärmen till agenten
POST	/tasks/:id/computer/teach	Spara en inspelad demonstration som en inlärd färdighet
POST	/tasks/:id/computer/anchor	Slå upp elementet under ett inspelat klick
POST	/computer/skills/:slug/trace	Lägg till en rad för lyckad/misslyckad i en inlärd färdighet
GET	/tasks/:id/files	Lista en katalog i arbetsytan
GET	/tasks/:id/file	Läs en textfil i arbetsytan
PUT	/tasks/:id/file	Spara en textfil i arbetsytan
GET	/tasks/:id/git	Läs skyddad lokal Git-status och historik
GET	/tasks/:id/git/diff	Läs en begränsad lokal diff
POST	/tasks/:id/git/init	Initiera lokal Git
POST	/tasks/:id/git/stage	Mellanlagra uttryckliga sökvägar i arbetsytan
POST	/tasks/:id/git/commit	Checka in mellanlagrade ändringar
POST	/tasks/:id/git/branches	Skapa en lokal gren
POST	/tasks/:id/git/switch	Växla till en befintlig ren lokal gren
POST	/tasks/:id/preview/start	Starta den hanterade förhandsvisningen
POST	/tasks/:id/preview/stop	Stoppa den hanterade förhandsvisningen

Uppgifts-ID:t kontrolleras alltid mot den autentiserade ägaren. Aktuell kontostatus, roll och Work-åtkomstpolicy läses från databasen vid varje begäran, så ett återkallande börjar gälla även om en äldre JWT innehåller inaktuella rollanspråk.

Schemat för uppgiftsuppdatering behåller fältet networkEnabled i serverdelen för intern kompatibilitet. Det exponeras inte som en oberoende Work-kontroll i gränssnittet. Välj en namngiven körtidspolicy med avsett nätverksstandardvärde när uppgiften skapas. Använd inte det obearbetade fältet som ett beständigt konfigurations-API.

Radering, kontoändringar och säkerhetskopiering

Radera en uppgift

En uppgift raderas avsiktligt på ett destruktivt sätt:

1. Serverdelen markerar uppgiften som under avveckling så att ingen ny ändrande åtgärd kan börja.
2. En aktiv körning avbryts och uppgiftens sandlåda stoppas.
3. Libre WebUI validerar etiketter för uppgiftsägarskap på körtidsresurserna.
4. Containern/Pod-resursen och den namngivna volymen/PVC:n tas bort.
5. Databasuppgiften raderas, vilket kaskadraderar dess körningar och meddelanden.
6. Webbläsarutkast för uppgiften rensas efter att API-anropet lyckats.

Om körtidsstädningen misslyckas behåller Libre WebUI uppgiftsposten i databasen och returnerar ett fel så att operatören kan reparera Docker- eller Kubernetes-serverdelen och försöka igen. Metadata raderas inte tyst medan en ospårad sandlåda eller arbetsyta lämnas kvar.

Att stoppa en körning eller förhandsvisning skiljer sig från radering: körningen stoppas, men den namngivna volymen och samtalet bevaras.

Nedgradering av administratör och radering av användare

När en administratör nedgraderas sparar Libre WebUI rollåterkallelsen innan systemet förlitar sig på körtidsstädningen. Varje senare Work-begäran kontrollerar den aktuella rollen och åtkomstläget. Serverdelen pausar sedan användarens Work-uppgifter om den nya rollen inte längre har åtkomst och försöker avbryta aktiva körningar samt stoppa deras sandlådor. Om städningen misslyckas förblir åtkomsten återkallad, och rolluppdateringen rapporterar felet så att en operatör kan återställa körtiden och försöka igen.

När en annan användare raderas tas först alla användarens hanterade Work-resurser bort. Om extern körtidsstädning misslyckas behålls användarposten så att en administratör kan försöka igen i stället för att förlora ägarskapsmetadata som behövs för säker städning.

Säkerhetskopiera hela uppgiften

En fullständig Work-säkerhetskopia behöver båda följande:

• Libre WebUI-databasen, som innehåller uppgiftsägarskap, Docker-resursnamn eller Kubernetes-resursnamn, leverantörsdirigering, körningar, meddelanden och aktivitet; samt
• varje Docker-volym eller Kubernetes-PVC med etiketten ai.libre-webui.managed=true, som innehåller Work-filerna.

De förbrukningsbara containrarna och förhandsvisningsprocesserna behöver inte säkerhetskopieras. För en konsekvent säkerhetskopia ska du stoppa ny Work-aktivitet och serverdelen innan databasen och uppgiftsarbetsytorna avbildas. Följ proceduren för ögonblicksbilder av Docker-volymer eller Kubernetes-lagringsleverantören för den serverdel som används.

Återställ databasen och dess motsvarande arbetsytor tillsammans. Återskapa varje volym eller PVC under exakt det namn som registrerats i databasen och återställ dess metadata för uppgiftsägarskap, däribland ai.libre-webui.task=<task UUID> och ai.libre-webui.managed=true. Om bara filer kopieras bevaras inte Docker- eller Kubernetes-etiketter. Om bara databasen återställs skapas uppgiftsposter vars filer saknas. Om bara lagringen återställs förloras uppgiftsägarskapet och de genererade resursnamn som Libre WebUI använder för att hitta och validera den.

Om installationen även använder krypterade autentiseringsuppgifter för leverantörer ska du följa Libre WebUI:s huvudsakliga vägledning för säkerhetskopiering av datakatalogen och krypteringsnyckeln.

Lokalisering och arabisk höger-till-vänster-layout

Hela Work-gränssnittet är översatt till alla 25 språk som stöds: engelska, arabiska, bengali, tjeckiska, danska, tyska, spanska, franska, hindi, indonesiska, isländska, italienska, japanska, koreanska, malajiska, nederländska, polska, portugisiska, ryska, svenska, thailändska, turkiska, ukrainska, vietnamesiska och kinesiska.

Arabiska tillämpar lang="ar" och dir="rtl" innan React renderar. Sidofältet flyttas till höger, Conversation upptar den högra sidan av skrivbordets delning, Workspace den vänstra, riktade ikoner spegelvänds, fliknavigeringen följer höger-till-vänster-ordning och storleksändring genom dragning eller tangentbord använder visuella höger-till-vänster-semantik.

Tekniskt innehåll förblir vänster-till-höger där riktningen påverkar riktigheten:

• kod och syntaxmarkering;
• filsystemsökvägar;
• modellidentifierare;
• kommandon och förhandsvisningsloggar;
• verktygsutdata och metadata; samt
• innehåll i kodblock.

Uppgiftsnamn, prompter på naturligt språk, fel, filnamn och förhandsvisningskommandon använder automatisk textriktning där det är lämpligt.

Felsökning

Körtiden är inte tillgänglig när npx används

npx libre-webui kör serverdelen på värden, men installerar inte Docker. Kör docker info som samma operativsystemsanvändare som startar Libre WebUI. Om kommandot saknas eller inte kan nå demonen ska du installera/starta Docker eller korrigera den användarens demonbehörigheter och sedan läsa in Work på nytt.

Bekräfta också att Ollama fungerar eller att minst ett aktivt plugin för komplettering/chatt har en modell och autentiseringsuppgifter konfigurerade för den aktuella administratören.

Körtiden är inte tillgänglig i Docker eller Kubernetes

En Compose-driftsättning från kodförrådet ska inte rapportera detta: avbildningen innehåller Dockers kommandoradsgränssnitt och Compose-filen monterar värdsocketen. Om det ändå händer anger panelen orsaken — kommandoradsgränssnittet saknas i en anpassad avbildning, socketmonteringen har tagits bort eller saknas, eller containeranvändaren tillhör inte socketgruppen. I det sista fallet anger du DOCKER_GID och återskapar containern. Se Köra Work när Libre WebUI självt finns i Docker.

I Kubernetes aktiverar du den inbyggda körtiden med --set work.enabled=true. Libre rapporterar då kubernetes, testar Kubernetes-API:et och kör sandlådor som Pod-resurser med PVC-arbetsytor. Montera inte en nods socket för containerkörtiden. Se Kubernetes-guiden.

Inga Work-kompatibla modeller

För Ollama ska du granska eller välja en modell som anger tools. För ett plugin ska du bekräfta följande:

• dess typ är komplettering eller chatt;
• det är aktivt;
• den exakta modellen finns i dess konfigurerade modellmappning;
• den aktuella administratören har en användbar API-nyckel; och
• fjärrmodellen implementerar verktygsanrop för leverantören.

Work dirigerar aldrig till en annan leverantör som reservlösning.

En paketinstallation eller ett Git-kommando mot fjärrsystem misslyckas

Bekräfta att uppgiftens valda namngivna körtidspolicy aktiverar nätverksåtkomst. Det finns ingen oberoende nätverksomkopplare per uppgift. Granska därefter konfigurationen för DNS, proxy, brandvägg/NetworkPolicy, register, certifikat, körtid och uppströmstjänst. Bekräfta också att den valda körtidsavbildningen innehåller kommandot som anropas.

Git-fliken är endast lokal och utför aldrig en fjärråtgärd. Använd bara terminalen eller modellens kommandoyta när uppgiftens nätverks- och autentiseringspolicy avsiktligt tillåter Git mot fjärrsystem. Klistra inte in en långlivad åtkomsttoken i en uppgiftsarbetsyta.

En körning stoppas vid en agentgräns

Modellen kan ha förbrukat den konfigurerade omgångsbudgeten eller den härledda säkerhetsbudgeten för verktygsanrop. Work begär en sista överlämning utan verktyg innan körningen avslutas, så granska det slutförda arbetet och de återstående stegen. Uppgiften förblir i Needs input, vilket är ett sluttillstånd för körningen men avsiktligt inte påstår att arbetet är slutfört. Starta en uppföljande körning för att fortsätta i samma beständiga arbetsyta, eller höj medvetet WORK_MAX_AGENT_ROUNDS för alla leverantörer om värdens och fjärrleverantörens kostnadspolicy tillåter längre körningar.

HTTP 429 när arbete startas

Instansen eller administratören har nått en tillträdesgräns för aktiva körtider eller beständiga uppgifter. Vänta tills en annan körning eller förhandsvisning stoppas, radera inaktuella uppgifter eller höj medvetet motsvarande WORK_MAX_*-inställning för en värd med tillräckliga resurser.

Förhandsvisningen blir inte klar

Bekräfta att kommandot fortsätter köras, binds till 0.0.0.0 och lyssnar på WORK_PREVIEW_PORT inom 15 sekunder. Med ett tomt kommando identifierar Work automatiskt ett dev-skript i package.json eller en vanlig index.html, även i ett enda kapslat program. Om felet rapporterar flera program eller ingen startpunkt som stöds anger du ett uttryckligt kommando i det valfria kommandofältet. Anpassade kommandon startar i /workspace, så använd cd <app-directory> && ... för ett kapslat program.

Förhandsvisningen fungerar på servern men inte i en fjärrwebbläsare

Bekräfta att driftsättningen kör ett bygge med den signerade Work-proxyn för förhandsvisning och starta sedan om förhandsvisningen för att ersätta en eventuell äldre loopback-URL. Om vanliga sidor läses in men direktuppdatering inte fungerar ska du kontrollera att den omvända proxyn och tunneln tillåter WebSocket-uppgraderingar på /api/work/previews/. Den Docker-publicerade porten ska förbli på serverdelens loopback och behöver inte öppnas i brandväggen.

Filerna finns kvar men förhandsvisningen har stoppats

Detta är förväntat efter en avbruten körning, omstart av serverdelen, uttryckligt stopp av förhandsvisningen eller misslyckade beredskapskontroller. Förhandsvisningsprocessen är tillfällig; den namngivna volymen är beständig. Öppna uppgiften igen och starta förhandsvisningen på nytt.

En fil kan inte öppnas eller sparas

Det integrerade fil-API:et godtar UTF-8-textfiler på upp till 2 MB. Om sparningen rapporterar att filen har ändrats sedan den öppnades ska du läsa in den på nytt före fortsatt redigering, så att du inte skriver över en annan ändring från modellen eller webbläsaren.

Syntaxmarkeringen växlar avsiktligt till oformaterad text över 8 000 tecken eller 400 rader. Formatering har en separat gräns på 100 000 tecken och 4 000 rader och stöder bara de dokumenterade filfamiljerna.

Work meddelar att sandlådor återställs

Start eller nedmontering kunde inte bevisa att en eller flera kända sandlådor stoppades. Work förblir låst i säkert läge och försöker igen var tionde sekund. Återställ åtkomsten till Docker-demonen eller Kubernetes-API:et och granska serverdelsloggen. Radera inte uppgiftsrader ur databasen medan deras etiketterade körtidsresurser fortfarande måste stämmas av.

Det går inte att radera en uppgift

Kontrollera att den valda körtiden går att nå. En resurskonflikt utan den förväntade etiketten ai.libre-webui.task avvisas avsiktligt i stället för att tas bort. Lös namn-/ägarskapskonflikten varsamt och försök sedan radera igen.

Säkerhetssammanfattning

Tänk på följande innan Work aktiveras för en installation:

• Som standard är Work endast tillgängligt för administratörer. Om Work öppnas för alla användare blir varje aktivt konto operatör för en sandlåda, så fatta beslutet medvetet. Arbetsytor med värdmappar förblir endast tillgängliga för administratörer i alla lägen.
• Serverdelen måste styra sin konfigurerade Docker-demon eller Kubernetes-namnrymden för sandlådor.
• Containrar minskar exponeringen av filsystemet men är inte virtuella datorer.
• Uppgifter utan en namngiven policy för frånkopplat läge har utgående nätverksåtkomst. Namngivna policyer väljer standardvärdet, medan operatören fortfarande ansvarar för begränsningar på destinationsnivå.
• Work-volymer har ingen oberoende diskkvot.
• Git-fliken är endast lokal; fjärrautentiseringsuppgifter monteras aldrig och godtas inte av dess API.
• Värdens brandväggspolicy, demonisolering, utgående begränsningar och verkliga volymkvoter förblir kontroller som operatören verkställer.
• Fjärrleverantörer tar emot begärda verktygsresultat och kan medföra flera anrop per körning.
• Förhandsvisningsportar stannar på serverdelens loopback och exponeras endast genom signerade, återkallningsbara proxy-URL:er.
• Standardkonfigurationen Docker Compose tillhandahåller Docker-körtiden, och Kubernetes/Helm tillhandahåller den inbyggda Pod-/PVC-körtiden när work.enabled=true.
• En fullständig säkerhetskopia kräver både Libre WebUI-databasen och Work-volymerna.

Relaterad dokumentation

• Snabbstart
• Arbeta med modeller
• Kortkommandon
• Miljövariabler
• Docker
• Kubernetes
• Autentisering
• Felsökning