Work: izolované pracovní prostory

Work je nativní rozhraní Libre WebUI pro programovací agenty. Každá úloha kombinuje trvalou konverzaci, výslovnou trasu poskytovatele a vyhrazený souborový systém /workspace. Vybraný model může zkoumat a upravovat soubory, spouštět příkazy v kontejneru Docker či Podu Kubernetes pro danou úlohu a spustit náhled v prohlížeči.

Work je implementován přímo v Libre WebUI. Nevyžaduje Libre Claw ani jiného démona agenta.

Pouze důvěryhodní uživatelé

Každé API Work vyžaduje ověřený účet s přístupem. Ve výchozím stavu jde pouze o správce; ten může na kartě User Management v Nastavení otevřít Work všem aktivním uživatelům. Pracovní prostory ve složkách hostitele zůstávají vždy jen správcům, protože připojují serverové cesty. Work záměrně dovoluje modelu spouštět libovolné shellové příkazy v sandboxu. Úlohy mají odchozí síť, pokud ji jejich běhová zásada nevypne. Každého s přístupem považujte za důvěryhodného operátora běhu, ne jen uživatele chatu.

Hlavní novinky vydání

Toto vydání přináší Work jako úplný pracovní postup:

• Samostatné akce Work a Chat v hlavním panelu s viditelným aktivním režimem.
• Úlohy Work v běžném panelu místo druhé lišty. Pozice zůstávají stabilní při běhu a vybranou úlohu lze přímo smazat.
• Vyhrazená identita sandboxu a trvalý svazek Docker či PVC Kubernetes pro každou úlohu. Sandbox lze zastavit nebo obnovit bez odstranění souborů.
• Trvalá konverzace, stav běhu, aktivita nástrojů, model a vlastník v databázi.
• Živý ověřený proud textu asistenta, poskytovatelem odhaleného uvažování, volání a výsledků nástrojů, používání, dovedností workeru a změn stavu.
• Serverové dovednosti, které model učí efektivně zkoumat, upravovat, ověřovat a zobrazovat náhled bez řídicích souborů v projektu.
• Místní modely Ollama s nástroji, Ollama Cloud a pluginy poskytovatelů.
• Responzivní rozdělení Conversation/Workspace s přístupným nastavením na desktopu a přepínačem ploch na menších obrazovkách.
• Integrované Files, Activity, Git, Terminal, Preview a Screen; Screen je sledovatelný a učitelný desktop Work Computer.
• Zvýraznění syntaxe ve světlém i tmavém režimu, formátování v prohlížeči, zjištění konfliktů ukládání a dočasné koncepty.
• Oznámení vzdáleného poskytovatele pro uživatele, které lze skrýt.
• Úplné překlady Work ve všech 25 jazycích včetně arabského RTL, zatímco kód, cesty, ID modelů a výstup příkazů zůstávají zleva doprava.

Trvalou jednotkou je pracovní prostor, ne stále běžící kontejner. Libre WebUI ho podle potřeby spouští, zastavuje či vytváří znovu, ale zachovává pojmenovaný svazek.

Architektura

Libre WebUI, ne model ani prohlížeč, vybírá názvy sandboxu a prostoru, image, mount, uživatele, limity, síťový režim a port náhledu. Model dostane jen nástroje:

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

delete_file a move_file chrání cesty jako ostatní: neopustí prostor, nenásledují symbolické odkazy, před odstraněním adresáře vyžadují rekurzivní příznak a nikdy nepřepíšou cíl. Běží přes pomocnou cestu souborů, proto fungují i během náhledu, kdy je run_command blokovaný.

Požadavky na model odesílá backend Libre WebUI. Nevznikají v kontejneru Work a nezávisí na jeho síťových zásadách.

Požadavky

Work potřebuje nastavený backend sandboxu:

• Výchozí backend vyžaduje Docker s dosažitelným démonem a oprávnění procesu volat docker nebo soubor z WORK_DOCKER_COMMAND.
• Kubernetes vyžaduje údaje API a Role, RoleBinding, namespace a NetworkPolicies vytvořené chartem Helm při work.enabled=true.

Každý backend také potřebuje:

• Model s nástroji přes zdravou Ollama včetně Cloud, nebo aktivní plugin s přesným modelem a přihlašovacími údaji aktuálního správce.
• Dostatek prostoru pro image, projekty a jejich závislosti.
• Ověřený účet s přístupem. Výchozí je pouze správce, který ho může otevřít ostatním.

Libre WebUI před během kontroluje oznamované funkce Ollama a odmítne model bez tools. Pluginy musí podporovat protokol nástrojů poskytovatele. Pokud vzdálený model nástroje odmítne, běh selže a Work potichu nepřepne jinam.

Místní spuštění

Nejjednodušší podporované nastavení provozuje Libre WebUI a Docker na počítači prohlížeče:

docker info
npx libre-webui@latest

Otevřete http://localhost:8080, přihlaste se jako správce, vyberte Work, vhodný model a popište projekt či změnu.

Když Docker chybí, neběží nebo není přístupný, Work zobrazí Runtime unavailable s důvodem a vypne editor Run. Libre WebUI nikdy nespustí příkazy přímo na hostiteli.

Image běhu se při prvním použití zkontroluje a případně automaticky stáhne, takže první operace může trvat déle.

Používání rozhraní Work

Vytváření a návrat k úlohám

V panelu vyberte Work vedle Chat, zadejte instrukci, model a Run. První zpráva vytvoří úlohu, běh, trasu poskytovatele a trvalý prostor.

Úloha zůstává v hlavním panelu. Znovuotevření obnoví konverzaci, Files, vybraný model a prostor. Starší zprávy lze načítat po stránkách. Úlohu lze přejmenovat a trvale smazat z nabídky či panelu. Aktivní může být jediný běh; další instrukce použije stejnou historii a soubory.

Editor podporuje diktování: mikrofon používá dostupné řečové API prohlížeče nebo model řeči na text a připojí přepis k napsanému textu. Soubory vytvořené nebo přesunuté během se zobrazí jako klikací štítky pod aktivitou; kliknutí je otevře ve Files a na úzkém displeji přepne plochu. Štítky vznikají jen z měnících nástrojů, takže čtení dvaceti souborů a zápis jednoho ukáže jediný artefakt.

Najmutí agenta

Máte-li persony, úvod nabízí Hire as an agent. Vybraná úloha se stane trvalým pojmenovaným agentem. Persona přetrvá mezi běhy; její název a systémový prompt se vloží před prompt Work, ale smlouva sandboxu má vždy přednost. Panel agenty připne do skupiny Agents nad ad hoc úlohy s avatarem, indikátorem aktivity a stavovým řádkem. Ve zúženém panelu zůstanou v liště jen tyto připnuté avatary agentů; jednorázové úlohy Work se vrátí po rozbalení panelu.

Stav má dvě úrovně. U najatých agentů požádá jedno levné volání bez nástrojů na konci o asi osm slov ("Inbox at zero. 2 replies ready."). Odpověď má jediný řádek do 90 znaků; selhání přejde na první řádek závěrečné zprávy. Ad hoc a neúspěšné úlohy používají jen deterministickou úroveň a WORK_STATUS_BLURB_MODEL=0 volání vypne. Agent má indikátor nepřečteného: otevření posune monotónní značku viděno synchronizovanou mezi zařízeními a panel ukáže tečku, když běh skončil po této značce.

Agenti hlásí život i přes oznámení: work-run-finished po dokončení, work-run-attention při čekání na vstup nebo chybě a work-takeover při žádosti o převzetí obrazovky. Banner je viditelný jen na Screen, push vás dosáhne jinde. Každé oznámení odkazuje přímo na agenta.

Lze najmout pod vlastní nebo sdílenou personou; sdílení neodhalí vzpomínky vlastníka. Po pozdějším odstranění persony agent pokračuje bez ní a zapíše varování. API přijímá personaId a isAgent; úloha s personou je automaticky agent.

Karta Agent

Panel agenta začíná zvláštní kartou Agent:

• Identity: avatar, název, indikátor a poslední stav.
• Screen: při povoleném Work Computer kompaktní živý náhled jen pro čtení. Počítá se do rozpočtu diváků; kliknutí otevře plnou Screen s převzetím, výukou a zvukem.
• Routines: automatizace svázané s úlohou. Každé spuštění používá stejný prostor, konverzaci, model a běh, ne novou úlohu. Řádky ukazují plán a přepínač, formulář + Routine je již svázán. Výskyt během práce selže jako work-task-busy, nezařadí se do fronty.
• Auto Review: přepínač schvalování pro tohoto agenta a nasbíraná pravidla Always-allow (odebráním pravidla jeho rozsah zase uzavřete). Pokud schvalování vynucuje zásada úlohy, je přepínač uzamčen v zapnuté poloze.
• Taught skills: postupy předvedené ve výuce s přepínačem každé dovednosti.

Připojené nástroje (servery MCP a OpenAPI)

Agenti Work mohou volat stejné servery nástrojů, jaké jsou nastavené pro chat — MCP nebo OpenAPI, registrované správcem v Nastavení → Nástroje. Agentovi se ukážou pod svými jmennými názvy (server__tool) a volání běží z backendu Libre WebUI přes zpevněnou bránu nástrojů (odchozí provoz chráněný proti SSRF, údaje jednotlivých uživatelů, limity velikosti a času), nikdy zevnitř sandboxu.

Nabídka přiznává, co může autonomní běh doopravdy použít:

• Offline úloha nenabídne žádný: ať už backend ven může, nebo ne, úloha bez přístupu k síti zůstává offline — stejný důvod jako u web_search.
• Server, který vyžaduje osobní přihlašovací údaj a uživatel jej neuložil, se odfiltruje už při sestavení nabídky, protože autonomní běh se nemůže zastavit a o něj požádat. Přidejte údaj v Nastavení → Nástroje a další běh server nabídne.
• Režim přístupu k nástrojům (jen správci, nebo všichni uživatelé) i viditelnost jednotlivých serverů platí přesně jako v chatu a vazby persony na servery nástrojů zužují, které servery její najatý agent uvidí.
• Když jsou aktivní schválení, připojené nástroje, které server klasifikuje jako mající vedlejší účinek, počkají na vaše rozhodnutí jako každá hlídaná akce; nástroje jen pro čtení běží bez ptaní.

Delegování mezi agenty (zmínky přes @)

Najatí agenti si mohou práci předávat. Napsáním @ v okně Work zmíníte jiného svého agenta; aktuální agent má ve svých instrukcích seznam kolegů (jména a stavové řádky) a odpovídající požadavky deleguje nástrojem message_agent. Delegování je koordinace zprávami, záměrně ne sdílením počítačů: každý agent má vlastní izolovaný pracovní prostor i sandbox a cílový agent nevidí delegující konverzaci — požadavek musí nést vlastní kontext.

Delegování je asynchronní. Nástroj se vrátí okamžitě, cílový agent běží ve své vlastní úloze (v jeho konverzaci je požadavek označen Delegated by a jménem odesílatele) a po skončení — dokončeno, potřebuje vstup, selhalo, nebo zrušeno — se jeho závěrečná odpověď doručí zpět do konverzace delegujícího agenta jako zpráva označená Report from a jménem agenta. Pokud delegující agent stále běží, dostane hlášení jeho model v dalším kole; pokud je nečinný, hlášení prostě počká v konverzaci — samo od sebe nikdy běh nespustí, takže si dva agenti nemohou donekonečna pinkat. Delegované běhy už dál delegovat nemohou, zaneprázdněný cíl pokus poctivě odmítne místo zařazení do fronty a při aktivních schváleních se message_agent zastaví ke kontrole jako každá jiná akce s vedlejším účinkem (pravidlo Always-allow se váže jen na toho jednoho cílového agenta).

Schvalování akcí (Auto Review)

Akce s vedlejším účinkem se mohou před spuštěním zastavit a počkat na vaše rozhodnutí. Když jsou pro úlohu schválení aktivní — zásada Work nastavuje Require approval for side-effecting actions, nebo je zapnutý přepínač Auto Review agenta — běh se zastaví před provedením run_command, computer_act, delete_file, move_file či message_agent a v konverzaci ukáže rozhodovací kartu: Allow once, Always allow, nebo Deny.

• Allow once provede přesně toto volání a příště se zeptá znovu.
• Always allow volání provede a k úloze uloží pravidlo: u souborových a počítačových akcí pro celý nástroj, u run_command omezené na program příkazu (jeho první token) — schválení npm run build předem povolí budoucí příkazy npm, ne celý shell — a u message_agent omezené na jednoho cílového agenta. Pravidla jsou vypsaná v sekci Auto Review na kartě Agent a lze je tam odebrat.
• Deny volání odmítne. Modelu se sdělí, že uživatel akci zamítl a nesmí ji opakovat beze změny; běh s touto odpovědí pokračuje.

Čekající schválení také vyvolá oznámení (v aplikaci a při zapnutém web pushi i push), protože běh může být v okamžiku zastavení už mnoho minut v práci bez dozoru. Pokud nikdo do pěti minut nerozhodne, požadavek vyprší, akce se neprovede a běh skončí jako Needs input s běžným předáním místo čekání až do vyčerpání rozpočtu.

Schválení hlídají akce, ne viditelnost: write_file a nástroje jen pro čtení zůstávají bez hlídání a každé rozhodnutí se zapíše do bezpečnostního auditu.

Stav úlohy

Rozhraní mapuje trvalé stavy backendu na menší sadu:

Stav rozhraní	Stav backendu	Barva
Nečinný	idle	rgb(255, 255, 255)
Přemýšlí	preparing nebo running	rgb(48, 121, 255)
Hotovo	completed	rgb(76, 212, 117)
Potřebuje vstup	needs_input nebo cancelled	rgb(255, 204, 0)
Chyba	failed	rgb(255, 61, 129)

Zastavení aktivního běhu nastaví Needs input a zachová soubory. Vyčerpání rozpočtu kol či nástrojů také končí jako Needs input po závěrečném předání bez nástrojů, nikoli Complete.

Aktivní běh nezamyká konverzaci: nová zpráva se ihned přidá a model ji dostane v dalším kole, takže lze směrovat a opravovat bez zastavení. Tlačítko Stop zůstává dostupné.

Změna velikosti prostoru

Na breakpointu xl sdílí Conversation a Workspace tažitelné rozdělení:

• Výchozí šířka konverzace je 45 %.
• Preferovaný rozsah je 30–70 % s minimálními šířkami obsahu.
• Uložený poměr platí přihlášenému uživateli v daném prohlížeči.
• Šipky posouvají o 2 %, Shift o 10 %.
• Home a End zvolí minimum a maximum.
• Enter nebo dvojklik rozdělení obnoví.

Ovládání následuje směr psaní. V arabštině je Conversation vpravo a Workspace vlevo a ukazatel i šipky se chovají podle vizuálního směru. Na menších obrazovkách použijte přepínač Conversation/Workspace v záhlaví.

Soubory

Files prochází přímé potomky /workspace, otevírá přísně platné UTF-8 texty a ukládá do svazku. Neplatné bajty odmítne namísto ztrátové náhrady.

Editor nabízí:

• zvýraznění syntaxe ve světlém a tmavém režimu pro běžné jazyky;
• Cmd/Ctrl+S pro uložení;
• Shift+Alt+F pro formátování;
• optimistickou detekci konfliktu, aby starý pohled nepřepsal novější soubor;
• koncepty omezené úlohou a cestou v úložišti relace; a
• varování navigace při neuložené úpravě.

Živé zvýraznění se nad 8 000 znaků nebo 400 řádků pozastaví. Formátování je do 100 000 znaků a 4 000 řádků pro JavaScript/JSX, TypeScript/TSX, JSON, CSS/SCSS/Less, HTML, Markdown/MDX a YAML.

Když model změní otevřený soubor, Files ukáže červenozelené Changes přesně s přidaným a odebraným od začátku tahu a složí dlouhé stejné části. Přepínač volí diff nebo editor, počítadla +added −removed shrnují změny. Základem je poslední obsah viděný prohlížečem, takže soubor otevřený až po tahu nemá diff.

Koncepty jsou pohodlí, ne záloha. Smažou se po úspěšném uložení, odstranění úlohy nebo obvykle s koncem relace.

Aktivita

Activity ukazuje volání a výsledky nástrojů, soubory, výstup příkazů a chyby. Metadata lze rozbalit v konverzaci. Výstup se zobrazuje zleva doprava i v RTL rozhraní.

Během aktivního běhu Libre WebUI otevře ověřený proud SSE a vykresluje pokrok. Proud může nést:

• úvodní snapshot a změny run_state;
• reasoning_delta, pokud poskytovatel odhaluje uvažování;
• text assistant_delta;
• tool_call a tool_result;
• měření usage;
• skill_loaded pro vedení workeru; a
• koncové error nebo done.

Dostupnost a podrobnost uvažování závisí na modelu. Libre WebUI ukazuje jen obsah vrácený API, nemůže obnovit skryté myšlenky a některé modely proud neposkytují. Text a nástroje přesto streamují, pokud jsou podporované nezávisle.

Výstup je záměrně omezený. Zkrácení nedokazuje, že příkaz nevytvořil další výstup; požádejte model o užší kontrolu nebo cílenější příkaz.

Git

Karta Git nabízí místní správu zdrojů vlastního /workspace:

• inicializaci repozitáře s větví main;
• porcelain stav, počty ahead/behind a až 20 commitů;
• omezený textový diff změněné cesty;
• stage nejvýše 200 výslovně vybraných cest;
• commit se jménem a e-mailem správce nebo místní no-reply adresou;
• vytvoření místní větve po prvním commitu; a
• přepnutí existující větve při čistém working tree.

Rozhraní je záměrně jen místní. Nemá clone, fetch, pull, push, remote, libovolné příkazy, tokeny, klíče SSH ani pull requesty. Ty vyžadují zvláštního důvěryhodného zprostředkovatele, ideálně GitHub App či token omezený na jediný repozitář a operaci. Nedávejte dlouhodobé údaje do /workspace, prostředí kontejneru ani konfigurace Git.

Čtení Git může běžet v klidné i aktivní úloze. Zápisy se odmítají, když kontejner vlastní model, terminál nebo náhled; přepnutí větve navíc vyžaduje čistý strom. Tím se zamezí souběhu s modelem a dlouhými procesy.

Každý příkaz UI je pevné pole argumentů spuštěné jako UID/GID 1000:1000; vstup uživatele nevyhodnocuje shell. Běh vypíná systémovou a globální konfiguraci, prompty, hooks, credential helpers, podpis commitů, rekurzi submodulů, externí diff, textconv a síťové protokoly. Odmítne repozitář, jehož working tree není přesně /workspace nebo Git adresář míří ven. Zápisy se zablokují i při spustitelném clean, smudge či process filtru.

To chrání Git API Libre WebUI. Správce může v Terminal a model přes run_command stále spustit běžný Git; bezpečnostní hranicí zůstává sandbox a instalace.

Vestavěné dovednosti workeru

Každý běh dostane serverovou příručku prostoru. Vysvětluje trvalý /workspace, kořen jen pro čtení, dočasné procesy a /tmp, síť, limity a životní cyklus náhledu. Model učí:

• před úpravou zkontrolovat instrukce, manifesty, lock soubory, skripty a stav Git;
• zachovat nesouvisející práci a dávkovat nezávislá čtení či hledání;
• pokračovat implementací namísto skončení plánem;
• spustit cílené ověření před širšími kontrolami;
• diagnostikovat chybu namísto slepého opakování; a
• ověřit aplikaci před spuštěním náhledu jako posledního dlouhého procesu.

Příručka existuje jen v kontextu modelu. Libre WebUI nevytváří AGENTS.md, adresář dovedností ani řídicí soubor. Projektové instrukce nemohou přepsat hranici kontejneru či nástrojů.

Terminál

Terminal připojí interaktivní shell ke stejnému sandboxu jako model, aby správce mohl zkoumat stav, ručně sestavit nebo ladit bez opuštění prohlížeče.

Shell má stejnou politiku: neprivilegovaný 1000:1000, pracovní adresář /workspace, zpevněný kontejner bez capability. Nedává nic navíc oproti run_command; jde o lidské rozhraní stejné hranice.

Provozní chování:

• Ověřování — prohlížeč vymění hlavičku Authorization přes HTTP za krátkodobý jednorázový ticket vázaný na protokol terminálu a úlohu. Jen ticket a ID jsou na /ws/work-terminal. Před každým vstupem Libre znovu ověří účet, přístup, existenci a vlastnictví; odvolání zavře shell a uvolní lease.
• Origin — při nastaveném CORS_ORIGIN nebo BASE_URL musí upgrade prohlížeče odpovídat. Pro vzdálenou instalaci nastavte alespoň jedno. Klienti Electron bez originu stále vyžadují ticket a živé ověření; řiďte je TLS, firewallem a proxy.
• Přijetí — terminál bere lease a počítá se do WORK_MAX_ACTIVE_RUNTIMES_*.
• Životnost — připojený terminál drží kontejner a brání zastavení v nečinnosti.
• Souběh — WORK_TERMINAL_MAX_SESSIONS_PER_TASK (výchozí 2) omezuje shelly úlohy.
• Nečinnost — WORK_TERMINAL_IDLE_TIMEOUT_MS (15 minut) zavře nedotčenou relaci.
• Aktivní běh — karta vysvětlí, že kontejner vlastní model, a shell otevře po tahu.

Terminal mluví přímo s Docker Engine API, protože TTY vyžaduje převzatý obousměrný proud. Použije WORK_DOCKER_SOCKET, jinak DOCKER_HOST — socket unix:// nebo prostý HTTP tcp://, jehož proxy přenese proud tunelem Connection: Upgrade — a jinak /var/run/docker.sock. Nepodporovaný DOCKER_HOST (ssh:// či tcp:// s DOCKER_TLS_VERIFY) oznámí nedostupnost namísto jiného připojení; zbytek Work funguje. V Kubernetes jde TTY WebSocket přes exec podzdroj API serveru včetně změn velikosti, bez Dockeru.

Relace terminálu se nezaznamenávají a příkazy nejsou v Activity.

Náhled

Preview spouští, zastavuje, vkládá a otevírá vytvořenou webovou aplikaci. S prázdným příkazem Libre zkontroluje prostor a:

• spustí kořenový skript dev v package.json s hostitelem a portem;
• podá kořenový index.html vestavěným serverem bez závislostí; nebo
• použije stejná pravidla na jedinou aplikaci v podadresáři.

Kořen má přednost. Při více podobných aplikacích nebo bez vstupu vrátí Work použitelnou chybu namísto nesouvisejícího npm. Pro jiné projekty zadejte před Start preview vlastní příkaz. Začíná v /workspace, například cd apps/web && npm run dev -- --host 0.0.0.0 --port 4173. Proces musí poslouchat 0.0.0.0 a WORK_PREVIEW_PORT; Work čeká nejvýše 15 sekund.

Model může použít start_preview. Jde o jediný podporovaný způsob ponechání procesu; run_command po dokončení uklidí potomky na pozadí.

Obrazovka (Work Computer)

Podívejte se na úplnou ukázku: skutečný, neupravený běh (30× a pak reálný čas), ve kterém agent prochází galerie NASA na vlastní obrazovce, vybírá fotografie a staví a testuje interaktivní galerii Three.js — vše z jednoho promptu.

Úloha s povoleným Work Computer dostane kartu Screen: živé okno do virtuálního desktopu ve stejném sandboxu — správce oken, dock a Chromium na 1280×800. Můžete sledovat práci, převzít myš a klávesnici, poslouchat zvuk a učit úlohy demonstrací. Otevření karty spustí GUI až na požádání a připojí prohlížeč VNC přes WebSocket.

Správce ho zapne jedním kliknutím: úvod Work ukazuje kartu Work Computer s Enable. Ta sestaví vestavěný GUI image na vlastním démonu Docker (poprvé několik minut) a vytvoří připravenou zásadu, bez ručního docker build. Za filtrovanou proxy je build záměrně zakázán; stáhněte image na hostiteli (ghcr.io/libre-webui/libre-work-computer, tag libre-work-computer:latest) nebo ho sestavte z deploy/work-computer/. Enable pak build přeskočí. Úlohy musí mít síť, protože obrazovka používá loopback port stejně jako náhled.

Zabezpečení: VNC server uvnitř váže localhost za dvě hesla relace — jedno jen pro sledování všem oprávněným a plné pouze držiteli lease převzetí. Ostatní vstupy server ignoruje. Jediným dosažitelným povrchem je WebSocket bridge publikovaný jen na loopbacku hostitele. Každý divák používá jednorázový ticket vázaný na relaci a úlohu, jako Terminal, a přístup Work se kontroluje při každém spojení. Odvolání obrazovku ihned odpojí. Současně mohou sledovat čtyři diváci a sledování se počítá jako aktivita. Sledování a běh si nekonkurují: otevření během práce se připojí k sandboxu běhu, neblokuje další běh a relace přežije jeho konec i v týmovém externím workeru. Profil prohlížeče přetrvává v /workspace/.browser-profile, takže přihlášení přežijí restart kontejneru.

Ovládání agenta: Work Computer přidává dva nástroje. computer_observe vrací plný snímek, polohu kurzoru, aktivní okno, aktuální URL, zda má fokus stránka či chrome prohlížeče, popis prvku a hash. Sémantika pochází z DevTools na loopbacku a u starších images může chybět. computer_act provede dávku až 24 akcí myši a klávesnice (pohyb, klik, dvojklik, pravé tlačítko, psaní, zkratky, scroll, čekání) a vrátí ustálený snímek.

Tři ochrany udržují dávky poctivé. type/key mohou nést tvrzení focus a bezpečně selžou, pokud pole fokus nemá, aby text neskončil v adresním řádku. Dávka skončí při novém okně, změně titulku nebo přesunu fokusu, protože souřadnice mířily na starou obrazovku. Může deklarovat očekávaný výsledek (titulek, URL, změnu oblasti), který běh ověří adaptivním termínem; „pending“ znamená nepozorováno, ne úspěch. Obrazovka se po dávce adaptivně dotazuje do ustálení namísto pevného čekání.

Výsledek nese důkazy. Kliknutí vrátí potvrzení o změně pixelů, scroll_until rolování k textu či okraji a informaci o viditelnosti, každé pozorování se porovná s předchozím a beze změny se výslovně označí. Dávka může mít jednořádkový subgoal, který zůstane jako checkpoint a zopakuje se při obnově.

Smyčka pozná uváznutí ukotvení (tři stejné akce na stejné obrazovce vyvolají jedno varování, opakování ukončí běh a požádá o vstup místo plýtvání koly) a rostoucí nejednoznačnost (po sobě jdoucí neověřená očekávání vyvolají nové ukotvení). Telemetrie kol, latence, snímků, ochran a verdiktů se zapisuje u každého nástroje a shrne na konci.

Snímky se modelu posílají jako skutečný obraz u všech tras — Ollama, Anthropic, Gemini, OpenAI Chat i Responses — proto používejte obrazový model. Pokud textový poskytovatel obraz odmítne, běh neselže: snímky se do konce zahodí, model použije textová pozorování a přepis vysvětlí degradaci. Ověření bez obrazu je slabší. V živém kontextu zůstávají jen nejnovější snímky; trvalý přepis uchovává pouze text, ne bajty obrazu.

Prohlížeč má vestavěné blokování obsahu: uBlock Origin Lite pro reklamy a sledování (připnutý a ověřený checksumem při sestavení, režim vynucen spravovanou zásadou) a automatické zavírání bannerů cookies. Reklamy a souhlasy plýtvají snímky, tokeny a kliknutími. Známé reklamní skripty se nahrazují neškodnými místními stuby, aby stránky fungovaly. Agent nikdy nesmí zadávat údaje ani řešit CAPTCHA/2FA; oznámí překážku. U nedůvěryhodných úloh kombinujte GUI s filtrovací DNS. Desktopový prohlížeč činí odchozí zásady důležitější, ne méně.

Zvuk: Screen je výchozím způsobem ztlumený (prohlížeč vyžaduje kliknutí). Tlačítko reproduktoru streamuje zvuk počítače. PulseAudio uvnitř hraje do null sinku, jehož monitor se zachytí jako PCM a podává druhým ověřeným WebSocket bridge na loopbacku se stejným ticketem, kontrolou a limitem diváků. Vyžaduje image z deploy/work-computer/ této nebo novější verze.

Převzetí: Take over dá myš a klávesnici pro přihlášení, CAPTCHA či kroky zakázané agentovi a I'm done je vrátí. Jedna relace VNC má heslo plné a jen pro čtení, generované pro relaci a neprotokolované. Diváci dostanou jen čtení, plné heslo pouze držitel lease. Lease má TTL (opuštěné převzetí vyprší do dvou minut), obnovuje se s otevřeným UI a nelze ho zabrat jinému uživateli.

Zásada může převzetí vypnout přes Allow screen takeover. Úlohy skryjí Take over a Teach, koncový bod odmítne a request_takeover oznámí nemožnost předání; sledování zůstane. Když ovládá člověk, computer_observe i computer_act jsou blokované, takže agent nezasahuje ani nesnímá psaný text. Agent může přes request_takeover zobrazit banner s důvodem a čekat na převzetí a vrácení. Zadané údaje jdou přímo z klávesnice na stránku, nikdy přes model či přepis. Starší images zůstávají sledovatelné jen pro čtení.

Režim výuky: Teach a task nahrává demonstraci. Řídíte skutečnou obrazovku jako při převzetí s indikátorem a zaznamenávají se akce v souřadnicích. Každé kliknutí se navíc ukotví: sonda jen pro čtení určí prvek pod kurzorem (tag, ID, štítek) a URL, takže kroky pojmenují cíl, například „Click "button#submit (Place order)"“, a souřadnice jsou jen nápověda.

Uložení vytvoří playbook deterministicky, bez modelu ve smyčce: klávesy se spojí do textu, klik a tažení rozliší hranice 8 pixelů, pauzy jsou čekání a text připomínající tajemství nebo přihlašovací údaje (8+ znaků se třemi třídami) se rediguje a nahradí pokynem request_takeover.

Playbook je přirozený postup — nejprve ukotvené cíle, souřadnice jako nápověda, nově interpretované přes computer_observe — s použitím, vstupy, kroky, ověřením, povoleným rozsahem z navštívených hostitelů (před opuštěním musí zastavit a zeptat se; naučený postup nedědí širší autoritu), hranicemi schválení a zastavením při chybě. Uloží se jako běžná dovednost s prefixem taught-, proto se zobrazí ve Skills s verzemi, úpravami a sdílením.

Běhy s počítačem načtou povolené naučené dovednosti vlastníka do systémového promptu a uvedou je v seznamu. Přehrání je běžný běh odpovídající postupu. Po dokončení nabízí štítky jedním klikem hodnocení úspěchu či selhání, které přidá datovaný řádek do Track record (nejnovější první, omezené, každý jako verze). Historie zůstává s postupem. Při nahrávání nepište skutečná hesla; demonstrujte k přihlášení, uložte a při přehrání použijte request_takeover.

Poskytovatelé, směrování a zveřejnění dat

Podporované trasy poskytovatelů

Trasa	Ověření a chování
Místní Ollama	Ollama musí být zdravá a přesný model musí uvádět podporu nástrojů.
Ollama Cloud	Explicitně se směruje přes Ollama; modely s cloudovým suffixem zobrazí upozornění na vzdáleného poskytovatele.
Completion/chat plugin	Plugin musí být aktivní, uvádět přesný model a mít přihlašovací údaje aktuálního administrátora.
Plugin Anthropic	Používá adaptér Work pro zprávy Anthropic a používání nástrojů.
Plugin Gemini	Používá adaptér Work pro obsah Gemini a volání funkcí.
Jiné kompatibilní pluginy	Používají formát požadavku se zprávami, nástroji a volbou nástrojů ve stylu OpenAI.

Typ poskytovatele a plugin ID se ukládají na úloze i každém běhu. Samotný název modelu trasu nikdy neurčuje. Plugin se stejným názvem jako model Ollama nemůže převzít existující úlohu.

Co poskytovatel obdrží

V každém kole modelu může vybraný poskytovatel obdržet:

• systémový prompt Work;
• vestavěné dovednosti workeru a aktuální limity runtime;
• nejvýše posledních 30 zpráv uživatele/asistenta, omezených na 256 KB;
• definice nástrojů Work;
• historii volání nástrojů asistentem; a
• výsledky nástrojů, které mohou obsahovat seznamy složek, vyžádaný obsah souborů, výsledky hledání, výstup příkazů a chyby.

Pojmenovaný volume se nenahrává celý. Obsah souboru či výstup příkazu vrácený nástrojem se však stane součástí konverzace modelu a odešle vybranému poskytovateli. Před použitím citlivého zdrojového kódu si prostudujte zásady vzdáleného poskytovatele pro uchování, trénování, ceny a využití.

Přihlašovací údaje poskytovatele zůstávají na backendu Libre WebUI, ať jsou nastaveny pro celé nasazení či jednotlivce. Používají se k backendovým požadavkům modelu a nikdy se nepřipojují do kontejneru Work.

Aplikační šifrování přihlašovacích údajů nešifruje celou úlohu. Konverzace Work, výsledky nástrojů, výstupy příkazů a metadata úloh jsou běžným obsahem databáze; soubory a závislosti pracovního prostoru jsou běžnými soubory v Docker volume nebo Kubernetes PVC. Pokud tržní model vyžaduje šifrování v úložišti, použijte hostitelské řízení přístupu a šifrování disku.

Upozornění na vzdáleného poskytovatele

Work pro účely upozornění považuje pluginové modely a názvy Ollama končící :cloud nebo -cloud za vzdálené. Jejich výběr zobrazí zavíratelné upozornění o toku dat a možnosti více zpoplatněných volání. Zavření se pamatuje pro každého uživatele Libre WebUI.

Všechny trasy používají stejný rozpočet WORK_MAX_AGENT_ROUNDS, ve výchozím stavu 48 kol. Pluginy nemají zvláštní limit 12 kol. Bezpečnostní rozpočet volání nástrojů je větší z 128 volání nebo osmi volání na nakonfigurované kolo. Po vyčerpání požádá Libre WebUI model o jedinou závěrečnou předávku bez nástrojů popisující dokončenou práci, kontroly, blokátory a zbývající kroky. Běh se poté zaznamená jako Needs input, nikoli jako surová chyba limitu či falešné dokončení. Následující běh pokračuje ve stejném trvalém prostoru. Jeden běh Work může stále provést mnoho zpoplatněných volání.

Pracovní prostory v hostitelských složkách (volitelné)

Na backendu Dockeru je /workspace úlohy obvykle pojmenovaný volume existující pouze pro ni, takže model nedosáhne na skutečné soubory. Docker nasazení může místo toho povolit navázání na skutečnou hostitelskou složku. Kubernetes hostitelské složky odmítá a používá PVC vlastněnou úlohou.

Nastavte obě proměnné a restartujte backend:

WORK_HOST_WORKSPACES_ENABLED=true
WORK_HOST_WORKSPACE_ROOTS=/Users/you/Projects

WORK_HOST_WORKSPACE_ROOTS je seznam kořenů oddělený : a ve výchozím stavu používá domovskou složku serverového uživatele. Po zapnutí přibude na úvodní obrazovce Work volitelné pole Workspace folder. Prázdná hodnota zachová izolovaný volume jako dosud.

Přijímaná cesta musí být absolutní, existovat, být složkou a po vyřešení symlinků ležet uvnitř nakonfigurovaného kořene. Složky .ssh, .gnupg, .aws, .config, .kube, .docker, .claude, .libre-webui a node_modules se vždy odmítnou. Vyřešená cesta se uloží s úlohou a zobrazí v záhlaví.

Tímto se zužuje sandbox

Hostitelský prostor znamená, že model čte a zapisuje skutečné soubory. Ostatní ochrany kontejneru — non-root uživatel, odstraněné capabilities a limity — již mezi modelem a složkou nestojí. Funkci ponechte vypnutou, kořeny omezte co nejvíce a upřednostněte složky pod verzováním.

Trvalost a životní cyklus runtime

Libre WebUI odděluje trvalý stav od stavu provádění:

Stav	Úložiště	Životnost
Vlastník, název, poskytovatel a stav úlohy	Databáze Libre WebUI	Do smazání úlohy či vlastníka
Běhy, chyby, zprávy a aktivita nástrojů	Databáze Libre WebUI	Do smazání úlohy
Soubory pracovního prostoru	Docker volume nebo K8s PVC úlohy	Přežijí zrušení, zastavení náhledu a restart sandboxu/aplikace
Kořenový systém a dočasné soubory	Kontejner nebo Pod úlohy	Dočasné; lze zastavit či znovu vytvořit
Proces náhledu	Běžící sandbox úlohy	Dočasný; zachován jen při ověřeném zdraví
Neuložený koncept editoru	Úložiště relace prohlížeče	Dočasné pohodlí pro relaci prohlížeče

Každá úloha dostane serverové UUID. Názvy sandboxu a prostoru odvozuje backend a nikdy je nepřijímá od prohlížeče. Prostředky runtime mají labels správy a vlastnictví. Před opětovným použitím či smazáním se label ověří a prostředek jiné úlohy odmítne.

Sandboxy se připravují na vyžádání. Operace souborů zastaví jinak nečinný sandbox, příkazy jej zastaví po dokončení a ověřený náhled jej může držet spuštěný. Trvalý pracovní prostor se připojí znovu při restartu či novém vytvoření.

Administrátoři mohou na kartě User Management v Nastavení definovat pojmenované zásady runtime. Zásada sdružuje runtime image, limity paměti/CPU/PID, velikost prostoru (Kubernetes), timeout nečinnosti, výchozí síť a dva přepínače: Work Computer (GUI + browser) pro virtuální plochu a kartu Screen a Allow screen takeover pro lidské převzetí a dostupnost výuky. Úloha vytvořená pod zásadou použije její konfiguraci. Prázdná pole dědí globální hodnoty a po smazání zásady se úlohy při příštím vytvoření kontejneru vrátí ke globálním. Zásada nesmí oslabit hardening (non-root, read-only rootfs, odstraněné capabilities, síťová izolace).

WORK_RUNTIME_IDLE_TIMEOUT_MS omezuje dobu nečinnosti náhledu. Je-li nastaven, sweep zastaví sandbox bez aktivity — dokončeného příkazu, terminálu či požadavku na náhled — po daném počtu milisekund a uvolní jeho slot. Prostor zůstane a sandbox se při příštím použití spustí. Výchozí 0 nechává náhled běžet do explicitního zastavení.

Při startu backend označí aktivní běhy jako selhané a vymaže stav náhledu. Driver jedním dotazem vypíše spravované kontejnery/Pody. Běžící sandbox známé úlohy zastaví, již zastavený ponechá a orphan bez databázové úlohy odstraní. Vlastnictví určuje label, ne název. Jedna instance musí vlastnit runtime namespace či daemon. Pokud driver neumí prokázat úklid, Work zůstane bezpečně uzavřen, opakuje kontrolu každých 10 sekund a blokuje nové mutace.

Síťové chování

Ověřte vybranou síťovou zásadu

Úlohy bez pojmenované zásady startují se sítí. Administrátor může vytvořit zásadu s výchozí sítí vypnutou a tvůrce ji vybrat. Samostatný přepínač per úloha neexistuje a změna zásady vyžaduje znovu vytvořit sandbox.

Docker připojuje síťové úlohy k řízené bridge síti (libre-webui-work, WORK_NETWORK_NAME) s vypnutou komunikací mezi kontejnery (com.docker.network.bridge.enable_icc=false). Sandbox proto nedosáhne na jiný sandbox ani na kontejnery instalace v běžné bridge síti, pokud nejsou záměrně publikovány.

Pokud síť se stejným názvem existuje, ale nemá správnou správu, Libre WebUI úlohu odmítne místo tichého připojení k síti operátora.

Na Kubernetes má Pod stejný štítek. Helm instaluje default-deny NetworkPolicy, ingress pouze pro preview a internetový egress jen pro síťové Pody kromě work.networkPolicy.blockedEgressCidrs. Účinnost závisí na CNI; viz Kubernetes.

Egress zůstává povolen, protože Work potřebuje balíčky, vzdálený Git a API. Nejde o odchozí firewall. Kód může dosáhnout na služby hostitele, LAN, internet a podle nasazení metadata infrastruktury.

Hooky zásady odchozího provozu

Pro přísnější hranici kombinujte:

• WORK_RUNTIME_DNS (Docker) — čárkami oddělené IPv4/IPv6 resolvery vynucené na každém síťovém sandboxu (--dns). Filtrovaný resolver poskytne seznamy podle názvů. Neadresy se odmítnou a logují, takže nelze injektovat Docker flags.
• Firewall hostitele či upstreamu (Docker) pro subnet řízené bridge.
• WORK_NETWORK_NAME (Docker) na předem vytvořenou síť s vlastními volbami driveru. Libre WebUI vyžaduje řízený label a vypnuté ICC.

DNS neomezuje egress na doslovnou IP. Záruka vyžaduje i firewall hostitele, clusteru nebo upstreamu.

Nepředpokládejte, že Work brání odesílání dat. Přístup dejte jen důvěryhodným uživatelům a pro offline úlohu použijte zásadu bez sítě. Globální proměnná měnící výchozí zásadu neexistuje.

Síť nepřidává přihlašovací údaje. Libre WebUI nepřipojuje SSH klíče, cloudové údaje, profily prohlížeče, domovskou složku ani Docker socket. Kód však může odeslat údaje zapsané do /workspace.

Provoz sandboxu je oddělen od modelového provozu. Požadavky Ollama/pluginu odesílá backend vždy explicitně vybranou trasou.

Bezpečnostní hranice sandboxu

Docker kontejner Work:

• běží jako non-root UID/GID 1000:1000;
• používá /workspace jako pracovní adresář;
• připojuje pouze pojmenovaný volume vybrané úlohy na /workspace;
• používá read-only kořenový systém a omezené dočasné /tmp;
• odstraňuje všechny Linux capabilities;
• zapíná no-new-privileges;
• není privileged a používá init proces;
• omezuje CPU, paměť, procesy, dobu příkazu a výstup;
• nastavuje swap na limit paměti (--memory-swap se rovná --memory), takže limit nelze obejít swapem;
• připojuje se k řízené síti bez komunikace mezi kontejnery nebo vůbec k žádné; a
• publikuje pouze preview port na loopback port hostitele přidělený Dockerem.

Vše se před opětovným použitím ověří přes docker inspect a hash sady se uloží v labelu ai.libre-webui.policy. Kontejner se starší zásadou se po upgradu zničí a znovu vytvoří, aby se hardening promítl do stávajících úloh.

Kubernetes driver aplikuje obdobný bezpečnostní kontext Podu: non-root UID/GID, read-only root, RuntimeDefault seccomp, bez privilege escalation, odstraněné capabilities, omezené ephemeral storage, resource limity, bez ServiceAccount tokenu a PVC úlohy na /workspace. Před opětovným použitím či smazáním ověřuje labels a otisk zásady.

Kontrola cest odmítá absolutní cesty, traversal, backslashes, NUL a příliš dlouhé cesty. Pomocníci vyřeší skutečné cesty a odmítnou únik symlinkem. Zápis používá dočasný soubor a atomický rename.

Tyto kontroly omezují náhodné vystavení hostitele, ale nedělají z Work virtuální stroj ani bezpečné prostředí pro analýzu malware. Kontejnery sdílejí jádro hostitele; zranitelnost Dockeru, Kubernetes, runtime, image, závislosti či jádra může hranici překročit.

Pojmenované Docker volumes nemají vlastní diskovou kvótu. Generovaný projekt nebo balíčky mohou úložiště zaplnit; sledujte růst a nastavte hostitelské limity. Kubernetes požádá o velikost PVC, ale vynucení závisí na storage provisioner.

Kontrolní seznam produkčního hardeningu Dockeru

Seznam platí pro Docker backend. Operátoři Kubernetes musí ověřit také namespace RBAC chartu, bezpečnost Podu, storage class a vynucení CNI NetworkPolicy podle Kubernetes.

Aplikace umí nastavit flags kontejneru, ověřit cesty a chránit API. Nemůže vynutit firewall hostitele, kvóty storage driveru ani oprávnění poskytnutého daemonu. Jde o explicitní práci nasazení.

1. Izolujte ovládání Dockeru

Hlavní kontejner Libre WebUI potřebuje ovládat daemon kvůli vytváření a kontrole Work kontejnerů. Připojený socket je proto přihlašovací údaj control plane; kompromitovaná webová aplikace může kompromitovat hostitele.

docker-compose.socket-proxy.yml drží socket mimo kontejner Libre WebUI. Interní proxy drží /var/run/docker.sock a předává jen containers, images, volumes, networks, exec a info; swarm, secrets, configs, build, commit a system odmítá. Libre WebUI ji používá přes DOCKER_HOST=tcp://docker-socket-proxy:2375 bez socketu či skupiny. CLI, terminál a diagnostika používají stejný endpoint. Proxy zužuje API, nikoli dopad povolených endpointů: kdo vytváří kontejnery, může stále bind-mountovat hostitelské cesty.

Silnější hranicí je dedikovaná VM bez dalších workloadů, případně dedikovaný rootless daemon či samostatný runtime hostitel. Před nasazením ověřte vlastnictví souborů, routing náhledu, úklid a terminál. Read-only připojení stejného rootful socketu z API read-only neudělá.

2. Blokujte správu hostitele ze sandboxu

Vypnutí komunikace kontejnerů neblokuje služby na hostiteli. Prohlédněte skutečnou bridge a subnet:

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

Trvalým firewallem hostitele odmítněte provoz z bridge zejména na SSH, Docker API, databáze a administraci. Otestujte pravidlo z dočasného kontejneru na libre-webui-work, povolené stahování a trvalost. DOCKER-USER řídí forwardovaný provoz; cíl na hostiteli může potřebovat také INPUT pravidlo.

3. Omezte odchozí cíle

Blokujte cloud metadata, soukromé rozsahy a klientskou LAN z Work subnetu, pokud je projekt nepotřebuje. Kombinujte filtrování DNS přes WORK_RUNTIME_DNS s firewallem. DNS lze obejít IP adresou a samotná HTTP proxy nestačí, dokud příkaz smí otevřít přímé spojení; zásadu vynucujte mimo kontejner.

Vytvořte zvláštní runtime zásady pro offline, pouze registry a otevřený egress. Zásada určuje připojení sandboxu, firewall/proxy cílová omezení.

4. Vynucujte skutečné kvóty úložiště

Limity CPU, paměti, swapu a PID neomezují pojmenovaný volume. Použijte úložiště s kvótou na prostor, například XFS project quotas, kvótované logické volumes nebo volume/PVC driver s velikostí. Výchozí Docker local na ext4 kvótu pouhým údajem nezíská.

Sledujte každý volume ai.libre-webui.managed=true i datový kořen Dockeru, upozorněte před zaplněním a testujte selhání. UI počítadlo či du varuje, ale nevynucuje.

5. Ověřte nasazenou zásadu

Po změně image či daemon policy vytvořte dočasnou úlohu a pomocí docker inspect ověřte non-root UID, read-only root, odstraněné capabilities, no-new-privileges, limity paměti/swapu/CPU/PID, pouze volume úlohy a správnou síť. Ověřte také mounts hlavního kontejneru a veřejný ingress přes ověřenou proxy/tunel, nikoli náhodně publikovaný port.

Bezpečnost a dostupnost náhledu

Docker driver publikuje preview port na dynamický port backendového loopbacku. Kubernetes používá přímo IP sandbox Podu. Model ani prohlížeč nemohou vybrat libovolný upstream. Libre WebUI podepíše capability URL přesné úlohy/endpointu, při každém požadavku kontroluje běh a proxyuje HTTP/WebSocket přes /api/work/previews. Stop či restart starou URL odvolá.

Odpovědi odstraňují přihlašovací údaje Libre WebUI a upstream cookies. HTML omezuje iframe sandbox a CSP, který dovoluje skripty, formuláře, dialogy a stahování bez same-origin přístupu. CSP chrání i samostatnou kartu. Generovaný kód zůstává nedůvěryhodný a může přes síť odeslat cokoli ze svého prostoru či vstupu prohlížeče. URL náhledu považujte za krátkodobé tajemství.

Proxy používá veřejný origin Libre WebUI, takže vzdálené prohlížeče a HTTPS proxy fungují bez portů Dockeru/Pod IP a mixed content. Reverse proxy musí zachovat WebSocket upgrade na /api/work/previews/; dodaná konfigurace Nginx to dělá.

Hlavní aplikace povoluje jako frame sources pouze vlastní origin a Cloudflare Turnstile. Odpovědi náhledu obcházejí hlavní Helmet policy pro stream request body a užší sandbox policy. Cross-origin embedder policy zůstává vypnutá, protože dev servery obvykle neposílají kompatibilní hlavičky.

Matice nasazení

Dostupnost Work závisí na stroji a procesu backendu, nikoli jen prohlížeči či desktopu.

Nasazení	Běhy a soubory Work	Vložený náhled
npx libre-webui na místním počítači	Podporováno, pokud Docker běží a backend jej smí volat.	Přes podepsanou same-origin proxy.
Vývoj ze zdrojů místně	Stejné požadavky Dockeru a poskytovatele.	Přes vývojový API origin na portu 3001.
Electron klient	Podmíněné; používá externí backend a neposkytuje vlastní Work runtime.	Přes podepsanou URL backendu.
Bare-metal/VM backend vzdáleně	Běhy, soubory a poskytovatel fungují s Dockerem na hostiteli.	Pokud veřejná proxy zachová HTTP/WebSocket.
Standardní Docker Compose	Výchozí podpora na Docker Desktopu: image má Docker CLI, Compose připojuje socket a porty Work vedou přes host.docker.internal. Nativní Docker Engine navíc potřebuje dosažitelné neveřejné WORK_PREVIEW_BIND.	Přes veřejný origin Libre WebUI.
Současný Kubernetes/Helm	Podporováno s --set work.enabled=true: sandboxy jako Pody s PVC, namespace RBAC a default-deny NetworkPolicies bez Docker socketu. Viz Kubernetes.	Backend v clusteru proxyuje přímo na Pod IP.

Spuštění Work, když Libre WebUI běží v Dockeru

Všechny Compose soubory repository Work zapínají: image má Docker CLI a připojí /var/run/docker.sock. Docker Desktop funguje s dodávaným výchozím směrováním; nativní Docker Engine navíc potřebuje WORK_PREVIEW_BIND nastavené na neveřejné rozhraní hostitele dosažitelné ze sourozeneckých kontejnerů, jak je popsáno níže. Work řídí daemon hostitele, takže kontejnery úloh jsou sourozenci kontejneru Libre WebUI, zobrazí se v docker ps a uklízí se stejnými pravidly.

Socket ve webové aplikaci dává kontrolu nad hostitelem jako root. Důsledek je explicitní: každý administrátor Libre WebUI je prakticky administrátorem Docker hostitele. Operátor vlastní bezpečnostní, síťové, životní, zálohovací a přístupové důsledky. Odstraněním řádku /var/run/docker.sock Work vypnete.

Pro Work bez socketu ve webapp použijte docker-compose.socket-proxy.yml; interní proxy drží socket a Libre WebUI ji používá přes DOCKER_HOST. Viz Izolujte ovládání Dockeru.

Musí platit tři podmínky a panel pojmenuje selhání:

1. Docker CLI musí být v image. Oficiální jej obsahuje; vlastní image potřebuje docker-cli nebo WORK_DOCKER_COMMAND. Jinak: The "docker" CLI is not installed….
2. Socket musí být připojen. Jinak: No Docker daemon is reachable….
3. Backendový uživatel musí být ve skupině socketu. Image běží jako nodejs (uid 1001), socket obvykle vlastní root či docker a Compose používá group_add: ['${DOCKER_GID:-0}']. Docker Desktop vyhovuje výchozí hodnotě, Linux potřebuje vlastní id. Jinak: 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

Preview porty zůstávají na loopbacku Docker hostitele a zpřístupňují se podepsanou same-origin proxy včetně WebSocketu. Fungují za HTTPS/tunely bez otevření portů a stop/restart odvolá URL.

Když backend běží v Dockeru, může se lišit bind a adresa spojení. Ponechte WORK_PREVIEW_BIND=127.0.0.1 a WORK_DOCKER_PUBLISHED_HOST nastavte na adresu Docker hostitele dosažitelnou z backendu (host.docker.internal na Docker Desktop). Dodávané profily Compose obě hodnoty nastavují a jméno hostitele mapují. Nativní Linux musí WORK_PREVIEW_BIND přepsat bránou mostu Docker (nebo jiným výslovně dosažitelným neveřejným rozhraním hostitele); samotné mapování host.docker.internal nezpřístupní loopback listener. Tyto surové dočasné porty nikdy nevažte na 0.0.0.0.

Souběh je omezen zvlášť: WORK_MAX_ACTIVE_RUNTIMES_PER_USER je výchozí 2 a WORK_MAX_ACTIVE_RUNTIMES_GLOBAL 3, takže administrátor může spustit druhou úlohu. Capabilities odpověď uvádí limity i obsazení.

Na Kubernetes instalujte chart s work.enabled=true bez runtime socketu uzlu. Chart vytvoří RBAC, namespace, NetworkPolicies a Pod/PVC konfiguraci podle Kubernetes.

Konfigurace runtime

Work čte v backendu tyto proměnné:

Proměnná	Výchozí	Účel
WORK_RUNTIME_BACKEND	docker	Driver sandboxu: docker nebo kubernetes
WORK_RUNTIME_IMAGE	node:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3	Image sandboxů
WORK_DOCKER_COMMAND	docker	CLI Docker backendu
WORK_COMMAND_TIMEOUT_MS	120000	Výchozí timeout příkazu
WORK_MAX_OUTPUT_CHARS	50000	Maximum zachyceného výstupu
WORK_MAX_AGENT_ROUNDS	48	Kola modelu/nástrojů na běh
WORK_MEMORY_LIMIT	2g	Paměť na kontejner
WORK_CPU_LIMIT	2	CPU na kontejner
WORK_PIDS_LIMIT	256	Procesy na kontejner
WORK_PREVIEW_PORT	4173	Port aplikace uvnitř kontejneru
WORK_PREVIEW_BIND	127.0.0.1	Hostitelské rozhraní preview portu
WORK_DOCKER_PUBLISHED_HOST	stejné jako WORK_PREVIEW_BIND	Hostitel/IP volaný backendem
WORK_COMPUTER_SCREEN_PORT	6080	WebSocket port obrazovky
WORK_COMPUTER_AUDIO_PORT	6081	WebSocket port zvuku
WORK_RUN_LEASE_WAIT_MS	60000	Čekání na dočasný lease
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL	3	Souběžné úlohy v instanci
WORK_MAX_ACTIVE_RUNTIMES_PER_USER	2	Souběžné úlohy na administrátora
WORK_MAX_TASKS_GLOBAL	500	Trvalé úlohy v instanci
WORK_MAX_TASKS_PER_USER	100	Trvalé úlohy na administrátora
WORK_NETWORK_NAME	libre-webui-work	Řízená bridge síť
WORK_RUNTIME_DNS	nenastaveno	Resolver IP pro síťové úlohy
WORK_DOCKER_SOCKET	DOCKER_HOST při unix:// či tcp://, jinak /var/run/docker.sock	Docker Engine endpoint terminálů
WORK_TERMINAL_MAX_SESSIONS_PER_TASK	2	Souběžné terminály na úlohu
WORK_TERMINAL_IDLE_TIMEOUT_MS	900000	Timeout nečinnosti terminálu
WORK_RUNTIME_IDLE_TIMEOUT_MS	0 (vypnuto)	Zastavit sandbox po nečinnosti
WORK_K8S_NAMESPACE	libre-webui-work	Namespace Pod/PVC
WORK_K8S_STORAGE_CLASS	výchozí clusteru	StorageClass PVC
WORK_K8S_WORKSPACE_SIZE	5Gi	Výchozí velikost PVC
WORK_K8S_POD_READY_TIMEOUT_MS	900000	Čekání na připravený Pod
WORK_K8S_POD_GONE_TIMEOUT_MS	60000	Čekání na zmizení smazaného Podu

V produkci používejte pevnou verzi image či digest. Proměnlivý tag může změnit nástroje i bezpečnostní hranici bez změny Libre WebUI.

Operace běhu, náhledu, souborů, příkazů a znovuvytvoření sdílejí stejné počítání kapacity. Vnořená operace na již započtené úloze se nepočítá znovu. Překročení limitu vrací HTTP 429.

Pevné limity protokolu a UI

Položka	Limit
Nová zpráva úlohy/běhu	65 536 znaků a UTF-8 bajtů
Model ID při vytvoření/úpravě	500 znaků a UTF-8 bajtů
ID poskytovatele pluginu	200 znaků
Aktivní běhy na úlohu	1
Text příkazu	20 000 znaků
Timeout příkazu žádaný nástrojem	1 až 600 sekund
Readiness náhledu	15 sekund
Čtení/zápis souboru	2 000 000 bajtů UTF-8 textu
Přímý seznam složky	Prvních 1 000 položek
Stránka zpráv	Až 200 zpráv a 1 000 000 bajtů
Jedna trvalá zpráva	100 KB
Kontext modelu	Posledních 30 zpráv, až 256 KB
Trvalý výstup nástroje	Přibližně 20 000 zdrojových znaků + marker
Živé zvýraznění	8 000 znaků a 400 řádků
Formátování v prohlížeči	100 000 znaků a 4 000 řádků
Git status	2 000 000 zachycených znaků
Git diff	600 000 zachycených znaků
Historie Git	20 místních commitů
Cesty v jednom stage	200
Zpráva commitu	4 000 znaků
Smyčka agenta, každá trasa	48 kol přes WORK_MAX_AGENT_ROUNDS
Bezpečnostní rozpočet volání	max(128, configured rounds × 8) volání

Soubory jsou UTF-8 text. Editor není binární a soubor nad 2 MB nelze otevřít přes API Work.

Přehled API

Všechny endpointy jsou pod /api/work a vyžadují ověření i aktuální přístup Work z databáze. Work je ve výchozím stavu jen pro administrátory; administrátor může běžné operace otevřít aktivním uživatelům. Hostitelské složky a administrativní endpointy zásad/přístupu zůstávají jen pro administrátory.

Metoda	Cesta	Účel
GET	/capabilities	Dostupnost a limity vybraného runtime/poskytovatele
GET	/tasks	Vypsat úlohy aktuálního administrátora
POST	/tasks	Vytvořit úlohu a první asynchronní běh
GET	/tasks/:id	Načíst stav a nedávné zprávy
GET	/tasks/:id/messages	Stránkovat starší zprávy
PATCH	/tasks/:id	Přejmenovat nebo změnit explicitní modelovou trasu
DELETE	/tasks/:id	Odstranit úlohu a trvalý pracovní prostor
POST	/tasks/:id/runs	Spustit navazující běh
POST	/tasks/:id/messages	Poslat zprávu agentovi během běhu
GET	/tasks/:taskId/runs/:runId/events	Streamovat ověřené live události přes SSE
POST	/tasks/:id/cancel	Zrušit aktivní běh
GET	/tasks/:id/approvals	Čekající schválení a stav Auto Review úlohy
PUT	/tasks/:id/approvals	Přepnout schvalování pro danou úlohu
POST	/tasks/:id/approvals/:approvalId	Rozhodnout čekající schválení (jednou/vždy povolit, odmítnout)
DELETE	/tasks/:id/approval-rules/:ruleId	Odebrat pravidlo Always-allow
GET	/computer/setup	Stav nastavení Work Computer (admin)
POST	/computer/setup	Sestavit GUI image a vytvořit zásadu (admin)
POST	/tasks/:id/computer/start	Spustit Work Computer relaci
GET	/tasks/:id/computer/control	Kdo řídí obrazovku; žádost agenta
POST	/tasks/:id/computer/control	Převzít nebo obnovit kontrolu
DELETE	/tasks/:id/computer/control	Vrátit obrazovku agentovi
POST	/tasks/:id/computer/teach	Uložit demonstraci jako naučenou dovednost
POST	/tasks/:id/computer/anchor	Najít prvek pod zaznamenaným kliknutím
POST	/computer/skills/:slug/trace	Přidat řádek úspěch/selhání
GET	/tasks/:id/files	Vypsat složku pracovního prostoru
GET	/tasks/:id/file	Číst textový soubor
PUT	/tasks/:id/file	Uložit textový soubor
GET	/tasks/:id/git	Číst chráněný místní Git stav/historii
GET	/tasks/:id/git/diff	Číst omezený místní diff
POST	/tasks/:id/git/init	Inicializovat místní Git
POST	/tasks/:id/git/stage	Stage explicitních cest
POST	/tasks/:id/git/commit	Commit staged změn
POST	/tasks/:id/git/branches	Vytvořit místní větev
POST	/tasks/:id/git/switch	Přepnout na existující čistou větev
POST	/tasks/:id/preview/start	Spustit spravovaný náhled
POST	/tasks/:id/preview/stop	Zastavit spravovaný náhled

ID úlohy se vždy kontroluje proti přihlášenému vlastníkovi. Stav účtu, role a přístup Work se při každém požadavku čtou z databáze, takže odvolání platí i se starým JWT.

Aktualizační schéma zachovává backendové pole networkEnabled pro interní kompatibilitu. Nejde o samostatný ovládací prvek UI. Při vytvoření zvolte pojmenovanou runtime zásadu s požadovanou sítí; raw pole nepoužívejte jako trvalé konfigurační API.

Smazání, změny účtu a zálohování

Smazání úlohy

Smazání je záměrně destruktivní:

1. Backend označí úlohu za vyřazovanou, aby nezačala nová mutace.
2. Aktivní běh se zruší a sandbox zastaví.
3. Libre WebUI ověří labels vlastnictví runtime prostředků.
4. Kontejner/Pod a volume/PVC se odstraní.
5. Databázová úloha se smaže a cascade odstraní běhy/zprávy.
6. Koncepty prohlížeče se vymažou po úspěchu API.

Pokud runtime cleanup selže, Libre WebUI ponechá databázový záznam a vrátí chybu, aby operátor opravil Docker/Kubernetes a opakoval. Metadata se nesmažou při zanechání nesledovaného sandboxu.

Zastavení běhu či náhledu je jiné: provádění skončí, ale volume a konverzace se zachovají.

Snížení role administrátora a smazání uživatele

Při snížení role se odvolání uloží před závislostí na cleanupu. Každý další požadavek kontroluje aktuální roli a přístup. Backend pozastaví úlohy, zruší běhy a zastaví sandboxy. Pokud cleanup selže, přístup zůstane odvolaný a aktualizace role hlásí chybu k pozdějšímu opakování.

Při smazání jiného uživatele se nejprve odstraní jeho řízené Work prostředky. Pokud externí cleanup selže, záznam uživatele se ponechá, aby se neztratila metadata vlastnictví.

Záloha celé úlohy

Úplná záloha Work potřebuje:

• databázi Libre WebUI s vlastnictvím, názvy Docker/Kubernetes prostředků, směrováním, běhy, zprávami a aktivitou; a
• každý Docker volume či Kubernetes PVC s labelem ai.libre-webui.managed=true, obsahující soubory Work.

Dočasné kontejnery a previewprocesy zálohu nepotřebují. Před snapshotem databáze a prostorů zastavte novou Work aktivitu i backend. Postupujte podle procesu snapshotu Docker volume nebo úložiště Kubernetes.

Databázi a odpovídající prostory obnovte společně. Volume/PVC vytvořte pod přesným databázovým názvem a obnovte metadata včetně ai.libre-webui.task=<task UUID> a ai.libre-webui.managed=true. Pouhé soubory nezachovají labels; pouze databáze dá úlohy bez souborů; pouze úložiště ztratí vlastnictví a názvy.

Při šifrovaných údajích poskytovatele dodržte hlavní pokyny pro datovou složku a šifrovací klíč.

Lokalizace a arabské RTL

Celé rozhraní Work je přeloženo do všech 25 podporovaných jazyků: angličtiny, arabštiny, bengálštiny, češtiny, dánštiny, němčiny, španělštiny, francouzštiny, hindštiny, indonéštiny, islandštiny, italštiny, japonštiny, korejštiny, malajštiny, nizozemštiny, polštiny, portugalštiny, ruštiny, švédštiny, thajštiny, turečtiny, ukrajinštiny, vietnamštiny a čínštiny.

Arabština aplikuje lang="ar" a dir="rtl" před vykreslením Reactu. Panel se přesune doprava, Conversation je vpravo, Workspace vlevo, ikony se zrcadlí, karty sledují RTL a změna velikosti používá vizuální RTL sémantiku.

Technický obsah zůstává zleva doprava tam, kde záleží na správnosti:

• kód a zvýraznění syntaxe;
• cesty souborů;
• identifikátory modelů;
• příkazy a logy náhledu;
• výsledky nástrojů a metadata; a
• obsah bloků kódu.

Názvy úloh, prompty, chyby, názvy souborů a příkazy náhledu používají podle potřeby automatický směr textu.

Řešení problémů

Runtime není dostupný s npx

npx libre-webui spouští backend na hostiteli, ale neinstaluje Docker. Spusťte docker info pod stejným systémovým uživatelem. Pokud příkaz chybí či nedosáhne na daemon, Docker nainstalujte/spusťte nebo opravte oprávnění a Work obnovte.

Ověřte také zdraví Ollama nebo alespoň jeden aktivní completion/chat plugin s modelem a údaji administrátora.

Runtime není dostupný v Dockeru nebo Kubernetes

Compose z repository by to hlásit neměl: image má Docker CLI a připojený socket. Panel uvede příčinu — chybějící CLI, socket či skupinu. Pro skupinu nastavte DOCKER_GID a kontejner znovu vytvořte. Viz Work v Dockeru.

Na Kubernetes zapněte native runtime pomocí --set work.enabled=true. Libre hlásí kubernetes, testuje API a spouští Pody s PVC. Nepřipojujte runtime socket uzlu; viz Kubernetes.

Žádné modely kompatibilní s Work

U Ollama vyberte model uvádějící tools. U pluginu ověřte typ completion/chat, aktivaci, přesný model v mapě, použitelný API klíč administrátora a podporu volání nástrojů. Work nikdy nepřechází k jinému poskytovateli.

Selže instalace balíčku nebo vzdálený Git

Ověřte zapnutou síť vybrané zásady. Samostatný přepínač neexistuje. Zkontrolujte DNS, proxy, firewall/NetworkPolicy, registry, certifikát, runtime a upstream i přítomnost příkazu v image.

Karta Git je pouze místní a vzdálené operace nedělá. Terminal/modelové příkazy používejte jen při záměrně povolené síti a údajích. Do prostoru nevkládejte dlouhodobý token.

Běh se zastaví na limitu agenta

Model mohl vyčerpat rozpočet kol či volání. Work před koncem požádá o závěrečnou předávku bez nástrojů; zkontrolujte dokončenou práci a kroky. Úloha zůstane Needs input, aniž tvrdí dokončení. Pokračujte navazujícím během nebo záměrně zvyšte WORK_MAX_AGENT_ROUNDS, pokud to zdroje a ceny dovolují.

HTTP 429 při spuštění práce

Instance či administrátor dosáhl limitu aktivních runtime nebo úloh. Počkejte na zastavení běhu/náhledu, smažte staré úlohy nebo zvyšte příslušné WORK_MAX_* na dostatečném hostiteli.

Náhled se nepřipraví

Příkaz musí zůstat běžet, bindovat 0.0.0.0 a poslouchat na WORK_PREVIEW_PORT do 15 sekund. Prázdný příkaz automaticky hledá script dev v package.json nebo index.html, i v jedné vnořené aplikaci. Při více aplikacích zadejte explicitní příkaz; pro vnořenou použijte cd <app-directory> && ... z /workspace.

Náhled funguje na serveru, ale ne vzdáleně

Ověřte podepsanou proxy a náhled restartujte. Pokud fungují stránky, ale ne hot reload, proxy/tunel musí povolit WebSocket na /api/work/previews/. Docker port zůstává na loopbacku a firewall se neotevírá.

Soubory zůstaly, náhled se zastavil

To je očekávané po zrušení, restartu, explicitním stopu či chybě readiness. Proces náhledu je dočasný, volume trvalý. Otevřete úlohu a spusťte jej znovu.

Soubor nelze otevřít či uložit

API přijímá UTF-8 text do 2 MB. Změněný soubor před úpravou obnovte, abyste nepřepsali novější změnu. Zvýraznění se nad 8 000 znaků či 400 řádků přepne na plaintext; formátování má limit 100 000 znaků a 4 000 řádků.

Work hlásí obnovu sandboxů

Start či teardown neprokázal zastavení známých sandboxů. Work zůstává bezpečně uzavřen a opakuje každých 10 sekund. Obnovte Docker/Kubernetes API a zkontrolujte log. Databázové řádky nemažte před reconciliation prostředků.

Úlohu nelze smazat

Ověřte dosažitelnost runtime. Konfliktní prostředek bez ai.libre-webui.task labelu se záměrně odmítne. Konflikt názvu/vlastnictví vyřešte a opakujte.

Bezpečnostní souhrn

Před zapnutím Work pamatujte:

• Work je ve výchozím stavu jen pro administrátory; otevření všem dělá z každého aktivního účtu operátora sandboxu. Hostitelské složky zůstávají admin-only.
• Backend musí ovládat Docker daemon nebo Kubernetes namespace.
• Kontejnery omezují soubory, ale nejsou VM.
• Bez offline zásady má úloha egress; cílová omezení jsou odpovědnost operátora.
• Volumes Work nemají vlastní diskovou kvótu.
• Karta Git je místní; vzdálené údaje se nemontují ani nepřijímají.
• Firewall, izolace daemonu, egress a kvóty vynucuje operátor.
• Vzdálení poskytovatelé dostávají výsledky nástrojů a mohou účtovat více volání.
• Preview porty jsou na loopbacku a přístupné jen podepsanými odvolatelnými URL.
• Docker Compose poskytuje Docker runtime a Kubernetes/Helm Pod/PVC při work.enabled=true.
• Úplná záloha vyžaduje databázi i volumes Work.

Související dokumentace

• Rychlý start
• Práce s modely
• Klávesové zkratky
• Proměnné prostředí
• Docker
• Kubernetes
• Ověření
• Řešení problémů