Work: isolerede arbejdsområder

Work er Libre WebUI's indbyggede grænseflade til kodeagenter. Hver Work-opgave kombinerer en vedvarende samtale, en eksplicit rute til modeludbyderen og et dedikeret filsystem på /workspace. Den valgte model kan undersøge og redigere filer, køre kommandoer i en opgaveafgrænset Docker-container eller Kubernetes Pod og starte en forhåndsvisning i browseren.

Work er implementeret direkte i Libre WebUI. Det kræver ikke Libre Claw eller en anden agentdæmon.

Kun betroede brugere

Alle Work-API'er kræver en godkendt konto med Work-adgang. Som standard betyder det kun administratorer. En administrator kan åbne Work for alle aktive brugere fra fanen User Management i Indstillinger (arbejdsområder i værtsmapper forbliver altid kun for administratorer, fordi de bind-mounter serverstier). Work lader bevidst en model køre vilkårlige shellkommandoer i en sandkasse. Opgaver har udgående netværksadgang, medmindre den valgte navngivne kørselspolitik deaktiverer den. Behandl alle, du giver Work-adgang, som betroede kørselsoperatører, ikke blot som chatbrugere.

Højdepunkter i releasen

Denne release introducerer Work som en komplet opgavearbejdsgang:

• Separate handlinger for Work og Chat i hovedsidepanelet med den aktive tilstand tydeligt markeret.
• Work-opgaver i det almindelige sidepanel i stedet for et ekstra opgavepanel. Eksisterende opgaveplaceringer forbliver stabile, mens kørsler opdateres, og den valgte opgave kan slettes direkte.
• En dedikeret sandkasseidentitet og vedvarende Docker-volumen eller Kubernetes PVC til hver opgave. Sandkasser kan stoppes eller genskabes uden at slette opgavefiler.
• Vedvarende samtale, kørselstilstand, værktøjsaktivitet, modelvalg og opgaveejerskab i Libre WebUI's database.
• En live, godkendt kørselsstream til assistenttekst, udbydereksponeret ræsonnering, værktøjskald og -resultater, brug, workerfærdigheder og tilstandsændringer.
• Serverejede workerfærdigheder, der lærer den valgte model at undersøge, redigere, verificere og forhåndsvise effektivt uden at skrive kontrolfiler i projektet.
• Lokale Ollama-modeller med værktøjsunderstøttelse, Ollama Cloud-modeller og konfigurerede udbyderplugins til completion eller chat.
• En responsiv opdeling mellem Conversation og Workspace med en trækbar, tastaturtilgængelig størrelse på desktop og en fokuseret overfladeskifter på mindre skærme.
• Integrerede visninger for Files, Activity, Git, Terminal, Preview og Screen — Screen-visningen er det observerbare Work Computer-skrivebord, som kan undervises.
• Syntaksfremhævning i mørk og lys tilstand, kodeformatering i browseren, registrering af gemmekonflikter og midlertidige ikke-gemte kladder.
• En meddelelse pr. bruger, der kan afvises, når en ekstern modeludbyder vælges.
• Komplette Work-oversættelser på alle 25 understøttede sprog, herunder indbygget arabisk højre-til-venstre-layout, mens kode, stier, modelidentifikatorer og kommandooutput forbliver venstre-til-højre.

Den vedvarende enhed er opgavens arbejdsområde, ikke en container, der kører hele tiden. Libre WebUI starter, stopper og kan genskabe opgavens container efter behov, mens den navngivne volumen bevares.

Arkitektur

Libre WebUI, ikke modellen eller browseren, vælger navne på sandkasse og arbejdsområde, image, mount, bruger, grænser, netværkstilstand og forhåndsvisningsport. Modellen får kun disse værktøjer:

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

delete_file og move_file har stibeskyttelse ligesom de øvrige filværktøjer: De nægter at forlade arbejdsområdet, følger aldrig symbolske links, kræver et eksplicit rekursivt flag, før en mappe fjernes, og overskriver aldrig en destination ved flytning. Da de kører gennem filhjælperens sti i stedet for en shell, virker de også, mens en forhåndsvisning kører, når run_command er blokeret.

Modelanmodninger foretages af Libre WebUI-backend. De kommer ikke fra Work-containeren og afhænger ikke af containerens netværkspolitik.

Krav

Work kræver en konfigureret sandkasse-backend:

• Standardbackend kræver Docker installeret med en tilgængelig dæmon og tilladelse til, at backendprocessen kan kalde docker (eller den eksekverbare fil, der er konfigureret gennem WORK_DOCKER_COMMAND).
• Kubernetes-backend kræver API-legitimationsoplysninger samt den namespace-afgrænsede Role, RoleBinding, sandkasse-namespace og NetworkPolicies, som Helm-chartet opretter, når work.enabled=true.

Alle backends kræver også:

• En model med værktøjsunderstøttelse, som udstilles gennem:
  • en sund Ollama-tjeneste, herunder modeller, der nås gennem Ollama Cloud; eller
  • et aktivt completion-/chatplugin med en præcist konfigureret model og legitimationsoplysninger for den aktuelle administrator.
• Tilstrækkelig lagerplads til imaget, genererede projekter og projektlokale afhængigheder.
• En godkendt konto med Work-adgang. Work er kun for administratorer som standard; en administrator kan åbne det for alle aktive brugere.

Libre WebUI kontrollerer Ollamas annoncerede modelfunktioner, før en kørsel oprettes, og afviser en Ollama-model, der ikke annoncerer tools. Pluginbaserede modeller skal understøtte udbyderens protokol for værktøjskald. Hvis en valgt ekstern model afviser værktøjer, mislykkes kørslen. Work skifter ikke lydløst til en anden model eller udbyder.

Start lokalt

For den enkleste understøttede Work-opsætning skal du køre Libre WebUI og Docker på samme computer som browseren:

docker info
npx libre-webui@latest

Åbn http://localhost:8080, log ind som administrator, vælg Work i sidepanelet, vælg en kompatibel model, og beskriv projektet eller ændringen.

Hvis Docker mangler, er stoppet eller ikke kan tilgås, viser Work Runtime unavailable med backendens årsag og deaktiverer Run-skrivefeltet. Libre WebUI falder aldrig tilbage til at køre Work-kommandoer direkte på værten.

Kørselsimaget undersøges ved første brug og hentes automatisk, hvis det mangler. Den første handling kan derfor tage længere tid end senere handlinger.

Brug Work-grænsefladen

Opret og genåbn opgaver

Vælg Work ved siden af Chat i sidepanelet. Skriv en instruktion, vælg en model, og vælg Run. Den første besked opretter opgaven, dens første kørsel, udbyderruten og det vedvarende arbejdsområde.

Hver opgave forbliver i det primære sidepanel. Når den åbnes igen, gendannes den seneste samtale, Files-visningen, det aktuelle valg af udbyder/model og arbejdsområdet. Ældre samtalebeskeder kan indlæses i sider. Du kan omdøbe opgaven fra dens titel og slette den permanent fra menuen for den valgte opgave eller fra sidepanelet.

Kun én kørsel kan være aktiv for en opgave. En senere instruktion opretter en ny kørsel mod den samme samtale og det samme filsystem.

Skrivefeltet understøtter diktering: En mikrofonknap bruger browserens tale-API, hvor det er tilgængeligt, eller en konfigureret tale-til-tekst-model som fallback og føjer transskriptionen til den tekst, der allerede er skrevet. I samtalen vises filer, som en kørsel oprettede eller flyttede, som klikbare chips under den værktøjsaktivitet, der frembragte dem. Et klik åbner filen i arbejdsområdets Files-editor (og skifter til arbejdsområdefladen på smalle skærme). Chips kommer kun fra ændrende værktøjer, så en kørsel, der læste tyve filer, men skrev én, viser præcis det ene artefakt.

Hyr en agent

Startvisningen tilbyder Hire as an agent, når du har personaer. Vælg én, så bliver den oprettede opgave en vedvarende navngivet agent i stedet for en engangsopgave. Agenten beholder sin persona mellem kørsler — personaens navn og systemprompt sættes foran Work-systemprompten (sandkassens kørselskontrakt tilsidesætter dem altid) — og sidepanelet fastgør agenter i deres egen gruppe Agents over ad hoc-opgaver, hver med personaavatar, aktivitetsindikator og en statuslinje. Når sidepanelet er sammenklappet, er det kun de fastgjorte agentavatarer, der bliver tilbage i skinnen; engangsopgaver i Work kommer igen, når sidepanelet foldes ud.

Statuslinjen har to niveauer. For hyrede agenter beder ét billigt modelkald uden værktøjer i slutningen af kørslen om en status på cirka otte ord ("Inbox at zero. 2 replies ready."). Svaret er begrænset til én linje på 90 tegn, og fejl eller timeout falder tilbage til det deterministiske niveau — første linje i assistentens afsluttende besked. Ad hoc-opgaver og mislykkede kørsler bruger kun det deterministiske niveau, og WORK_STATUS_BLURB_MODEL=0 deaktiverer modelanmodningen helt. Agenter har også en ulæstindikator. Når opgaven åbnes, flyttes en monoton set-markør pr. opgave (synkroniseret mellem enheder), og sidepanelet viser en prik, når en kørsel nåede en sluttilstand efter denne markør.

Agenter rapporterer også gennem notifikationer — i appen og, når det er aktiveret, via web-push: work-run-finished, når en kørsel fuldføres, work-run-attention, når den stopper for input eller mislykkes, og work-takeover, når agenten beder et menneske overtage skærmen. Banneret er kun synligt, mens fanen Screen er åben, så pushen når dig andre steder. Hver notifikation linker direkte til agenten.

Du kan hyre under en persona, du ejer, eller en, der er delt med dig. Den delte visning afslører aldrig ejerens personaminder. Hvis personaen senere slettes, fortsætter agenten uden den, og en advarsel logges. API'et accepterer personaId og isAgent ved oprettelse af opgaven. En opgave, der oprettes med en persona, bliver automatisk en agent.

Fanen Agent

En agents arbejdsområdepanel åbner med en ekstra første fane, Agent — agentens egen side:

• Identity: personaavatar, navn, aktivitetsindikator og seneste statuslinje.
• Screen: Når opgavens politik giver Work Computer, vises en kompakt, live og skrivebeskyttet miniature af agentens skærm. Det er en rigtig fremviser (tæller med i opgavens fremviserbudget). Et klik åbner hele Screen-fanen, hvor overtagelse, undervisning og lyd findes.
• Routines: automatiseringer, der er bundet til opgaven. Hver udløsning kører i agentens eget arbejdsområde og samtale med agentens model og kørselstid — ikke i en ny opgave — så en morgenbriefing samles ét sted. Rækker viser tidsplanen med ord, har en pause-/genoptagelseskontakt, og formularen + Routine er allerede bundet til agenten. En forekomst, der udløses, mens agenten er optaget, mislykkes ærligt som work-task-busy i stedet for at blive sat i kø.
• Auto Review: agentens godkendelseskontakt og de Always-allow-regler, agenten har samlet (fjern en regel for at lukke dens omfang igen). Når opgavens politik gennemtvinger gennemgang, er kontakten låst i tændt tilstand.
• Taught skills: procedurer, der er demonstreret i undervisningstilstand, med en aktiveringskontakt pr. færdighed.

Tilsluttede værktøjer (MCP- og OpenAPI-servere)

Work-agenter kan kalde de samme værktøjsservere, som er konfigureret til chat — MCP eller OpenAPI, registreret af en administrator under Indstillinger → Værktøjer. Værktøjerne vises for agenten under deres navnerumsbestemte navne (server__tool), og kaldene kører fra Libre WebUI's backend gennem den hærdede værktøjsgateway (SSRF-sikret udgående trafik, legitimationsoplysninger pr. bruger, størrelses- og tidsgrænser) — aldrig inde fra sandkassen.

Udbuddet er ærligt om, hvad en autonom kørsel faktisk kan bruge:

• En offlineopgave får ingen: uanset at trafikken går gennem backend, forbliver en opgave uden netværksadgang offline — samme begrundelse som for web_search.
• En server, der kræver personlige legitimationsoplysninger, som brugeren ikke har gemt, filtreres fra allerede når værktøjerne tilbydes, fordi en autonom kørsel ikke kan holde pause for at spørge om dem. Tilføj oplysningerne under Indstillinger → Værktøjer, så tilbyder næste kørsel serveren.
• Adgangstilstanden for værktøjer (kun administratorer eller alle brugere) og synligheden pr. server gælder præcis som i chatten, og en personas bindinger til værktøjsservere indsnævrer, hvilke servere dens hyrede agent ser.
• Når godkendelser er aktive, holder tilsluttede værktøjer, som serveren klassificerer som sideeffektværktøjer, pause for din beslutning som enhver anden gatet handling; skrivebeskyttede værktøjer kører uden at spørge.

Delegering mellem agenter (@-omtaler)

Hyrede agenter kan give arbejde videre til hinanden. Skriv @ i Work-skrivefeltet for at omtale en af dine andre agenter; den aktuelle agent ser sin kollegaliste (navne og statuslinjer) i sine instruktioner og delegerer matchende anmodninger med værktøjet message_agent. Delegering er koordinering via beskeder, bevidst ikke via delte computere: hver agent beholder sit eget isolerede arbejdsområde og sin egen sandkasse, og modtageren kan ikke se den delegerende samtale — anmodningen skal bære sin egen kontekst.

Delegering er asynkron. Værktøjet svarer med det samme, målagenten kører i sin egen opgave (dens samtale viser anmodningen mærket Delegated by afsenderen), og når den er færdig — fuldført, kræver input, mislykket eller annulleret — leveres dens endelige svar tilbage i den delegerende agents samtale som en besked mærket Report from den pågældende agent. Hvis delegereren stadig kører, når rapporten dens model i næste runde; er den inaktiv, venter rapporten blot i samtalen — en rapport starter aldrig en kørsel af sig selv, så to agenter kan ikke sende bolden frem og tilbage. Delegerede kørsler kan ikke delegere videre, et optaget mål mislykkes ærligt i stedet for at blive sat i kø, og når godkendelser er aktive, holder message_agent pause for gennemgang som enhver anden handling med sideeffekt (en Always-allow-regel gælder kun den ene målagent).

Handlingsgodkendelser (Auto Review)

Handlinger med sideeffekt kan holde pause for din beslutning, før de kører. Når godkendelser er aktive for en opgave — dens Work-politik sætter Require approval for side-effecting actions, eller agentens kontakt Auto Review er slået til — stopper kørslen, før den udfører run_command, computer_act, delete_file, move_file eller message_agent, og viser et beslutningskort i samtalen: Allow once, Always allow eller Deny.

• Allow once kører præcis dette kald og spørger igen næste gang.
• Always allow kører kaldet og gemmer en regel på opgaven: for hele værktøjet ved fil- og computerhandlinger, begrænset til kommandoens program (dets første token) ved run_command — at godkende npm run build forhåndsgodkender fremtidige npm-kommandoer, ikke hele skallen — og begrænset til den ene målagent ved message_agent. Reglerne vises i Agent-fanens Auto Review-afsnit og kan fjernes der.
• Deny afviser kaldet. Modellen får at vide, at brugeren afviste handlingen og ikke må forsøge igen som den er; kørslen fortsætter med det svar.

En ventende godkendelse udløser også en notifikation (i appen og som webpush, når det er aktiveret), fordi kørslen kan være mange minutter inde i uovervåget arbejde, når den rammer porten. Hvis ingen beslutter inden for fem minutter, udløber anmodningen, handlingen udføres ikke, og kørslen slutter som Needs input med en normal overdragelse i stedet for at vente budgettet ud.

Godkendelser gater handlinger, ikke indsigt: write_file og de skrivebeskyttede værktøjer forbliver ugatede, og hver beslutning havner i sikkerhedsrevisionsloggen.

Forstå opgavestatus

Grænsefladen mapper vedvarende backendtilstande til et mindre brugerrettet sæt:

Status i grænsefladen	Backendtilstand	Indikatorfarve
Inaktiv	idle	rgb(255, 255, 255)
Tænker	preparing eller running	rgb(48, 121, 255)
Fuldført	completed	rgb(76, 212, 117)
Kræver input	needs_input eller cancelled	rgb(255, 204, 0)
Fejl	failed	rgb(255, 61, 129)

Hvis en aktiv kørsel stoppes, ændres den til Needs input, og filerne bevares. Hvis sikkerhedsbudgettet for runder eller værktøjskald udtømmes, slutter den også som Needs input efter den sidste overdragelse uden værktøjer, så ufuldstændigt arbejde aldrig mærkes som Complete.

En aktiv kørsel låser ikke samtalen. En besked, der sendes, mens agenten arbejder, føjes straks til samtalen og når modellen i dens næste runde, så du kan styre, rette eller tilføje kontekst uden at stoppe kørslen. Stopknappen forbliver tilgængelig ved siden af send.

Tilpas arbejdsområdets størrelse

Ved desktop-breakpointet xl deler Conversation og Workspace en trækbar opdeling:

• Standardbredden for samtalen er 45 %.
• Det foretrukne interval er 30–70 %, under hensyn til mindste indholdsbredder.
• Det gemte forhold gælder for den bruger, der er logget ind i den pågældende browser.
• Piletaster flytter skillelinjen med 2 %; hold Shift nede for 10 %.
• Home og End vælger henholdsvis det tilgængelige minimum og maksimum.
• Enter eller dobbeltklik nulstiller opdelingen.

Kontrollerne følger den aktive skriveretning. På arabisk ligger Conversation til højre og Workspace til venstre, og ændring af størrelse med markør og piletaster fortsætter i den forventede visuelle retning.

På mindre skærme bruges kontrollen Conversation/Workspace i opgavehovedet til at skifte flade.

Filer

Fanen Files viser direkte børn af /workspace, åbner strengt gyldige UTF-8-tekstfiler og gemmer ændringer i opgavevolumenet. Ugyldige bytesekvenser afvises i stedet for at blive erstattet med tabsgivende pladsholdertegn.

Editoren tilbyder:

• syntaksfremhævning i lys og mørk tilstand til almindelige web-, system-, script-, data- og markup-sprog;
• Cmd/Ctrl+S til at gemme;
• Shift+Alt+F til at formatere understøttede filer;
• optimistisk registrering af gemmekonflikter, så en ældre editorvisning ikke lydløst kan overskrive en fil, der er ændret, siden den blev åbnet;
• ikke-gemte kladder afgrænset til opgave og sti i browserens sessionslager; og
• navigationsadvarsler, mens en ikke-gemt redigering er åben.

Live-syntaksfremhævning sættes på pause over 8.000 tegn eller 400 linjer for at bevare responsen. Formatering er tilgængelig op til 100.000 tegn og 4.000 linjer for JavaScript/JSX, TypeScript/TSX, JSON-varianter, CSS/SCSS/Less, HTML, Markdown/MDX og YAML.

Når modellen ændrer en fil, du havde åben, viser Files en rød/grøn Changes-visning med præcis det, der blev tilføjet og fjernet, siden turen begyndte. Lange uændrede områder foldes sammen. En kontakt i værktøjslinjen skifter mellem diff og editor, og tællerne +added −removed opsummerer turen. Sammenligningsgrundlaget er det seneste indhold, browseren så før turen, så filer, der først åbnes efter turen, viser ingen diff.

Browserkladder er bekvemmelighedstilstand, ikke en sikkerhedskopi. De ryddes efter en vellykket gemning eller sletning af opgaven og forsvinder normalt, når browsersessionen slutter.

Aktivitet

Fanen Activity viser værktøjskald, værktøjsresultater, filhandlinger, kommandooutput og fejl. Værktøjsmetadata kan udvides i samtalen. Kommando- og værktøjsoutput vises venstre-til-højre, selv når den omgivende grænseflade er højre-til-venstre.

Mens en kørsel er aktiv, åbner Libre WebUI en godkendt server-sent event-stream og viser fremdrift, efterhånden som backend modtager den. Streamen kan indeholde:

• et indledende snapshot og senere ændringer af run_state;
• reasoning_delta, når den valgte udbyder eksplicit viser ræsonnering;
• tekst i assistant_delta;
• aktivitet i tool_call og tool_result;
• målinger i usage;
• notifikationer i skill_loaded til serverleveret workervejledning; og
• afsluttende hændelser error eller done.

Tilgængelighed og detaljeringsgrad for ræsonnering afhænger af model og udbyder. Libre WebUI viser kun ræsonneringsindhold, som udbyderen returnerer gennem sit API. Det kan ikke gendanne skjulte chain-of-thought, og nogle modeller giver ingen ræsonneringsstream. Assistenttekst og værktøjsaktivitet streames stadig, når de understøttes uafhængigt af ræsonnering.

Output er bevidst afgrænset. Et afkortet resultat beviser ikke, at en kommando ikke producerede yderligere output. Bed modellen undersøge et snævrere resultat eller køre en mere fokuseret kommando.

Git

Fanen Git tilbyder lokale versionsstyringshandlinger for opgavens eget /workspace:

• initialiser et repository med grenen main;
• undersøg porcelain-status, ahead/behind-antal og op til 20 seneste commits;
• undersøg en afgrænset tekstdiff for en ændret sti;
• stage op til 200 udtrykkeligt valgte stier ad gangen;
• commit stagede ændringer med den administrator, der er logget ind, brugerens navn og e-mail eller en instanslokal no-reply-adresse, når kontoen ikke har en e-mail;
• opret en lokal gren efter første commit; og
• skift til en eksisterende lokal gren, når arbejdsområdet er rent.

Denne flade er bevidst kun lokal. Den har ingen kontroller til clone, fetch, pull, push, administration af remotes, vilkårlige Git-kommandoer, tokens, SSH-nøgler eller pull requests. Disse handlinger kræver en særskilt betroet legitimationsmægler, helst en GitHub App eller tilsvarende installationstoken afgrænset til ét repository og én handling. Placer ikke langlivede Git-legitimationsoplysninger i /workspace, opgavecontainerens miljø eller repositorykonfigurationen.

Git-læsninger kan køre, mens opgaven ellers er inaktiv eller aktiv. Git-skrivninger afvises, mens en modelkørsel, interaktiv terminal eller forhåndsvisning ejer opgavecontaineren. Greneskift kræver desuden et rent working tree. Det forhindrer grænsefladen i at konkurrere med modellen eller en langvarig proces om de samme filer.

Alle Git-kommandoer i grænsefladen er et fast argumentarray, der køres som UID/GID 1000:1000 i opgavecontaineren. Brugerinput evalueres aldrig af en shell. Kørselstiden deaktiverer system-/global Git-konfiguration, prompts, hooks, credential helpers, commit-signering, submodulrekursion, eksterne diff-drivere, textconv og netværksprotokoller for denne flade. Den afviser repositories, hvis working tree ikke er præcis /workspace, eller hvis Git-/fællesmappen opløses uden for /workspace. Git-skrivehandlinger, der kan behandle filindhold, blokeres også, når repositorykonfigurationen definerer et eksekverbart clean-, smudge- eller processfilter.

Disse kontroller beskytter Libre WebUI's Git-API. En administrator kan stadig bruge Terminal, og modellen kan stadig bruge run_command til almindelige Git-kommandoer i sandkassen. Sandkassen og deploymentsgrænsen forbliver derfor sikkerhedskontrollerne for vilkårlige kommandoer.

Indbyggede workerfærdigheder

Hver kørsel får en serverejet vejledning til arbejdsområdet. Den forklarer den vedvarende /workspace-grænse, skrivebeskyttet containerrod, midlertidig proces- og /tmp-tilstand, netværkspolitik, kommando- og outputgrænser samt forhåndsvisningens livscyklus. Dens indbyggede færdigheder instruerer modellen i at:

• undersøge projektinstruktioner, manifester, lockfiler, scripts og aktuel repositorytilstand før redigering;
• bevare ikke-relateret arbejde og samle uafhængige læsninger eller søgninger;
• fortsætte med implementeringen i stedet for at stoppe efter en plan;
• køre fokuseret verificering før bredere kontroller;
• diagnosticere en fejl i stedet for blindt at prøve igen; og
• verificere programmet, før forhåndsvisningen startes som den sidste langvarige proces.

Vejledningen findes kun i modelkonteksten. Libre WebUI opretter ingen AGENTS.md, færdighedsmappe eller anden kontrolfil i brugerens arbejdsområde. Projektets egne instruktioner er fortsat projektvejledning og kan ikke tilsidesætte containerens eller værktøjernes sikkerhedsgrænse.

Terminal

Fanen Terminal forbinder en interaktiv shell til den samme sandkassecontainer, som modellen arbejder i. En administrator kan undersøge tilstand, køre en build manuelt eller fejlfinde det, en kørsel efterlod, uden at forlade browseren.

Shellen kører under den samme containerpolitik som alle modelværktøjer: den uprivilegerede bruger 1000:1000, arbejdsmappen /workspace, i den allerede hærdede container med fjernede capabilities. En terminal giver ingen rettighed, som modellens værktøj run_command ikke allerede har. Den er en menneskelig grænseflade til samme grænse, ikke en vej uden om den.

Driftsadfærd:

• Godkendelse — browseren udveksler sin almindelige Authorization-header via HTTP med en kortlivet engangsbillet, der er bundet til Work-terminalprotokollen og den præcise opgave. Kun billetten og opgave-ID'et vises i upgrade-URL'en /ws/work-terminal. Før hvert shellinput kontrollerer Libre igen kontostatus, Work-adgang, opgavens eksistens og ejerskab. Tilbagekaldelse lukker shellen og frigiver dens runtime-lease med det samme.
• Origin-kontroller — når CORS_ORIGIN eller BASE_URL er konfigureret, skal browser-upgrades matche en af de origins. Konfigurer mindst én til fjerndeployments. Upgrades uden origin er stadig tilgængelige for Electron og ikke-browserklienter, men kræver samme opgavebundne billet og aktuelle godkendelseskontroller. Brug TLS, firewall og reverse proxy-politik til at kontrollere disse klienter.
• Adgang — en åben terminal tager en runtime-lease præcis som en kommando eller forhåndsvisning og tæller mod WORK_MAX_ACTIVE_RUNTIMES_*.
• Containerens levetid — en tilsluttet terminal holder containeren kørende og forhindrer tomgangsstoppet i at fjerne den midt i sessionen.
• Samtidighed — WORK_TERMINAL_MAX_SESSIONS_PER_TASK (standard 2) begrænser samtidige shells pr. opgave.
• Tomgangstimeout — WORK_TERMINAL_IDLE_TIMEOUT_MS (standard 15 minutter) lukker en urørt session og frigiver dens lease.
• Mens en kørsel er aktiv — fanen forklarer, at modellen ejer containeren, og åbner shellen, når turen er færdig.

Terminalen taler direkte med Docker Engine API, fordi en TTY-session kræver en overtaget tovejsstream, som Docker CLI kun giver til en rigtig kontrolterminal. Den bruger WORK_DOCKER_SOCKET, ellers DOCKER_HOST — en unix://-socket eller et almindeligt HTTP-tcp://-slutpunkt som en socketproxy, hvis HTTP-bevidste videresendelse bærer den overtagne stream gennem en standard Connection: Upgrade-tunnel — og ellers /var/run/docker.sock. En DOCKER_HOST, som klienten ikke kan tale med (ssh:// eller tcp:// med DOCKER_TLS_VERIFY angivet), gør terminalen utilgængelig med den pågældende årsag i stedet for at forbinde et andet sted. Resten af Work fortsætter med at fungere. På Kubernetes-backend går samme session gennem exec-underressourcen som en TTY-WebSocket via API-serveren — inklusive frames til størrelsesændring — uden et Docker-slutpunkt.

Terminalsessioner er interaktive og optages ikke. Kommandoer, der skrives dér, vises ikke på opgavens Activity-tidslinje.

Forhåndsvisning

Fanen Preview starter, stopper, indlejrer og åbner den genererede webapplikation. Når kommandofeltet er tomt, undersøger Libre WebUI arbejdsområdet og:

• kører scriptet dev i en package.json i roden med den nødvendige vært og port;
• serverer en index.html i roden med en medfølgende statisk server uden afhængigheder; eller
• bruger samme regler til én app i en undermappe.

Rodprogrammer har forrang. Hvis der findes flere lige sandsynlige indlejrede apps, eller hvis der ikke findes et understøttet indgangspunkt, returnerer Work en fejl, der kan handles på, i stedet for at prøve en ikke-relateret npm-kommando. Angiv en tilpasset kommando, før Start preview vælges til andre projektlayouts eller servere. Tilpassede kommandoer starter i /workspace, så medtag den relative mappe efter behov, for eksempel cd apps/web && npm run dev -- --host 0.0.0.0 --port 4173. En tilpasset proces skal lytte på 0.0.0.0 og den konfigurerede WORK_PREVIEW_PORT. Work venter op til 15 sekunder på, at porten bliver klar.

Modellen kan også starte forhåndsvisningen gennem værktøjet start_preview. Det er den eneste understøttede måde, hvorpå en model kan efterlade en proces kørende. Almindelige run_command-kald rydder baggrundsunderprocesser, når kommandoen er færdig.

Skærm (Work Computer)

Se hele demonstrationen: en virkelig, uredigeret kørsel (30× og derefter realtid), hvor en Work-agent gennemser NASA's billedgallerier på sin egen skærm, vælger billeder og derefter bygger og tester et interaktivt Three.js-galleri — alt sammen ud fra én prompt.

En opgave, hvis politik aktiverer Work Computer, får en Screen-fane: et livevindue til et virtuelt skrivebord, der kører i samme sandkasse — en window manager, en dock og en Chromium-browser på en skærm med 1280×800. Du kan se agenten arbejde, overtage musen og tastaturet, lytte til computerens lyd og lære den opgaver gennem demonstration. Når fanen åbnes, startes GUI-sessionen efter behov (intet kører, før nogen ser på), og en VNC-over-WebSocket-fremviser forbindes.

En administrator aktiverer den med ét klik. Work-startsiden viser et kort for Work Computer med knappen Enable. Knappen bygger det medfølgende GUI-image på installationens egen Docker-dæmon (det første build tager et par minutter) og opretter en færdig Work Computer-politik — ingen manuel docker build og ingen policyfelter er nødvendige. Bag en filtreret Docker API-proxy er build-slutpunktet bevidst nægtet. Hent i stedet det offentliggjorte image på Docker-værten (ghcr.io/libre-webui/libre-work-computer, tagget libre-work-computer:latest), eller byg det dér fra deploy/work-computer/. Enable springer derefter buildet over og opretter kun politikken. Opgaver under politikken skal have netværksadgang — skærmen nås over en loopback-publiceret containerport, præcis som forhåndsvisningen.

Sikkerhedsmodel: VNC-serveren i containeren binder til localhost bag to adgangskoder pr. session — en skrivebeskyttet, der gives til alle godkendte seere, og en med fuld kontrol, der kun frigives til den aktuelle indehaver af overtagelsesleasen. VNC-serveren holder dermed alle andres input inaktivt. WebSocket-broen er den eneste tilgængelige overflade, offentliggjort på Docker-værtens loopback og aldrig eksponeret direkte. Alle seere godkendes med en engangsbillet bundet til sessionen og opgaven — samme mekanisme som Terminal — og den aktuelle Work-adgang kontrolleres ved hver forbindelse, så tilbagekaldelse af en brugers adgang afbryder skærmene med det samme. Op til fire samtidige seere kan følge én skærm, og visning tæller som opgaveaktivitet for tomgangsoprydningen.

Visning og kørsel konkurrerer aldrig. Hvis skærmen åbnes midt i agentens kørsel, forbindes der til kørslens egen sandkasse. En skærm, der bliver vist, blokerer ikke næste kørsel, og sessionen overlever, at kørslen slutter — også i teaminstallationer, hvor kørsler udføres i en separat workerproces. Browserprofilen gemmes i /workspace/.browser-profile, så logins i computeren overlever containergenstarter.

Agentstyring: En opgave med Work Computer giver også modellen to ekstra værktøjer. computer_observe returnerer et fuldt screenshot af skrivebordet sammen med markørens placering, identiteten på det aktive vindue, browserens aktuelle URL, om siden (i modsætning til browserens egen UI) har tastaturfokus, en kompakt beskrivelse af det fokuserede element og en screenshot-hash. De semantiske signaler kommer fra et DevTools-slutpunkt, der er bundet til containerens loopback, og mangler på GUI-images, som blev bygget, før det fandtes. computer_act udfører en batch på op til 24 mus- og tastaturhandlinger (flyt, klik, dobbeltklik, højreklik, skriv, tastekombinationer, scroll, vent) og returnerer skærmbilledet, efter at de er faldet til ro.

Tre kørselsværn holder batches ærlige. Handlingerne type/key kan have en focus-påstand og fejler sikkert, når det angivne felt ikke har tastaturfokus (så tekst ikke lydløst ender i adresselinjen). En batch stopper tidligt, hvis et vindue vises, titlen ændres, eller fokus flytter sig midt i batchen, fordi de resterende koordinater var rettet mod den forrige skærm. En batch kan desuden erklære et forventet resultat (titel, URL eller ændret skærmområde), som kørselstiden verificerer med en adaptiv deadline — "pending" betyder endnu ikke observeret, aldrig antaget succes. Efter en batch får skærmen lov at falde adaptivt til ro (ved polling, indtil den ikke længere ændrer sig) i stedet for efter en fast forsinkelse.

Hvert resultat indeholder også bevis, som modellen instrueres i at læse. Klik på eksplicitte koordinater returnerer en kvittering, der angiver, om pixels nær klikket ændrede sig. scroll_until ruller mod en måltekst eller sidekant og rapporterer, om den blev synlig. Hver observation sammenlignes med den forrige, så en uændret skærm benævnes som sådan. Batches kan erklære et énlinjes subgoal, der gemmes med resultatet som et checkpoint og gentages i gendannelsesprompter.

Agentløkken registrerer fastlåsning i grounding (tre identiske handlinger mod en uændret skærm udløser én gendannelsesbesked, og en gentagelse afslutter kørslen og beder om input i stedet for at bruge de resterende runder) og voksende tvetydighed (gentagne ikke-verificerede forventninger udløser én besked om ny grounding). Løkketelemetri — runder, værktøjslatenstid, screenshots, værn og vurderinger af forventninger — stemples på hver vedvarende værktøjspost og opsummeres, når kørslen slutter.

Screenshots når modellen som rigtigt billedindhold på alle udbyderruter — Ollama, Anthropic, Gemini samt OpenAI-kompatible chat- og Responses-plugins — så modellen, der driver opgaven, bør være en visionmodel. Hvis udbyderen afviser billedinput (en tekstmodel), mislykkes kørslen ikke. Screenshots fjernes for resten af kørslen, modellen får besked på at bruge tekstobservationerne, og en note i transskriptionen forklarer forringelsen. En model, der ikke kan se skærmen, verificerer dog langt mindre, så foretræk en visionmodel til computeropgaver. Kun de seneste screenshots forbliver i modellens livekontekst, og vedvarende opgavetransskriptioner gemmer kun tekstobservationen, aldrig billedbytes.

Browseren leveres med indbygget indholdsblokering — uBlock Origin Lite til annoncer og trackere (fastlåst og checksumverificeret ved image-build, med filtreringstilstand fastlåst gennem administreret politik) og automatisk afvisning af bannere om cookie-samtykke — fordi annoncer og samtykkevægge spilder agentens screenshots, tokens og klik. Annonceanmodninger neutraliseres på uBlock-måden: Kendte annoncescripts opløses til uskadelige lokale stubs, så sider fortsat fungerer. Agenten instrueres i aldrig at indtaste legitimationsoplysninger eller gennemføre CAPTCHA-/2FA-udfordringer; den rapporterer i stedet blokeringen. Til opgaver, man ikke har tillid til, bør en GUI-politik kombineres med en filtrerende DNS-resolver. En desktopbrowser gør politikken for udgående netværk vigtigere, ikke mindre.

Lyd: Skærmen er slået fra som standard (en browserregel — lyd kræver et klik). Højttalerknappen i Screen-panelet streamer computerens lyd live. I sandkassen spiller PulseAudio til en null sink, hvis monitor opfanges som rå PCM og serveres over en anden godkendt, loopback-publiceret WebSocket-bro — med samme billet, adgangskontrol og seergrænse pr. opgave som selve skærmen. Dette kræver et GUI-image bygget fra deploy/work-computer/ i denne version eller senere.

Overtagelse: Knappen Take over i Screen-panelet giver dig mus og tastatur — til login, håndtering af CAPTCHA eller andre trin, agenten ikke må udføre — og I'm done giver skærmen tilbage. Én VNC-session betjener begge roller: Serveren i containeren har en adgangskode med fuld kontrol og en skrivebeskyttet adgangskode (genereret pr. session, aldrig logget). Seere modtager kun den skrivebeskyttede adgangskode, og kontroladgangskoden frigives kun til den aktuelle indehaver af en kontrollease. Leasen er TTL-begrænset (en forladt overtagelse udløber inden for to minutter), fornyes, mens overtagelses-UI'en er åben, og er samarbejdsbaseret — den kan ikke tages fra en anden bruger.

En politik kan deaktivere overtagelse helt (Allow screen takeover i politikeditoren). Opgaver under den skjuler kontrollerne Take over og Teach, overtagelsesslutpunktet afviser, og agentens request_takeover rapporterer, at kontrol ikke kan gives til nogen. Visning er fortsat tilgængelig. Mens et menneske har kontrol, blokeres både computer_observe og computer_act, så agenten hverken kan modarbejde dit input eller tage screenshots af det, du skriver. Agenten kan også bede om dig: Værktøjet request_takeover viser et banner i Screen-panelet med årsagen og venter, indtil du overtager og giver kontrollen tilbage. Legitimationsoplysninger, der indtastes under en overtagelse, går direkte fra dit tastatur til siden — de passerer aldrig modellen eller opgavetransskriptionen. Overtagelse kræver et GUI-image bygget fra deploy/work-computer/ i denne version eller senere. Sessioner fra ældre images kan stadig ses, men er skrivebeskyttede for alle.

Undervisningstilstand: Teach a task i Screen-panelet optager en demonstration. Du styrer den rigtige skærm (kontrollen overtages præcis som ved en overtagelse, med en synlig optageindikator), mens markør-, tastatur- og scrollhandlinger registreres i skærmkoordinater. Hvert klik forankres også. En skrivebeskyttet probe identificerer det interaktive element under markøren (tag, ID og synlig label) og sidens aktuelle URL, så playbooktrin navngiver deres mål — "Click "button#submit (Place order)"" — og koordinaterne degraderes til hints om, hvor kontrollen var under demonstrationen.

Når demonstrationen gemmes, bygges en playbook deterministisk, uden en model i løkken. Tastetryk samles til indtastede strenge, klik kontra træk afgøres med en tærskel på 8 pixels, pauser bliver eksplicitte ventetrin, og indtastet tekst, der nævner ord for hemmeligheder eller ligner legitimationsoplysninger (mindst 8 tegn, der blander tre tegnklasser), fortrolighedsfiltreres og erstattes med en instruktion om at bruge request_takeover ved det trin.

Playbooken er en procedure i naturligt sprog — forankrede mål først, koordinater som hints, fortolket på ny med computer_observe — med hvornår den skal bruges, input, trin, verificering, et tilladt omfang, der afledes af de værter, demonstrationen faktisk besøgte (afspilning skal stoppe og spørge, før de forlades; en undervist procedure arver aldrig mere autoritet end det, der blev vist), godkendelsesgrænser og stop-og-spørg-håndtering af fejl. Den gemmes som en almindelig færdighed (slugpræfiks taught-), så den vises på Skills-siden med versionering, redigering og deling.

Work-kørsler med computeradgang indlæser ejerens aktiverede underviste færdigheder i systemprompten og rapporterer dem i kørslens færdighedsliste. Afspilning af en undervist opgave er derfor en almindelig kørsel, hvis anmodning matcher proceduren. Efter en færdig kørsel tilbyder færdighedschips en anmeldelse med ét klik for fungerede/mislykkedes, som føjer en dateret linje til færdighedens afsnit Track record (nyeste først, begrænset, hver linje en normal færdighedsversion). Procedurens historik bliver hos proceduren. Indtast ikke rigtige adgangskoder under optagelse. Demonstrér frem til login, gem, og lad request_takeover håndtere legitimationsoplysninger ved afspilning.

Udbydere, routing og dataoplysning

Understøttede udbyderruter

Rute	Validering og adfærd
Lokal Ollama	Ollama skal være sund, og den præcise model skal annoncere værktøjsunderstøttelse.
Ollama Cloud	Routes eksplicit gennem Ollama; modeller med cloud-suffiks viser oplysningen om fjernudbyderen.
Completion-/chatplugin	Pluginet skal være aktivt, angive den præcise model og have legitimationsoplysninger til den aktuelle administrator.
Anthropic-plugin	Bruger Works adapter til Anthropic-beskeder og værktøjsbrug.
Gemini-plugin	Bruger Works adapter til Gemini-indhold og funktionskald.
Andre kompatible plugins	Bruger anmodningsformatet med beskeder, værktøjer og værktøjsvalg i OpenAI-stil.

Udbydertype og plugin-ID gemmes både på opgaven og på hver kørsel. Modelnavnet vælger aldrig ruten alene. Et plugin med samme modelnavn som en Ollama-model kan ikke overtage en eksisterende opgave.

Hvad en udbyder modtager

For hver modelrunde kan den valgte udbyder modtage:

• Works systemprompt;
• de indbyggede worker-færdigheder og de aktuelle runtimegrænser;
• op til de seneste 30 beskeder fra bruger og assistent, begrænset til 256 KB;
• Works værktøjsdefinitioner;
• assistentens historik over værktøjskald; og
• værktøjsresultater, som kan indeholde mappelister, ønsket filindhold, søgeresultater, kommandooutput og fejl.

Den navngivne diskenhed uploades ikke som helhed. Filindhold og kommandooutput, der returneres gennem et værktøj, bliver imidlertid en del af modelsamtalen og sendes til den valgte udbyder. Gennemgå fjernudbyderens politikker for opbevaring, træning, priser og brug, før du anvender følsom kildekode.

Udbyderens legitimationsoplysninger forbliver i Libre WebUI-backend, uanset om de er konfigureret for hele installationen eller en enkelt bruger. De bruges til modelanmodninger fra backend og monteres aldrig i Work-containeren.

Kryptering af legitimationsoplysninger på applikationsniveau krypterer ikke hele opgaven. Work-samtaler, værktøjsresultater, kommandooutput og opgavemetadata er almindeligt databaseindhold, mens arbejdsområdets filer og afhængigheder er almindelige filer på opgavens Docker-diskenhed eller Kubernetes-PVC. Brug værtsadgangskontrol og diskkryptering, når installationens trusselsmodel kræver kryptering i hvile.

Oplysning om fjernudbydere

Work behandler pluginmodeller og Ollama-navne, der ender på :cloud eller -cloud, som fjernmodeller i oplysningsøjemed. Når en sådan model vælges, vises en besked, der kan afvises, om udbyderens dataflow og muligheden for flere fakturerbare kald. Valget om at afvise beskeden huskes per Libre WebUI-bruger.

Alle udbyderruter bruger samme budget i WORK_MAX_AGENT_ROUNDS, som er 48 runder som standard. Der er ingen særskilt grænse på 12 runder for plugins. Sikkerhedsbudgettet for værktøjskald er det største af 128 kald eller otte kald per konfigureret runde. Når rundebudgettet er opbrugt, beder Libre WebUI modellen om én afsluttende overlevering uden værktøjer, som beskriver udført arbejde, kontroller, blokeringer og resterende trin. Derefter registreres kørslen som Needs input i stedet for at vise en rå grænsefejl eller markere ufuldstændigt arbejde som færdigt. En opfølgende kørsel fortsætter i samme vedvarende arbejdsområde. En enkelt Work-kørsel kan stadig foretage mange fakturerbare udbyderkald.

Arbejdsområder med værtsmapper (valgfrit)

På Docker-backend er en opgaves /workspace normalt en navngiven diskenhed, som kun findes til den pågældende opgave, så modellen ikke kan nå dine virkelige filer. En Docker-installation kan i stedet tillade, at opgaven bindes til en faktisk mappe på værten. Kubernetes afviser arbejdsområder med værtsmapper og bruger en opgaveejet PVC.

Angiv begge variabler, og genstart backend:

WORK_HOST_WORKSPACES_ENABLED=true
WORK_HOST_WORKSPACE_ROOTS=/Users/you/Projects

WORK_HOST_WORKSPACE_ROOTS er en :-separeret liste over rødder og bruger serverbrugerens hjemmemappe som standard. Når funktionen er aktiv, får Work-startskærmen et valgfrit felt, Workspace folder. Lad det være tomt for at bruge opgavens isolerede diskenhed som hidtil.

Før en sti accepteres, skal den være absolut, eksistere, være en mappe og – efter opløsning af symlinks – ligge inden for en konfigureret rod. Mapper med navnene .ssh, .gnupg, .aws, .config, .kube, .docker, .claude, .libre-webui eller node_modules afvises altid. Den opløste sti gemmes med opgaven og vises i opgavehovedet, så det altid er synligt, hvilken mappe opgaven arbejder i.

Dette indsnævrer sandboxen

Et arbejdsområde på værten betyder, at modellen læser og skriver dine virkelige filer. Containerens øvrige beskyttelser – ikke-root-bruger, fjernede capabilities og ressourcegrænser – står ikke længere mellem modellen og mappen. Hold funktionen deaktiveret, medmindre du ønsker den, begræns rødderne mest muligt, og foretræk mapper under versionsstyring.

Persistens og runtimets livscyklus

Libre WebUI adskiller vedvarende tilstand fra udførelsestilstand:

Tilstand	Lager	Levetid
Opgaveejer, titel, udbyder og status	Libre WebUI-database	Indtil opgaven eller ejeren slettes
Kørsler, fejl, beskeder og værktøjsaktivitet	Libre WebUI-database	Indtil opgaven slettes
Filer i arbejdsområdet	Opgavespecifik Docker-diskenhed eller K8s-PVC	Overlever annullering, previewstop, genstart af sandbox og app
Rodfilsystem og midlertidige filer	Opgavespecifik container eller Pod	Midlertidige; kan stoppes eller oprettes igen
Previewproces	Kørende opgavesandbox	Midlertidig; beholdes kun, mens den er verificeret sund
Ikke-gemt editorudkast	Browserens sessionslager	Midlertidig bekvemmelighed i browsersessionen

Hver opgave får et servergenereret UUID. Navne på sandbox og arbejdsområde udledes i backend og accepteres aldrig fra en browseranmodning. Libre WebUI opretter runtime-ressourcer med labels for administration og opgaveejerskab. Før genbrug eller sletning kontrolleres ejerskabslabelen; en ressource, der tilhører en anden opgave, afvises.

Sandboxes klargøres efter behov. Filhjælpere stopper en ellers inaktiv sandbox, kommandoer stopper sandboxen efter afslutning, og et verificeret preview kan holde den kørende til inspektion. Det vedvarende arbejdsområde monteres igen, når samme opgavesandbox genstartes eller genskabes.

Administratorer kan definere navngivne runtimepolitikker på fanen User Management i Indstillinger. En politik samler runtime-image, hukommelses-/CPU-/PID-grænser, arbejdsområdestørrelse (Kubernetes), inaktivitetstimeout, netværksstandard og to funktionskontakter: Work Computer (GUI + browser), som giver opgaverne et virtuelt skrivebord og fanen Screen, samt Allow screen takeover, som bestemmer, om mennesker må overtage skærmene og dermed også, om undervisningstilstand er tilgængelig. En opgave oprettet under en politik bruger denne konfiguration. Tomme felter arver installationens globale værdier, og når en politik slettes, vender dens opgaver tilbage til globale værdier ved næste containergenskabelse. Politikker kan kun justere ressourcer og disse kontakter; hærdningsprofilen (ikke-root, skrivebeskyttet rootfs, fjernede capabilities og netværksisolering) kan ikke svækkes per politik.

WORK_RUNTIME_IDLE_TIMEOUT_MS begrænser previewets inaktivitetsperiode. Når værdien er angivet, stopper et sweep enhver sandbox uden aktivitet – afsluttet kommando, tilsluttet terminal eller previewanmodning gennem den signerede proxy – i så mange millisekunder og frigør dens plads. Arbejdsområdet bevares og sandboxen starter igen ved næste brug. Standardværdien (0) bevarer den nuværende adfærd: et preview kører, indtil det stoppes eksplicit.

Når backend starter, markeres aktive kørsler som mislykkede, og previewtilstand ryddes, fordi agentloop og proxy døde med processen. Driveren viser derefter alle administrerede containers eller Pods i én labelbaseret forespørgsel. Kørende sandboxes for kendte opgaver stoppes, da en afbrudt kommando kan køre uden supervisor; allerede stoppede sandboxes ændres ikke; og sandboxes uden tilsvarende opgaver fjernes. Ejerskab kommer fra opgavelabelen, aldrig ressourcenavnet. Fjernelse af forældreløse ressourcer forudsætter, at én Libre WebUI-instans ejer runtime-namespace eller Docker-daemon. Ret ikke to instanser mod samme Work-ressourcer. Hvis driveren ikke kan bevise oprydning, forbliver Work lukket sikkert, prøver igen hvert 10. sekund og blokerer nye muterende handlinger, indtil runtimeadgangen er gendannet.

Netværksadfærd

Kontrollér den valgte netværkspolitik

Opgaver uden en navngiven runtimepolitik starter med netværk aktiveret. En administrator kan definere en politik med netværk slået fra som standard, og opretteren kan vælge den. Der er ingen særskilt netværkskontakt per opgave. Senere politikændringer kræver, at sandboxen genskabes, før den nye runtimekonfiguration gælder.

På Docker-backend forbindes netværksaktiverede opgaver til et særligt administreret bridge-netværk (libre-webui-work som standard, WORK_NETWORK_NAME) med kommunikation mellem containers deaktiveret (com.docker.network.bridge.enable_icc=false). Derfor kan en Work-sandbox hverken oprette forbindelse til en anden Work-sandbox eller nå installationens containers på Dockers fælles standardbridge, herunder en database- eller Ollama-container, som ikke bevidst er publiceret.

Libre WebUI nægter at starte en netværksaktiveret opgave, hvis et netværk med det konfigurerede navn allerede findes, men ikke er det administrerede netværk. Det undgår stiltiende tilslutning til operatørens netværk.

På Kubernetes har sandbox-Pod'en samme netværkslabel. Helm-chartet installerer default-deny NetworkPolicy, kun preview-ingress og internet-egress til netværksaktiverede Pods, bortset fra work.networkPolicy.blockedEgressCidrs. NetworkPolicy virker kun, hvis clusterets CNI håndhæver den; se Kubernetes-guiden.

Udgående trafik til omverdenen er stadig tilladt, fordi pakkehentning, fjern-Git og eksterne API'er gør Work nyttigt. Dette er ikke en udgående firewall. Genereret kode kan stadig nå tjenester på Docker-værten, systemer på værtens lokale netværk, internettjenester og – afhængigt af installationen – metadataendpoints for infrastrukturen.

Hooks til udgående trafikpolitik

Brug følgende sammen for en strengere grænse:

• WORK_RUNTIME_DNS (Docker) — kommaseparerede IPv4-/IPv6-resolveradresser, der tvinges på hver netværksaktiveret sandbox (--dns). En filtrerende resolver giver navnebaserede tilladelses-/afvisningslister. Ikke-adresser afvises og logges, så værdien ikke kan injicere Docker-flags.
• Firewallregler på værten eller upstream (Docker) for det administrerede bridge-subnet.
• WORK_NETWORK_NAME (Docker) rettet mod et netværk, du selv opretter med egne driverindstillinger. Libre WebUI kræver både den administrerede label og deaktiveret ICC.

DNS-filtrering begrænser navneopslag, ikke direkte IP-egress. En installation, der skal garantere blokering af direkte IP-trafik, kræver også firewallregler på værts-, cluster- eller upstreamniveau.

Antag ikke, at Work forhindrer kode i at sende data. Giv kun Work-adgang til betroede brugere. Brug en navngiven netværksdeaktiveret runtimepolitik, når en opgave skal starte offline; ingen installationsomfattende miljøvariabel ændrer standardpolitikken.

Netværksadgang tilføjer ingen legitimationsoplysninger. Libre WebUI monterer ikke SSH-nøgler, cloudoplysninger, browserprofiler, værtens hjemmemappe eller Docker-socketen i opgavecontainers. Kode kan stadig sende oplysninger, som en bruger eller model skriver i /workspace.

Sandboxtrafik er adskilt fra modeltrafik. Ollama- og pluginanmodninger sendes altid af Libre WebUI-backend til den eksplicit valgte udbyderrute.

Sandboxens sikkerhedsgrænse

En Docker Work-container:

• kører som ikke-root UID/GID 1000:1000;
• bruger /workspace som arbejdsmappe;
• monterer kun den valgte opgaves navngivne diskenhed på /workspace;
• bruger et skrivebeskyttet rodfilsystem og et begrænset midlertidigt /tmp;
• fjerner alle Linux-capabilities;
• aktiverer no-new-privileges;
• er ikke privilegeret og bruger en init-proces;
• anvender grænser for CPU, hukommelse, processer, kommandotid og output;
• låser swap til hukommelsesgrænsen (--memory-swap er lig med --memory), så grænsen ikke kan omgås med swap;
• forbindes til det administrerede sandboxnetværk med kommunikation mellem containers deaktiveret eller slet intet netværk; og
• publicerer kun den konfigurerede previewport til en Docker-tildelt loopbackport på værten.

Alt verificeres igen med docker inspect, før en container genbruges, og hele sættet hashes i containerlabelen ai.libre-webui.policy. En container med en politik fra før en Libre WebUI-opgradering destrueres og genskabes, så hærdningsændringer automatisk når eksisterende opgaver.

Kubernetes-driveren anvender tilsvarende Pod-sikkerhedskontekst: ikke-root UID/GID, skrivebeskyttet rod, RuntimeDefault seccomp, ingen privilege escalation, alle capabilities fjernet, begrænset midlertidigt lager, ressourcegrænser, ingen ServiceAccount-token og en opgaveejet PVC på /workspace. Opgavelabel og policyfingeraftryk verificeres før genbrug eller sletning af Pod/PVC.

Stivalidering afviser absolutte stier, traversal, backslashes, NUL-tegn og for lange stier. Filhjælpere opløser reelle stier og afviser symlink-udbrud. Skrivninger bruger en midlertidig fil og atomisk rename.

Kontrollerne reducerer utilsigtet værtseksponering, men gør ikke Work til en virtuel maskine eller et sikkert miljø til malwareanalyse. Containers deler runtimeværtens kerne; en sårbarhed i Docker, Kubernetes, runtime, image, afhængighed eller kerne kan krydse grænsen.

Docker-diskenheder har ingen selvstændig diskkvote. Genererede projekter eller pakker kan opbruge Docker-lageret, så overvåg vækst og anvend værtsgrænser. Kubernetes anmoder om en PVC-størrelse; håndhævelsen afhænger af storage provisioner.

Tjekliste til Docker-hærdning i produktion

Tjeklisten gælder Docker-backend. Kubernetes-operatører skal også validere chartets namespace-RBAC, Pod-sikkerhed, storage class og CNI-håndhævelse af NetworkPolicy som beskrevet i Kubernetes-guiden.

Appen kan sætte containerflags, validere arbejdsområdestier og beskytte sit API. Den kan ikke håndhæve værtens firewall, storage-driverkvoter eller privilegieniveauet for den Docker-daemon, den får. Det er eksplicit implementeringsarbejde for en privat klientinstallation.

1. Isoler Docker-kontrollen

Libre WebUI-hovedcontaineren skal kontrollere daemonen for at oprette og inspicere Work-containers. En monteret Docker-socket er derfor en kontrolplanslegitimation, ikke en almindelig datamontering; kompromittering af webappen kan kompromittere Docker-værten.

docker-compose.socket-proxy.yml holder socketen helt ude af Libre WebUI-containeren. En intern proxy holder /var/run/docker.sock og videresender kun de API-dele, Work bruger – containers, images, volumes, networks, exec og info – mens swarm, secrets, configs, build, commit og system afvises. Libre WebUI bruger DOCKER_HOST=tcp://docker-socket-proxy:2375 uden socketmontering eller gruppemedlemskab. CLI, terminal og diagnostik følger samme endpoint. Proxyen indsnævrer API-overfladen, men ikke skadeområdet for de endpoints, den tillader: den, der kan oprette containers, kan stadig bind-mounte værtsstier.

En stærkere produktionsgrænse er en dedikeret VM uden andre workloads. Endnu stærkere er en dedikeret rootless Docker-daemon eller separat runtimevært, hvor kun den daemon eksponeres for Libre WebUI. Verificér filers ejerskab, previewrouting, oprydning og terminalstøtte før udrulning. En read-only-montering af samme rootful socket gør ikke Docker-API'et read-only.

2. Bloker administrationsadgang fra sandbox til vært

Deaktiveret kommunikation mellem containers stopper ikke adgang til tjenester på Docker-værten. Inspicér den faktiske bridge og subnet:

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

Brug værtens vedvarende firewallmanager til at afvise trafik fra bridgen til især SSH, Docker-API, databaser og administrationsporte. Test reglen fra en midlertidig container på libre-webui-work, test tilladte pakkehentninger og gør reglen vedvarende. Dockers DOCKER-USER styrer videresendt trafik; trafik til selve værten kan også kræve en INPUT-/input-hook-regel på bridgeinterfacet.

3. Begræns udgående destinationer

Bloker cloudmetadata, private infrastrukturranges og klient-LAN fra Work-subnettet, medmindre projektet kræver dem. Kombinér en filtrerende resolver via WORK_RUNTIME_DNS med firewallregler. DNS alene kan omgås med en IP-adresse, og en HTTP-proxy er utilstrækkelig, mens vilkårlige kommandoer kan åbne direkte forbindelser; håndhæv routing uden for containeren.

Opret separate runtimepolitikker til eksempelvis offline, kun pakkeregister og åben egress. Politikken bestemmer, om Libre forbinder sandboxnetværket; firewall/proxy håndhæver fortsat destinationsregler.

4. Håndhæv reelle lagerkvoter

CPU-, hukommelses-, swap- og PID-grænser begrænser ikke den navngivne diskenhed. Brug et lager med håndhævelige kvoter per arbejdsområde, eksempelvis XFS project quotas, kvotestyrede logiske diskenheder eller en volume/PVC-driver med størrelse. Docker-driveren local på almindelig ext4 får ikke en pålidelig kvote blot ved at dokumentere en størrelse.

Overvåg både hver diskenhed med ai.libre-webui.managed=true og Docker-dataroden, alarmér før fuld disk, og test fejltilstanden. En UI-tæller eller periodisk du kan advare, men ikke håndhæve, da containeren kan opbruge resten mellem kontroller.

5. Verificer den implementerede politik

Efter hver ændring af image eller daemonpolitik skal du oprette en midlertidig Work-opgave og verificere med docker inspect: ikke-root UID, skrivebeskyttet rod, fjernede capabilities, no-new-privileges, hukommelse/swap/CPU/PID, kun opgavediskenheden monteret og korrekt netværk. Verificér også hovedcontainerens mounts og at offentlig ingress går gennem autentificeret reverse proxy eller tunnel, ikke en utilsigtet Docker- eller previewport.

Previewets sikkerhed og tilgængelighed

Docker-driveren publicerer den konfigurerede previewport til en dynamisk port på backend-loopback. Kubernetes-backend bruger sandbox-Pod-IP'en direkte. Model og browser kan ikke vælge vilkårlig upstream. Libre WebUI signerer en capability-URL til præcis opgave og endpoint, kontrollerer ved hver anmodning, at previewet stadig kører, og proxyer HTTP/WebSocket gennem /api/work/previews. Stop eller genstart tilbagekalder den gamle URL.

Previewsvar fjerner Libre WebUI-legitimationsoplysninger og upstream-cookies. HTML begrænses af iframe-sandbox og CSP, som tillader scripts, formularer, dialoger og downloads uden same-origin-adgang. CSP beskytter også en separat fane. Genereret kode er stadig upålidelig og kan bruge egress til at sende alt, den kan læse fra arbejdsområdet eller browserinput. Behandl en kørende preview-URL som en kortlivet hemmelighed.

Fordi browseren indlæser proxyen på Libre WebUI's offentlige origin, virker fjernbrowsere og HTTPS-proxyer uden eksponerede Docker-porte/Pod-IP'er eller mixed content. Reverse proxy skal bevare WebSocket-upgrades til /api/work/previews/; den medfølgende Nginx-konfiguration gør det.

Hovedappen tillader kun egen origin og Cloudflare Turnstile som frame sources. Previewsvar omgår hovedpolitikken fra Helmet for at streame request bodies og anvende den smallere sandboxpolitik. Cross-origin embedder policy er fortsat deaktiveret, da genererede dev-servere normalt ikke udsender kompatible headers.

Implementeringsmatrix

Work-tilgængelighed følger maskinen og processen, der kører Libre WebUI-backend, ikke kun browseren eller desktopgrænsefladen.

Implementering	Work-kørsler og filer	Integreret preview
npx libre-webui på lokal computer	Understøttet, når Docker er installeret, kører og kan kaldes af backendbrugeren.	Understøttet gennem signeret same-origin-proxy.
Kildeudvikling på lokal computer	Understøttet med samme Docker- og udbyderkrav.	Understøttet gennem udviklings-API-origin på port 3001.
Electron-desktopklient	Betinget. Electron bruger en ekstern Libre WebUI-backend og giver ingen særskilt Work-runtime.	Understøttet gennem backendens signerede proxy-URL.
Bare-metal/VM-backend på fjernvært	Kørsler, filer og udbyderkald virker med Docker på værten.	Understøttet, når offentlig reverse proxy bevarer HTTP/WebSocket.
Standard Docker Compose	Understøttet som standard på Docker Desktop: imagen har Docker CLI, Compose monterer værtens socket, og Work-portene routes gennem host.docker.internal. Native Docker Engine kræver desuden en nåbar, ikke-offentlig WORK_PREVIEW_BIND.	Understøttet gennem samme offentlige Libre WebUI-origin.
Aktuel Kubernetes/Helm	Understøttet med --set work.enabled=true: sandboxes som Pods med PVC-arbejdsområder, namespace-RBAC og default-deny NetworkPolicies uden Docker-socket. Se Kubernetes-guiden.	Understøttet, når backend kører i clusteret og proxyen bruger Pod-IP.

Kør Work, når Libre WebUI selv kører i Docker

Alle repositoryets Compose-filer aktiverer Work: imagen har Docker CLI, og /var/run/docker.sock monteres. Docker Desktop fungerer med de medfølgende routingstandarder. Native Docker Engine kræver desuden, at WORK_PREVIEW_BIND sættes til en ikke-offentlig værtsgrænseflade, som søskendecontainere kan nå, som beskrevet nedenfor. Work styrer værtsdaemonen, så opgavecontainers er sideordnede med Libre WebUI-containeren, vises i værtens docker ps og ryddes af samme livscyklusregler.

En Docker-socket i en webapp giver root-lignende kontrol over værten. Work kan ikke fungere uden den; derfor er konsekvensen eksplicit: hver Libre WebUI-administrator er reelt administrator af Docker-værten. Operatøren ejer konsekvenserne for daemon, netværk, livscyklus, backup og adgang. Fjern linjen med /var/run/docker.sock for at slå Work fra.

Brug docker-compose.socket-proxy.yml for at beholde Work uden socketen i webappen. En intern proxy holder socketen, videresender kun nødvendige API-dele, og Libre WebUI bruger DOCKER_HOST. Se Isoler Docker-kontrollen.

Tre betingelser skal gælde, og Work-panelet navngiver den, der fejler:

1. Docker CLI skal findes i imagen. Den officielle image indeholder den; en tilpasset image skal have docker-cli eller WORK_DOCKER_COMMAND. Ellers: The "docker" CLI is not installed….
2. Socketen skal være monteret. Ellers: No Docker daemon is reachable….
3. Backendbrugeren skal være medlem af socketens gruppe. Imagen kører som nodejs (uid 1001), og socketen ejes typisk af root eller docker, så Compose bruger group_add: ['${DOCKER_GID:-0}']. Docker Desktop passer normalt til standarden; Linux kræver sit eget gruppe-id. Ellers: 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

Previewporte forbliver bundet til Docker-værtens loopback og eksponeres gennem en signeret same-origin-proxy med HTTP-assets og WebSocket-upgrades. Det virker bag HTTPS og tunneler uden at åbne de midlertidige porte. Stop/genstart tilbagekalder URL'en.

Når backend selv kører i Docker, kan publicerings- og forbindelsesadresse være forskellige. Behold WORK_PREVIEW_BIND=127.0.0.1, og sæt WORK_DOCKER_PUBLISHED_HOST til Docker-værtens adresse, som backendcontaineren kan nå (host.docker.internal på Docker Desktop). De medfølgende Compose-profiler sætter begge værdier og mapper værtsnavnet. Installationer på native Linux skal tilsidesætte WORK_PREVIEW_BIND med Docker-bridgens gateway (eller en anden eksplicit tilgængelig, ikke-offentlig værtsgrænseflade); mapping alene gør ikke en loopback-listener tilgængelig. Bind aldrig disse rå midlertidige porte til 0.0.0.0.

Samtidighed begrænses separat: WORK_MAX_ACTIVE_RUNTIMES_PER_USER er 2 og WORK_MAX_ACTIVE_RUNTIMES_GLOBAL er 3 som standard, så en administrator kan køre en anden opgave, mens den første er optaget. Capabilities-svaret rapporterer grænser og aktuel belægning.

På Kubernetes installeres chartet med work.enabled=true uden node-runtime-socket. Chartet opretter RBAC, sandbox-namespace, netværkspolitikker og Pod/PVC-konfiguration fra Kubernetes-guiden.

Runtimekonfiguration

Work læser følgende variabler i backendprocessen:

Variabel	Standard	Formål
WORK_RUNTIME_BACKEND	docker	Sandboxdriver: docker eller kubernetes
WORK_RUNTIME_IMAGE	node:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3	Image til opgavesandboxes
WORK_DOCKER_COMMAND	docker	CLI til Docker-backend
WORK_COMMAND_TIMEOUT_MS	120000	Standardtimeout for kommando
WORK_MAX_OUTPUT_CHARS	50000	Maksimalt indfanget kommando-/søgeoutput
WORK_MAX_AGENT_ROUNDS	48	Model-/værktøjsrunder per kørsel
WORK_MEMORY_LIMIT	2g	Hukommelsesgrænse per container
WORK_CPU_LIMIT	2	CPU-grænse per container
WORK_PIDS_LIMIT	256	Procesgrænse per container
WORK_PREVIEW_PORT	4173	Port appen lytter på i containeren
WORK_PREVIEW_BIND	127.0.0.1	Værtsinterface for previewport
WORK_DOCKER_PUBLISHED_HOST	samme som WORK_PREVIEW_BIND	Vært/IP backend bruger til publicerede Work-porte
WORK_COMPUTER_SCREEN_PORT	6080	WebSocket-port til skærmbroen i containeren
WORK_COMPUTER_AUDIO_PORT	6081	WebSocket-port til lydbroen i containeren
WORK_RUN_LEASE_WAIT_MS	60000	Ventetid på midlertidig runtimelease
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL	3	Samtidige containeropgaver per installation
WORK_MAX_ACTIVE_RUNTIMES_PER_USER	2	Samtidige containeropgaver per administrator
WORK_MAX_TASKS_GLOBAL	500	Vedvarende opgaver per installation
WORK_MAX_TASKS_PER_USER	100	Vedvarende opgaver per administrator
WORK_NETWORK_NAME	libre-webui-work	Administreret bridge-netværk
WORK_RUNTIME_DNS	ikke angivet	Resolver-IP'er til netværksopgaver
WORK_DOCKER_SOCKET	DOCKER_HOST ved unix:// eller tcp://, ellers /var/run/docker.sock	Docker Engine-endpoint til terminaler
WORK_TERMINAL_MAX_SESSIONS_PER_TASK	2	Samtidige terminaler per opgave
WORK_TERMINAL_IDLE_TIMEOUT_MS	900000	Inaktivitetstimeout for terminal
WORK_RUNTIME_IDLE_TIMEOUT_MS	0 (deaktiveret)	Stop sandbox efter inaktivitet
WORK_K8S_NAMESPACE	libre-webui-work	Namespace til sandbox-Pod/PVC
WORK_K8S_STORAGE_CLASS	clusterstandard	StorageClass til PVC
WORK_K8S_WORKSPACE_SIZE	5Gi	Standardstørrelse per PVC
WORK_K8S_POD_READY_TIMEOUT_MS	900000	Maksimal ventetid på klar Pod
WORK_K8S_POD_GONE_TIMEOUT_MS	60000	Maksimal ventetid på slettet Pod

Brug en fast imageversion eller digest i produktion. Et foranderligt tag kan ændre både værktøjer og sikkerhedsgrænse uden at ændre Libre WebUI.

Run-, preview-, filhjælper-, kommando- og sandbox-genskabelsesoperationer deler samme kapacitetsregnskab. En indlejret operation på en allerede talt opgave tæller ikke igen. Overskredne opgave-/runtimegrænser giver HTTP 429.

Faste protokol- og grænsefladegrænser

Element	Grænse
Ny opgave- eller kørselsbesked	65.536 tegn og UTF-8-byte
Model-id ved oprettelse/opdatering	500 tegn og UTF-8-byte
Pluginudbyder-id	200 tegn
Aktive kørsler per opgave	1
Kommandotekst	20.000 tegn
Værktøjets ønskede kommandotimeout	1 til 600 sekunder
Preview-readiness	15 sekunder
Fillæsning/-skrivning	2.000.000 byte UTF-8-tekst
Direkte mappeliste	Første 1.000 poster
Beskedside	Op til 200 beskeder og 1.000.000 byte
Vedvarende enkeltbesked	100 KB
Samtalekontekst til model	Seneste 30 bruger-/assistentbeskeder, op til 256 KB
Vedvarende værktøjsoutput	Cirka 20.000 kildetegn plus markør
Live syntaksfremhævning	8.000 tegn og 400 linjer
Browserformatering	100.000 tegn og 4.000 linjer
Git status-output	2.000.000 indfangede tegn
Git diff-output	600.000 indfangede tegn
Git-historik	20 lokale commits
Stier i én Git-stageanmodning	200
Git-commitbesked	4.000 tegn
Agentloop, alle udbyderruter	48 runder som standard via WORK_MAX_AGENT_ROUNDS
Sikkerhedsbudget for værktøjskald	max(128, configured rounds × 8) kald

Filadgang er til UTF-8-tekst. Editorens fil-API er ikke til binære filer, og filer over 2 MB kan ikke åbnes.

API-oversigt

Alle endpoints ligger under /api/work og kræver autentificering samt aktuel Work-adgang fra databasen. Work er kun for administratorer som standard; en administrator kan åbne almindelige opgavehandlinger for aktive brugere. Valg af værtsmappe og administrative policy-/adgangsendpoints forbliver kun for administratorer.

Metode	Sti	Formål
GET	/capabilities	Valgt runtime-/udbydertilgængelighed og grænser
GET	/tasks	Vis den aktuelle administrators opgaver
POST	/tasks	Opret en opgave og dens første asynkrone kørsel
GET	/tasks/:id	Indlæs opgavetilstand og seneste beskeder
GET	/tasks/:id/messages	Hent ældre beskeder sidevist
PATCH	/tasks/:id	Omdøb eller ændr den eksplicitte modelrute
DELETE	/tasks/:id	Fjern opgaven og dens vedvarende arbejdsområde
POST	/tasks/:id/runs	Start en opfølgende kørsel
POST	/tasks/:id/messages	Send besked til agenten under aktiv kørsel
GET	/tasks/:taskId/runs/:runId/events	Stream autentificerede liveevents via SSE
POST	/tasks/:id/cancel	Annuller aktiv kørsel
GET	/tasks/:id/approvals	Ventende godkendelser plus opgavens Auto Review-tilstand
PUT	/tasks/:id/approvals	Slå godkendelser til eller fra for opgaven
POST	/tasks/:id/approvals/:approvalId	Afgør en ventende godkendelse (tillad én gang/altid, afvis)
DELETE	/tasks/:id/approval-rules/:ruleId	Fjern en Always-allow-regel
GET	/computer/setup	Work Computer-konfigurationsstatus (administrator)
POST	/computer/setup	Byg GUI-image og opret policy (administrator)
POST	/tasks/:id/computer/start	Start opgavens Work Computer-session
GET	/tasks/:id/computer/control	Hvem styrer skærmen; agentens overtagelsesanmodning
POST	/tasks/:id/computer/control	Overtag eller forny kontrol over skærmen
DELETE	/tasks/:id/computer/control	Giv skærmen tilbage til agenten
POST	/tasks/:id/computer/teach	Gem demonstration som undervist færdighed
POST	/tasks/:id/computer/anchor	Find elementet under et registreret klik
POST	/computer/skills/:slug/trace	Tilføj en lykkedes/mislykkedes-linje til færdighed
GET	/tasks/:id/files	Vis en mappe i arbejdsområdet
GET	/tasks/:id/file	Læs en tekstfil
PUT	/tasks/:id/file	Gem en tekstfil
GET	/tasks/:id/git	Læs beskyttet lokal Git-status og historik
GET	/tasks/:id/git/diff	Læs begrænset lokal diff
POST	/tasks/:id/git/init	Initialiser lokal Git
POST	/tasks/:id/git/stage	Stage eksplicitte arbejdsområdestier
POST	/tasks/:id/git/commit	Commit staged ændringer
POST	/tasks/:id/git/branches	Opret lokal gren
POST	/tasks/:id/git/switch	Skift til eksisterende ren lokal gren
POST	/tasks/:id/preview/start	Start administreret preview
POST	/tasks/:id/preview/stop	Stop administreret preview

Opgave-id kontrolleres altid mod den autentificerede ejer. Aktuel kontostatus, rolle og Work-adgang læses fra databasen ved hver anmodning, så tilbagekaldelse gælder, selv hvis en ældre JWT indeholder forældede rolleclaims.

Opdateringsskemaet beholder backendfeltet networkEnabled til intern kompatibilitet. Det vises ikke som en selvstændig Work-kontrol. Vælg en navngiven runtimepolitik med ønsket netværksstandard ved oprettelse; brug ikke råfeltet som vedvarende konfigurations-API.

Sletning, kontoændringer og sikkerhedskopiering

Slet en opgave

Opgavesletning er bevidst destruktiv:

1. Backend markerer opgaven som under afvikling, så ingen ny muterende operation kan begynde.
2. En aktiv kørsel annulleres, og sandboxen stoppes.
3. Libre WebUI validerer opgaveejerskabslabels på runtime-ressourcerne.
4. Container/Pod og navngiven diskenhed/PVC fjernes.
5. Databaseopgaven slettes med cascade af kørsler og beskeder.
6. Browserudkast ryddes efter et vellykket API-kald.

Hvis runtimeoprydning fejler, bevarer Libre WebUI databaseposten og returnerer en fejl, så operatøren kan reparere Docker/Kubernetes og prøve igen. Metadata slettes ikke, mens en ikke-sporet sandbox eller et arbejdsområde efterlades.

At stoppe en kørsel eller et preview er anderledes: udførelsen stopper, men den navngivne diskenhed og samtalen bevares.

Nedgradering af administrator og sletning af bruger

Ved nedgradering gemmer Libre WebUI rolletilbagekaldelsen, før systemet afhænger af runtimeoprydning. Alle senere Work-anmodninger kontrollerer aktuel rolle og adgang. Backend suspenderer derefter opgaver, når rollen mister adgang, og forsøger at annullere kørsler og stoppe sandboxes. Hvis oprydning fejler, forbliver adgangen tilbagekaldt, og rolleopdateringen rapporterer fejlen, så operatøren kan reparere runtime og prøve igen.

Sletning af en anden bruger fjerner først alle brugerens administrerede Work-ressourcer. Hvis ekstern oprydning fejler, bevares brugerposten, så ejerskabsmetadata ikke mistes.

Sikkerhedskopiér hele opgaven

En komplet Work-backup kræver både:

• Libre WebUI-databasen med ejerskab, Docker-/Kubernetes-ressourcenavne, udbyderrouting, kørsler, beskeder og aktivitet; og
• hver Docker-diskenhed eller Kubernetes-PVC med labelen ai.libre-webui.managed=true, som indeholder Work-filerne.

Midlertidige containers og previewprocesser behøver ingen backup. Stop ny Work-aktivitet og backend før snapshot af database og arbejdsområder. Følg proceduren for Docker-diskenheder eller Kubernetes-lagerudbyderen.

Gendan database og matchende arbejdsområder sammen. Genskab hver diskenhed/PVC under præcis det navn, databasen registrerer, og gendan ejerskabsmetadata, herunder ai.libre-webui.task=<task UUID> og ai.libre-webui.managed=true. Kun filkopiering bevarer ikke labels; kun database giver opgaver uden filer; kun lager mister ejerskab og genererede navne.

Hvis installationen bruger krypterede udbyderoplysninger, skal du følge Libre WebUI's primære backupvejledning for datamappe og krypteringsnøgle.

Lokalisering og arabisk højre-til-venstre-layout

Hele Work-grænsefladen er oversat til alle 25 understøttede sprog: engelsk, arabisk, bengali, tjekkisk, dansk, tysk, spansk, fransk, hindi, indonesisk, islandsk, italiensk, japansk, koreansk, malajisk, nederlandsk, polsk, portugisisk, russisk, svensk, thai, tyrkisk, ukrainsk, vietnamesisk og kinesisk.

Arabisk anvender lang="ar" og dir="rtl" før React-rendering. Sidepanelet flyttes til højre, Conversation ligger til højre i desktopdelingen, Workspace til venstre, retningsikoner spejles, faner følger RTL-rækkefølge, og træk-/tastaturændring af størrelse bruger visuel RTL-semantik.

Teknisk indhold forbliver venstre-til-højre, når retning påvirker korrektheden:

• kode og syntaksfremhævning;
• filsystemstier;
• model-id'er;
• kommandoer og previewlogs;
• værktøjsoutput og metadata; og
• indhold i kodeblokke.

Opgavenavne, prompter i naturligt sprog, fejl, filnavne og previewkommandoer bruger automatisk tekstretning, hvor det passer.

Fejlfinding

Runtime er ikke tilgængelig, når npx bruges

npx libre-webui kører backend på værten, men installerer ikke Docker. Kør docker info som samme operativsystembruger, der starter Libre WebUI. Hvis kommandoen mangler eller ikke når daemonen, skal Docker installeres/startes eller brugerens daemonrettigheder rettes, og Work genindlæses.

Kontrollér også, at Ollama er sund, eller at mindst ét aktivt completion-/chatplugin har en model og legitimationsoplysninger til den aktuelle administrator.

Runtime er ikke tilgængelig i Docker eller Kubernetes

Repositoryets Compose-installation bør ikke rapportere dette: imagen har Docker CLI, og Compose monterer værtens socket. Panelet angiver årsagen: manglende CLI i tilpasset image, manglende socketmontering eller forkert socketgruppe. I sidste tilfælde angives DOCKER_GID, og containeren genskabes. Se Kør Work, når Libre WebUI selv kører i Docker.

På Kubernetes aktiveres native runtime med --set work.enabled=true. Libre rapporterer kubernetes, tester API'et og kører sandboxes som Pods med PVC-arbejdsområder. Monter ikke en nodes runtime-socket; se Kubernetes-guiden.

Ingen Work-kompatible modeller

For Ollama skal du vælge en model, der annoncerer tools. For et plugin skal du kontrollere, at typen er completion/chat, pluginet er aktivt, den præcise model findes i modelkortet, den aktuelle administrator har en brugbar API-nøgle, og fjernmodellen implementerer værktøjskald. Work falder aldrig tilbage til en anden udbyder.

En pakkeinstallation eller fjern-Git-kommando mislykkes

Kontrollér, at opgavens runtimepolitik aktiverer netværk. Der er ingen særskilt kontakt per opgave. Inspicér derefter DNS, proxy, firewall/NetworkPolicy, registry, certifikat, runtime og upstreamtjeneste samt om runtimeimagen indeholder kommandoen.

Git-fanen er kun lokal og udfører aldrig fjernoperationer. Brug Terminal eller modelkommandoer kun, når netværks- og legitimationspolitikken tillader fjern-Git. Indsæt ikke en langtidslevende token i arbejdsområdet.

En kørsel stopper ved en agentgrænse

Modellen kan have opbrugt runde- eller værktøjskaldsbudgettet. Work beder om en afsluttende overlevering uden værktøjer, så gennemgå udført arbejde og resterende trin. Opgaven forbliver i Needs input, hvilket afslutter kørslen uden at påstå færdiggørelse. Start en opfølgende kørsel i samme arbejdsområde, eller hæv bevidst WORK_MAX_AGENT_ROUNDS for alle udbydere, hvis værtens ressourcer og omkostningspolitik tillader det.

HTTP 429, når arbejde startes

Installationen eller administratoren har nået en grænse for aktive runtimes eller vedvarende opgaver. Vent på, at en kørsel/preview stopper, slet forældede opgaver, eller hæv den tilsvarende WORK_MAX_*-indstilling på en vært med tilstrækkelige ressourcer.

Previewet bliver ikke klar

Kontrollér, at kommandoen bliver ved med at køre, binder til 0.0.0.0 og lytter på WORK_PREVIEW_PORT inden for 15 sekunder. Med tom kommando finder Work automatisk et dev-script i package.json eller almindelig index.html, også i én indlejret app. Hvis flere apps eller ingen indgang rapporteres, skal du angive en eksplicit kommando. Til indlejret app bruges cd <app-directory> && ... fra /workspace.

Previewet virker på serveren, men ikke i en fjernbrowser

Kontrollér, at installationen har den signerede Work-previewproxy, og genstart previewet for at erstatte en gammel loopback-URL. Hvis sider virker, men hot reload ikke gør, skal proxy/tunnel tillade WebSocket-upgrades på /api/work/previews/. Docker-porten skal forblive på backend-loopback og kræver ingen firewallåbning.

Filerne er bevaret, men previewet er stoppet

Det forventes efter annullering, backendgenstart, eksplicit previewstop eller fejlet readiness. Previewprocessen er midlertidig; diskenheden er vedvarende. Åbn opgaven og start previewet igen.

En fil kan ikke åbnes eller gemmes

Fil-API'et accepterer UTF-8-tekst op til 2 MB. Hvis filen er ændret siden åbning, skal den genindlæses før redigering for ikke at overskrive en nyere ændring. Syntaksfremhævning skifter bevidst til plaintext over 8.000 tegn eller 400 linjer. Formatering har en separat grænse på 100.000 tegn og 4.000 linjer.

Work oplyser, at sandboxes gendannes

Start eller nedtagning kunne ikke bevise, at kendte sandboxes stoppede. Work forbliver lukket sikkert og prøver igen hvert 10. sekund. Gendan adgang til Docker-daemon/Kubernetes-API, og inspicér backendloggen. Slet ikke databaseopgaver, mens labelbaserede ressourcer stadig skal afstemmes.

En opgave kan ikke slettes

Kontrollér, at valgt runtime er tilgængelig. En konfliktende ressource uden forventet ai.libre-webui.task-label afvises bevidst. Løs navn-/ejerskabskonflikten forsigtigt, og prøv igen.

Sikkerhedsoversigt

Før Work aktiveres, skal du huske:

• Work er kun for administratorer som standard. Åbning for alle brugere gør hver aktiv konto til sandboxoperatør. Værtsmapper er altid kun for administratorer.
• Backend skal kontrollere sin Docker-daemon eller Kubernetes-namespace.
• Containers reducerer filsystemeksponering, men er ikke virtuelle maskiner.
• Opgaver uden navngiven offlinepolitik har netværksegress; destinationsbegrænsninger er operatørens ansvar.
• Work-diskenheder har ingen selvstændig diskkvote.
• Git-fanen er kun lokal; fjernlegitimationsoplysninger monteres eller accepteres aldrig af API'et.
• Værtsfirewall, daemonisolering, egressregler og reelle kvoter håndhæves af operatøren.
• Fjernudbydere modtager ønskede værktøjsresultater og kan medføre flere kald per kørsel.
• Previewporte forbliver på backend-loopback og eksponeres kun gennem signerede, tilbagekaldelige proxy-URL'er.
• Docker Compose giver Docker-runtime, og Kubernetes/Helm giver native Pod/PVC-runtime med work.enabled=true.
• En komplet backup kræver både Libre WebUI-databasen og Work-diskenhederne.

Relateret dokumentation

• Hurtig start
• Arbejde med modeller
• Tastaturgenveje
• Miljøvariabler
• Docker
• Kubernetes
• Autentificering
• Fejlfinding