Work : espaces de travail isolés

Work est l’interface native d’agent de codage de Libre WebUI. Chaque tâche Work associe une conversation durable, une route explicite vers un fournisseur de modèles et un système de fichiers dédié sous /workspace. Le modèle sélectionné peut examiner et modifier les fichiers, exécuter des commandes dans un conteneur Docker ou un Pod Kubernetes propre à la tâche et démarrer un aperçu dans le navigateur.

Work est directement intégré à Libre WebUI. Il ne nécessite ni Libre Claw ni un autre démon d’agent.

Utilisateurs de confiance uniquement

Chaque API Work exige un compte authentifié disposant d’un accès à Work. Par défaut, seuls les administrateurs en bénéficient ; un administrateur peut ouvrir Work à tous les utilisateurs actifs depuis l’onglet Gestion des utilisateurs des Paramètres (les espaces liés à un dossier de l’hôte restent réservés aux administrateurs, car ils montent des chemins du serveur). Work permet délibérément à un modèle d’exécuter des commandes shell arbitraires dans un bac à sable. Les tâches disposent d’une sortie réseau, sauf si la politique d’exécution nommée sélectionnée la désactive. Considérez toute personne à laquelle vous accordez l’accès à Work comme un opérateur d’exécution de confiance, et non comme un simple utilisateur du chat.

Points forts de cette version

Cette version introduit Work comme un flux de tâches complet :

• Des actions Work et Chat distinctes dans la barre latérale principale, avec une indication claire du mode actif.
• Les tâches Work dans la barre latérale normale, sans second rail de tâches. Les positions existantes restent stables pendant la mise à jour des exécutions et la tâche sélectionnée peut être supprimée directement.
• Une identité de bac à sable dédiée et un volume Docker persistant ou un PVC Kubernetes pour chaque tâche. Les bacs à sable peuvent être arrêtés ou recréés sans supprimer les fichiers de la tâche.
• La conversation durable, l’état de l’exécution, l’activité des outils, la sélection du modèle et la propriété de la tâche dans la base de données de Libre WebUI.
• Un flux d’exécution authentifié et en direct pour le texte de l’assistant, le raisonnement exposé par le fournisseur, les appels d’outils et leurs résultats, l’utilisation, les compétences du worker et les changements d’état.
• Des compétences de worker détenues par le serveur, qui apprennent au modèle sélectionné à examiner, modifier, vérifier et prévisualiser efficacement, sans écrire de fichiers de contrôle dans le projet.
• Les modèles Ollama locaux capables d’utiliser des outils, les modèles Ollama Cloud et les plugins configurés de complétion ou de chat.
• Une répartition adaptative entre Conversation et Espace de travail, dont la taille peut être réglée par glissement ou au clavier sur ordinateur, ainsi qu’un sélecteur de surface ciblé sur les écrans plus petits.
• Des vues intégrées Fichiers, Activité, Git, Terminal, Aperçu et Écran ; la vue Écran correspond au bureau Work Computer observable et propice à l’apprentissage.
• La coloration syntaxique en mode clair et sombre, la mise en forme du code côté navigateur, la détection des conflits d’enregistrement et des brouillons temporaires non enregistrés.
• Une information propre à chaque utilisateur et masquable lorsqu’un fournisseur de modèles distant est sélectionné.
• Des traductions Work complètes dans les 25 langues prises en charge, notamment une mise en page arabe native de droite à gauche, tandis que le code, les chemins, les identifiants de modèles et la sortie des commandes restent de gauche à droite.

L’unité persistante est l’espace de travail de la tâche, et non un conteneur qui fonctionne en permanence. Libre WebUI démarre, arrête et peut recréer le conteneur de la tâche selon les besoins, tout en conservant son volume nommé.

Architecture

Libre WebUI, plutôt que le modèle ou le navigateur, choisit les noms du bac à sable et de l’espace de travail, l’image, le montage, l’utilisateur, les limites, le mode réseau et le port d’aperçu. Le modèle ne reçoit que les outils suivants :

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

delete_file et move_file sont protégés au niveau des chemins, comme les autres outils de fichiers : ils refusent de sortir de l’espace de travail, ne traversent jamais les liens symboliques, exigent un indicateur récursif explicite avant de supprimer un répertoire et n’écrasent jamais la destination d’un déplacement. Comme ils passent par l’outil d’assistance des fichiers plutôt que par un shell, ils fonctionnent aussi pendant l’exécution d’un aperçu, lorsque run_command est bloqué.

Les requêtes adressées au modèle sont émises par le backend Libre WebUI. Elles ne proviennent pas du conteneur Work et ne dépendent pas de sa politique réseau.

Configuration requise

Work exige un backend de bac à sable configuré :

• Le backend par défaut nécessite l’installation de Docker, un démon accessible et l’autorisation pour le processus du backend d’appeler docker (ou l’exécutable configuré avec WORK_DOCKER_COMMAND).
• Le backend Kubernetes nécessite des identifiants d’API, ainsi que le Role, le RoleBinding, l’espace de noms des bacs à sable et les NetworkPolicies créés par le chart Helm lorsque work.enabled=true.

Chaque backend exige également :

• Un modèle capable d’utiliser des outils, exposé par :
  • un service Ollama sain, notamment pour les modèles accessibles via Ollama Cloud ; ou
  • un plugin de complétion ou de chat actif avec un modèle configuré exactement et des identifiants pour l’administrateur actuel.
• Un stockage d’exécution suffisant pour l’image, les projets générés et les dépendances locales aux projets.
• Un compte authentifié ayant accès à Work. Work est réservé aux administrateurs par défaut ; un administrateur peut l’ouvrir à tous les utilisateurs actifs.

Libre WebUI vérifie les capacités de modèle annoncées par Ollama avant de créer une exécution et rejette tout modèle Ollama qui n’annonce pas tools. Les modèles fournis par des plugins doivent prendre en charge le protocole d’appels d’outils de leur fournisseur. Si le modèle distant choisi refuse les outils, l’exécution échoue ; Work ne bascule pas silencieusement vers un autre modèle ou fournisseur.

Démarrer en local

Pour la configuration Work prise en charge la plus simple, exécutez Libre WebUI et Docker sur le même ordinateur que le navigateur :

docker info
npx libre-webui@latest

Ouvrez http://localhost:8080, connectez-vous en tant qu’administrateur, sélectionnez Work dans la barre latérale, choisissez un modèle compatible et décrivez le projet ou la modification.

Si Docker est absent, arrêté ou inaccessible, Work affiche Environnement d’exécution indisponible, accompagné du motif du backend, et désactive le compositeur Exécuter. Libre WebUI ne se rabat jamais sur l’exécution des commandes Work directement sur l’hôte.

L’image d’exécution est inspectée lors de sa première utilisation et récupérée automatiquement si elle est absente. La première opération peut donc prendre plus de temps que les suivantes.

Utiliser l’interface Work

Créer et rouvrir des tâches

Sélectionnez Work à côté de Chat dans la barre latérale. Saisissez une instruction, choisissez un modèle et sélectionnez Exécuter. Le premier message crée la tâche, sa première exécution, sa route de fournisseur et son espace de travail persistant.

Chaque tâche reste dans la barre latérale principale. Lorsque vous la rouvrez, sa conversation récente, sa vue Fichiers, la sélection actuelle du fournisseur et du modèle, ainsi que son espace de travail, sont restaurés. Les anciens messages de la conversation peuvent être chargés par pages. Vous pouvez renommer la tâche depuis son titre et la supprimer définitivement depuis le menu de la tâche sélectionnée ou la barre latérale.

Une seule exécution peut être active pour une tâche. Une instruction ultérieure crée une autre exécution qui utilise la même conversation et le même système de fichiers.

Le compositeur accepte la dictée : le bouton du microphone utilise l’API vocale du navigateur lorsqu’elle est disponible, ou un modèle de fournisseur de conversion de la parole en texte configuré comme solution de repli, puis ajoute la transcription au texte déjà saisi. Dans la conversation, les fichiers qu’une exécution a créés ou déplacés apparaissent sous forme de pastilles cliquables sous l’activité de l’outil qui les a produits. Cliquer sur une pastille ouvre le fichier dans l’éditeur Fichiers de l’espace de travail et, sur un écran étroit, bascule vers la surface de l’espace de travail. Seuls les outils qui modifient des fichiers produisent des pastilles : une exécution qui lit vingt fichiers mais n’en écrit qu’un affiche exactement cet artefact.

Recruter un agent

La vue d’accueil propose Recruter comme agent lorsque vous disposez de personas : choisissez-en une et la tâche créée devient un agent nommé persistant plutôt qu’une tâche ponctuelle. Un agent conserve sa persona d’une exécution à l’autre. Le nom et l’invite système de la persona sont ajoutés au début de l’invite système de Work, mais le contrat d’environnement du bac à sable prévaut toujours. La barre latérale épingle les agents dans leur propre groupe Agents, au-dessus des tâches ponctuelles, avec l’avatar de la persona, un indicateur d’activité et une ligne d’état. Lorsque la barre latérale est réduite, seuls ces avatars d’agents épinglés restent dans le rail ; les tâches Work ponctuelles réapparaissent une fois la barre latérale déployée.

Cette ligne comporte deux niveaux. Pour un agent recruté, une requête peu coûteuse au modèle, sans outils, demande à la fin de l’exécution un état d’environ huit mots (« Boîte de réception vide. 2 réponses prêtes. »). La réponse est limitée à une seule ligne de 90 caractères ; un échec ou un dépassement de délai revient au niveau déterministe, à savoir la première ligne du dernier message de l’assistant. Les tâches ponctuelles et les exécutions échouées utilisent uniquement le niveau déterministe, et WORK_STATUS_BLURB_MODEL=0 désactive entièrement la requête au modèle. Les agents ont aussi un indicateur de non-lu : ouvrir la tâche avance un marqueur de consultation par tâche, monotone et synchronisé entre appareils, et la barre latérale affiche un point si une exécution atteint un état terminal après ce marqueur.

Les agents rendent également compte de leur activité par les notifications, dans l’application et, si elle est activée, par notification web : work-run-finished lorsqu’une exécution se termine, work-run-attention lorsqu’elle attend une intervention ou échoue, et work-takeover dès que l’agent demande à une personne de prendre le contrôle de son écran. La bannière à l’écran n’est visible que lorsque l’onglet Écran est ouvert ; la notification est donc ce qui vous atteint ailleurs. Chaque notification ouvre directement l’agent.

Vous pouvez recruter avec une persona qui vous appartient ou qui est partagée avec vous ; la vue partagée n’expose jamais les souvenirs de persona du propriétaire. Si la persona est supprimée ultérieurement, l’agent continue sans elle et un avertissement est journalisé. L’API accepte personaId et isAgent à la création d’une tâche ; une tâche créée avec une persona devient automatiquement un agent.

L’onglet Agent

Le volet d’espace de travail d’un agent s’ouvre sur un premier onglet supplémentaire, Agent, qui constitue sa propre page :

• Identité : avatar et nom de la persona, indicateur d’activité et dernière ligne d’état.
• Écran : lorsque la politique de la tâche accorde le Work Computer, une miniature compacte et en direct, en lecture seule, de l’écran de l’agent. Il s’agit d’un vrai visualiseur, comptabilisé dans la limite de visualiseurs par tâche. Cliquer dessus ouvre l’onglet Écran complet, où sont disponibles la prise de contrôle, l’enseignement et l’audio.
• Routines : les automatisations liées à cette tâche. Chaque déclenchement s’exécute dans l’espace de travail et la conversation de l’agent avec son modèle et son environnement, et non dans une nouvelle tâche. Une routine de briefing matinal s’accumule ainsi au même endroit. Les lignes décrivent la planification avec un bouton pause/reprise, et le formulaire + Routine intégré est déjà lié à l’agent. Une occurrence déclenchée pendant que l’agent est occupé échoue honnêtement avec work-task-busy au lieu d’être mise en file d’attente.
• Vérification automatique : l’interrupteur d’approbations propre à l’agent et les règles « Toujours autoriser » qu’il a accumulées ; retirer une règle referme sa portée. Lorsque la politique de la tâche impose la vérification, l’interrupteur est verrouillé en position active.
• Compétences enseignées : procédures montrées en mode Enseigner, avec un bouton d’activation ou de désactivation pour chaque compétence.

Outils connectés (serveurs MCP et OpenAPI)

Les agents Work peuvent appeler les mêmes serveurs d’outils que ceux configurés pour le chat, en MCP ou OpenAPI, enregistrés par un administrateur sous Paramètres → Outils. Les outils apparaissent à l’agent sous leur nom qualifié (server__tool) et les appels partent du backend de Libre WebUI par la passerelle d’outils renforcée (sorties protégées contre le SSRF, identifiants propres à chaque utilisateur, limites de taille et de durée), jamais depuis l’intérieur du bac à sable.

L’offre reste honnête sur ce qu’une exécution autonome peut réellement utiliser :

• Une tâche hors ligne n’en propose aucun : que la sortie passe ou non par le backend, une tâche privée de réseau reste hors ligne, pour la même raison que web_search.
• Un serveur qui exige un identifiant personnel que l’utilisateur n’a pas enregistré est écarté au moment de l’offre, car une exécution autonome ne peut pas s’interrompre pour le demander. Ajoutez l’identifiant sous Paramètres → Outils et l’exécution suivante propose le serveur.
• Le mode d’accès aux outils (administrateurs uniquement ou tous les utilisateurs) et la visibilité par serveur s’appliquent exactement comme dans le chat, et les serveurs d’outils liés à une persona restreignent ceux que voit l’agent recruté sous cette persona.
• Lorsque les approbations sont actives, les outils connectés que le serveur classe comme produisant un effet attendent votre décision comme toute action soumise à contrôle ; les outils en lecture seule s’exécutent sans rien demander.

Délégation entre agents (mentions @)

Les agents recrutés peuvent se transmettre du travail. Tapez @ dans la zone de rédaction Work pour mentionner l’un de vos autres agents : l’agent en cours voit dans ses instructions la liste de ses pairs, avec leurs noms et leurs lignes d’état, et délègue les demandes correspondantes avec l’outil message_agent. La délégation coordonne par messages, et délibérément pas par ordinateurs partagés : chaque agent conserve son espace de travail et son bac à sable isolés, et la cible ne voit pas la conversation d’origine. La demande doit donc porter son propre contexte.

La délégation est asynchrone. L’outil rend la main immédiatement, l’agent cible s’exécute dans sa propre tâche — sa conversation affiche la demande étiquetée Délégué par l’expéditeur — et lorsqu’il termine, qu’il ait abouti, demandé une intervention, échoué ou été annulé, sa réponse finale est livrée dans la conversation de l’agent délégant sous forme de message étiqueté Rapport de cet agent. Si le délégant est encore en cours d’exécution, le rapport parvient à son modèle au tour suivant ; s’il est inactif, le rapport attend simplement dans la conversation, car un rapport ne démarre jamais une exécution de lui-même : deux agents ne peuvent donc pas se renvoyer la balle indéfiniment. Une exécution déléguée ne peut pas déléguer à son tour, une cible occupée fait échouer honnêtement la tentative au lieu de la mettre en attente, et lorsque les approbations sont actives, message_agent s’arrête pour vérification comme toute autre action produisant un effet, une règle « Toujours autoriser » ne portant alors que sur cet agent cible.

Approbation des actions (Vérification automatique)

Les actions produisant un effet peuvent attendre votre décision avant de s’exécuter. Lorsque les approbations sont actives pour une tâche, parce que sa politique Work active Exiger une approbation pour les actions produisant un effet ou parce que l’interrupteur Vérification automatique de l’agent est activé, l’exécution s’arrête avant d’exécuter run_command, computer_act, delete_file, move_file ou message_agent et affiche une carte de décision dans la conversation : Autoriser une fois, Toujours autoriser ou Refuser.

• Autoriser une fois exécute exactement cet appel et redemande la fois suivante.
• Toujours autoriser exécute l’appel et enregistre une règle sur la tâche : pour l’outil entier dans le cas des actions sur les fichiers et sur l’ordinateur, limitée au programme de la commande (son premier mot) pour run_command — approuver npm run build pré-approuve les futures commandes npm, et non l’ensemble de l’interpréteur — et limitée au seul agent cible pour message_agent. Les règles figurent dans la section Vérification automatique de l’onglet Agent, où elles peuvent être supprimées.
• Refuser rejette l’appel. Le modèle apprend que l’utilisateur a refusé l’action et qu’il ne doit pas la retenter telle quelle ; l’exécution se poursuit avec cette réponse.

Une approbation en attente déclenche aussi une notification, dans l’application et par notification web si elle est activée, car l’exécution peut travailler sans surveillance depuis plusieurs minutes lorsqu’elle atteint ce point de contrôle. Si personne ne décide dans les cinq minutes, la demande expire, l’action n’est pas exécutée et l’exécution se termine en Intervention requise avec une transmission normale au lieu d’épuiser son budget.

Les approbations contrôlent les actions, pas la visibilité : write_file et les outils en lecture seule restent hors contrôle, et chaque décision est consignée dans le journal d’audit de sécurité.

Comprendre l’état d’une tâche

L’interface associe les états durables du backend à un ensemble plus réduit destiné aux utilisateurs :

État de l’interface	État du backend	Couleur de l’indicateur
Inactif	idle	rgb(255, 255, 255)
Réflexion	preparing ou running	rgb(48, 121, 255)
Terminé	completed	rgb(76, 212, 117)
Intervention requise	needs_input ou cancelled	rgb(255, 204, 0)
Erreur	failed	rgb(255, 61, 129)

Arrêter une exécution active la fait passer à Intervention requise et préserve ses fichiers. L’épuisement du budget de tours ou de sécurité des appels d’outils se termine également par Intervention requise après la transmission finale sans outils ; un travail incomplet n’est donc jamais marqué Terminé.

Une exécution active ne verrouille pas la conversation : un message envoyé pendant le travail de l’agent rejoint immédiatement la conversation et parvient au modèle au tour suivant. Vous pouvez donc l’orienter, le corriger ou ajouter du contexte sans arrêter l’exécution ; le bouton d’arrêt reste disponible à côté de l’envoi.

Redimensionner l’espace de travail

Au point de rupture xl sur ordinateur, Conversation et Espace de travail partagent une division réglable par glissement :

• La largeur par défaut de la conversation est de 45%.
• La plage conseillée va de 30% à 70%, sous réserve des largeurs minimales du contenu.
• Le rapport enregistré est propre à l’utilisateur connecté dans ce navigateur.
• Les touches fléchées déplacent le séparateur de 2% ; maintenez Maj pour 10%.
• Début et Fin sélectionnent les valeurs minimale et maximale disponibles.
• Entrée ou un double-clic réinitialise la division.

Les commandes suivent le sens d’écriture actif. En arabe, Conversation se trouve à droite, Espace de travail à gauche, et le redimensionnement au pointeur comme au clavier continue de suivre le sens visuel attendu.

Sur les écrans plus petits, utilisez la commande Conversation/Espace de travail dans l’en-tête de la tâche pour changer de surface.

Fichiers

L’onglet Fichiers parcourt les enfants directs de /workspace, ouvre uniquement les fichiers texte UTF-8 strictement valides et enregistre les modifications dans le volume de la tâche. Les séquences d’octets non valides sont rejetées au lieu d’être remplacées par des caractères de substitution avec perte.

L’éditeur propose :

• la coloration syntaxique en mode clair et sombre pour les langages courants du web, des systèmes, des scripts, des données et du balisage ;
• Cmd/Ctrl+S pour enregistrer ;
• Shift+Alt+F pour mettre en forme les fichiers pris en charge ;
• la détection optimiste des conflits d’enregistrement, afin qu’une ancienne vue de l’éditeur ne puisse pas écraser silencieusement un fichier modifié depuis son ouverture ;
• des brouillons non enregistrés, propres à la tâche et au chemin, dans le stockage de session du navigateur ; et
• des avertissements de navigation lorsqu’une modification non enregistrée est ouverte.

La coloration en direct est suspendue au-delà de 8,000 caractères ou 400 lignes afin de préserver la réactivité de l’éditeur. La mise en forme est disponible jusqu’à 100,000 caractères et 4,000 lignes pour JavaScript/JSX, TypeScript/TSX, les variantes JSON, CSS/SCSS/Less, HTML, Markdown/MDX et YAML.

Lorsque le modèle modifie un fichier ouvert, l’onglet Fichiers affiche une vue Modifications rouge et verte qui montre exactement ce qui a été ajouté et supprimé depuis le début du tour, en repliant les longues portions inchangées. Un bouton de la barre d’outils permet de basculer entre la différence et l’éditeur, et les compteurs +added −removed résument immédiatement le tour. La référence de comparaison est le dernier contenu vu par votre navigateur avant le tour ; les fichiers ouverts pour la première fois après le tour n’affichent donc aucune différence.

Les brouillons du navigateur constituent une commodité, pas une sauvegarde. Ils sont effacés après un enregistrement réussi ou la suppression de la tâche et disparaissent normalement à la fin de la session du navigateur.

Activité

L’onglet Activité affiche les appels d’outils, leurs résultats, les opérations sur les fichiers, les sorties de commandes et les erreurs. Les métadonnées des outils peuvent être développées dans la conversation. Les sorties des commandes et des outils sont affichées de gauche à droite, même lorsque l’interface environnante est de droite à gauche.

Pendant une exécution, Libre WebUI ouvre un flux d’événements envoyés par le serveur et authentifié, puis affiche la progression à mesure que le backend la reçoit. Le flux peut transporter :

• un snapshot initial et des changements run_state ultérieurs ;
• reasoning_delta lorsque le fournisseur sélectionné expose explicitement le raisonnement ;
• le texte assistant_delta ;
• l’activité tool_call et tool_result ;
• les mesures usage ;
• les notifications skill_loaded pour les consignes de worker fournies par le serveur ; et
• les événements finaux error ou done.

La disponibilité et la granularité du raisonnement dépendent du modèle et du fournisseur. Libre WebUI affiche uniquement le contenu de raisonnement renvoyé par l’API du fournisseur ; il ne peut pas retrouver une chaîne de pensée masquée et certains modèles ne fournissent aucun flux de raisonnement. Le texte de l’assistant et l’activité des outils continuent d’être diffusés lorsqu’ils sont pris en charge indépendamment du raisonnement.

La sortie est volontairement limitée. Un résultat tronqué ne prouve pas qu’une commande n’a produit aucune autre sortie ; demandez au modèle d’examiner un résultat plus restreint ou d’exécuter une commande plus ciblée.

Git

L’onglet Git fournit des opérations de gestion de versions locales pour le /workspace propre à la tâche :

• initialiser un dépôt avec une branche main ;
• examiner l’état porcelain, le nombre de commits d’avance et de retard, ainsi que jusqu’à 20 commits récents ;
• examiner une différence textuelle limitée pour un chemin modifié ;
• indexer jusqu’à 200 chemins explicitement sélectionnés à la fois ;
• valider les modifications indexées en utilisant le nom d’utilisateur et l’adresse e-mail de l’administrateur connecté, ou une adresse locale sans réponse de l’instance si le compte ne possède aucune adresse e-mail ;
• créer une branche locale après la première validation ; et
• basculer vers une branche locale existante lorsque l’arbre de travail est propre.

Cette surface est intentionnellement locale uniquement. Elle ne propose aucune commande de clonage, fetch, pull, push, gestion des dépôts distants, commande Git arbitraire, jeton, clé SSH ni pull request. Ces opérations exigent un courtier d’identifiants de confiance distinct, idéalement une GitHub App ou un jeton d’installation équivalent, limité à un dépôt et à une opération. Ne placez pas d’identifiants Git de longue durée dans /workspace, l’environnement du conteneur de la tâche ou la configuration du dépôt.

Les lectures Git peuvent s’exécuter lorsque la tâche est par ailleurs inactive ou active. Les écritures Git sont rejetées lorsqu’une exécution de modèle, un terminal interactif ou un aperçu possède le conteneur de la tâche. Le changement de branche exige en outre un arbre de travail propre. L’interface ne peut ainsi pas entrer en concurrence avec le modèle ou un processus de longue durée sur les mêmes fichiers.

Chaque commande Git de l’interface est un tableau d’arguments fixe, exécuté sous l’UID/GID 1000:1000 dans le conteneur de la tâche ; les entrées de l’utilisateur ne sont jamais évaluées par un shell. Pour cette surface, l’environnement d’exécution désactive la configuration Git système et globale, les invites, les hooks, les outils d’assistance d’identifiants, la signature des commits, la récursion des sous-modules, les pilotes de diff externes, textconv et les protocoles réseau. Il refuse les dépôts dont l’arbre de travail n’est pas exactement /workspace ou dont le répertoire Git ou commun est résolu hors de /workspace. Les actions d’écriture Git susceptibles de traiter le contenu des fichiers sont également bloquées lorsque la configuration du dépôt définit un filtre clean, smudge ou process exécutable.

Ces commandes protègent l’API Git de Libre WebUI. Un administrateur peut toujours utiliser le Terminal, et le modèle run_command, pour exécuter des commandes Git ordinaires dans le bac à sable. Le bac à sable et la frontière du déploiement restent donc les contrôles de sécurité pour les commandes arbitraires.

Compétences de worker intégrées

Chaque exécution reçoit un guide de l’espace de travail détenu par le serveur. Il décrit la frontière durable de /workspace, la racine en lecture seule du conteneur, l’état temporaire des processus et de /tmp, la politique réseau, les limites des commandes et des sorties ainsi que le cycle de vie de l’aperçu. Ses compétences intégrées demandent au modèle de :

• examiner les instructions du projet, les manifestes, les fichiers de verrouillage, les scripts et l’état actuel du dépôt avant toute modification ;
• préserver le travail sans rapport et regrouper les lectures ou recherches indépendantes ;
• poursuivre jusqu’à l’implémentation au lieu de s’arrêter après un plan ;
• exécuter des vérifications ciblées avant les contrôles plus larges ;
• diagnostiquer un échec au lieu de réessayer aveuglément ; et
• vérifier l’application avant de démarrer l’aperçu comme dernier processus de longue durée.

Le guide n’existe que dans le contexte du modèle. Libre WebUI ne crée aucun fichier AGENTS.md, répertoire de compétences ou autre fichier de contrôle dans l’espace de travail de l’utilisateur. Les instructions fournies par le projet restent des consignes propres au projet et ne peuvent pas remplacer la frontière de sécurité du conteneur ou des outils.

Terminal

L’onglet Terminal attache un shell interactif au même conteneur isolé que celui dans lequel travaille le modèle. Un administrateur peut ainsi examiner l’état, lancer manuellement un build ou déboguer ce qu’une exécution a laissé derrière elle sans quitter le navigateur.

Le shell s’exécute selon la même politique de conteneur que tous les outils du modèle : l’utilisateur non privilégié 1000:1000, le répertoire de travail /workspace, au sein du conteneur déjà renforcé et dépourvu de capacités. Un terminal n’accorde aucun privilège que l’outil run_command du modèle ne possède pas déjà : il constitue une interface humaine vers la même frontière, et non un moyen de la contourner.

Comportement opérationnel :

• Authentification — le navigateur échange son en-tête Authorization habituel via HTTP contre un ticket à courte durée de vie et à usage unique, lié au protocole du terminal Work et à la tâche exacte. Seuls ce ticket et l’identifiant de la tâche figurent dans l’URL de mise à niveau /ws/work-terminal. Avant chaque saisie dans le shell, Libre revérifie l’état actuel du compte, l’accès à Work, l’existence et la propriété de la tâche. Une révocation ferme immédiatement le shell et libère son bail d’exécution.
• Contrôles d’origine — lorsque CORS_ORIGIN ou BASE_URL est configuré, les mises à niveau des navigateurs doivent correspondre à l’une de ces origines. Configurez-en au moins une pour les déploiements distants. Les mises à niveau sans origine restent disponibles pour Electron et les clients autres que des navigateurs, mais exigent le même ticket lié à la tâche et les mêmes contrôles d’autorisation en direct ; utilisez TLS, un pare-feu et la politique du proxy inverse pour contrôler ces clients.
• Admission — un terminal ouvert acquiert un bail d’exécution comme une commande ou un aperçu et compte dans WORK_MAX_ACTIVE_RUNTIMES_*.
• Durée de vie du conteneur — un terminal attaché maintient le conteneur en cours d’exécution et empêche le mécanisme d’arrêt pour inactivité de le supprimer en pleine session.
• Simultanéité — WORK_TERMINAL_MAX_SESSIONS_PER_TASK (valeur par défaut : 2) limite le nombre de shells simultanés par tâche.
• Délai d’inactivité — WORK_TERMINAL_IDLE_TIMEOUT_MS (valeur par défaut : 15 minutes) ferme une session sans activité et libère son bail.
• Pendant une exécution — l’onglet explique que le modèle possède le conteneur et ouvre le shell une fois le tour terminé.

Le terminal communique directement avec l’API Docker Engine, car une session TTY exige un flux bidirectionnel détourné que la CLI Docker ne fournit qu’à un véritable terminal de contrôle. Il utilise WORK_DOCKER_SOCKET, ou à défaut DOCKER_HOST — un socket unix:// ou un point de terminaison tcp:// en HTTP simple, tel qu’un proxy de socket dont le transfert compatible avec HTTP transporte le flux détourné dans un tunnel Connection: Upgrade standard — ou enfin /var/run/docker.sock. Un DOCKER_HOST avec lequel ce client ne sait pas communiquer (ssh://, ou tcp:// avec DOCKER_TLS_VERIFY défini) signale que le terminal est indisponible et en donne la raison, au lieu de s’attacher silencieusement ailleurs ; le reste de Work continue de fonctionner. Sur le backend Kubernetes, la même session passe par la sous-ressource exec sous forme de WebSocket TTY via le serveur de l’API — trames de redimensionnement comprises — sans faire intervenir de point de terminaison Docker.

Les sessions du terminal sont interactives et ne sont pas enregistrées. Les commandes qui y sont saisies n’apparaissent pas dans la chronologie Activité de la tâche.

Aperçu

L’onglet Aperçu démarre, arrête, intègre et ouvre l’application web générée. Lorsque le champ de commande est vide, Libre WebUI examine l’espace de travail et :

• exécute un script dev du fichier package.json racine avec l’hôte et le port requis ;
• sert un fichier index.html racine avec un serveur statique intégré et sans dépendance ; ou
• applique les mêmes règles à une seule application située dans un répertoire imbriqué.

Les applications racines sont prioritaires. Si plusieurs applications imbriquées sont aussi probables les unes que les autres, ou si aucun point d’entrée pris en charge n’existe, Work renvoie une erreur exploitable au lieu de tenter une commande npm sans rapport. Pour les autres structures de projet ou serveurs, saisissez une commande personnalisée avant de sélectionner Démarrer l’aperçu. Les commandes personnalisées commencent dans /workspace ; incluez donc le répertoire relatif si nécessaire, par exemple cd apps/web && npm run dev -- --host 0.0.0.0 --port 4173. Un processus personnalisé doit écouter sur 0.0.0.0 et sur le WORK_PREVIEW_PORT configuré. Work attend jusqu’à 15 secondes que le port soit prêt.

Le modèle peut également démarrer l’aperçu avec son outil start_preview. C’est le seul moyen pris en charge pour qu’un modèle laisse un processus en cours d’exécution. Les appels run_command ordinaires nettoient les descendants en arrière-plan à la fin de la commande.

Écran (le Work Computer)

Regardez la démonstration complète : une exécution réelle et non retouchée (30x, puis en temps réel) d’un agent Work qui parcourt les galeries d’images de la NASA sur son propre écran, choisit des photos, puis construit et teste une galerie Three.js interactive, le tout à partir d’une seule invite.

Une tâche dont la politique active le Work Computer dispose d’un onglet Écran : une fenêtre en direct sur un bureau virtuel exécuté dans le même bac à sable, avec un gestionnaire de fenêtres, un dock et un navigateur Chromium sur un écran 1280×800. Vous pouvez regarder l’agent travailler, prendre le contrôle de la souris et du clavier, écouter le son de l’ordinateur et lui apprendre des tâches par démonstration. L’ouverture de l’onglet démarre la session graphique à la demande (rien ne s’exécute avant que quelqu’un ne la regarde) et attache un visualiseur VNC sur WebSocket.

Un administrateur l’active en un clic : la page d’accueil de Work affiche une fiche Work Computer avec un bouton Activer. Celui-ci construit l’image graphique intégrée sur le propre démon Docker du déploiement (la première construction prend quelques minutes) et crée une politique Work Computer prête à l’emploi ; aucune commande docker build ni aucun champ de politique ne doit être renseigné manuellement. Derrière un proxy filtré de l’API Docker, le point de terminaison de build est délibérément refusé. Récupérez plutôt l’image publiée sur l’hôte Docker (ghcr.io/libre-webui/libre-work-computer, étiquetée libre-work-computer:latest) ou construisez-la à cet endroit depuis deploy/work-computer/ ; Activer ignore alors la construction et se contente de créer la politique. Les tâches soumises à cette politique doivent disposer d’un accès réseau : l’écran est atteint par un port de conteneur publié sur l’interface de bouclage, exactement comme l’aperçu.

Modèle de sécurité : le serveur VNC du conteneur se lie à localhost derrière deux mots de passe propres à la session. Le premier, en lecture seule, est transmis à chaque observateur autorisé ; le second, offrant un contrôle complet, n’est remis qu’au détenteur actuel du bail de prise de contrôle. Le serveur VNC lui-même rend donc inactives les entrées de tous les autres utilisateurs. Le pont WebSocket est la seule surface accessible. Il est publié sur l’interface de bouclage de l’hôte Docker et jamais exposé directement. Chaque observateur s’authentifie avec un ticket à usage unique lié à sa session et à la tâche, selon le même mécanisme que le Terminal. L’accès actuel à Work est revérifié à chaque connexion ; la révocation de l’accès d’un utilisateur coupe donc immédiatement ses écrans. Jusqu’à quatre observateurs simultanés peuvent regarder un écran, et l’observation compte comme activité de la tâche pour le nettoyage après inactivité. Observer et exécuter ne s’opposent jamais : ouvrir l’écran pendant une exécution de l’agent s’attache au bac à sable de cette exécution, un écran observé ne bloque pas le démarrage du tour suivant et la session survit à la fin de l’exécution, y compris dans les déploiements en équipe où les exécutions ont lieu dans un processus worker distinct. Le profil du navigateur persiste dans /workspace/.browser-profile, afin que les connexions effectuées dans l’ordinateur survivent aux redémarrages du conteneur.

Contrôle par l’agent : une tâche dotée du Work Computer propose aussi deux outils supplémentaires au modèle. computer_observe renvoie une capture complète du bureau, ainsi que la position du curseur, l’identité de la fenêtre active, l’URL actuelle du navigateur, une indication précisant si la page — plutôt que l’interface propre au navigateur — détient le focus clavier, un descripteur compact de l’élément ciblé et un hachage de la capture. Les signaux sémantiques proviennent d’un point de terminaison DevTools lié à l’interface de bouclage du conteneur et sont simplement absents avec les images graphiques construites avant son introduction. computer_act exécute un lot pouvant contenir jusqu’à 24 actions de souris et de clavier (déplacement, clic, double-clic, clic droit, saisie, combinaisons de touches, défilement, attente), puis renvoie la capture une fois l’écran stabilisé. Trois protections d’exécution garantissent l’intégrité des lots : les actions type et key peuvent comporter une assertion focus et échouent de manière sûre lorsque le champ affirmé ne détient pas le focus clavier, afin que du texte ne soit pas silencieusement saisi dans l’omnibox ; un lot s’arrête prématurément si une fenêtre apparaît, si le titre change ou si le focus se déplace en cours de lot, puisque les coordonnées restantes visaient l’écran précédent ; enfin, un lot peut déclarer un résultat attendu (titre, URL ou région d’écran modifiée), que l’environnement vérifie avec un délai adaptatif — « pending » signifie que le résultat n’a pas encore été observé, jamais qu’il est présumé réussi. Après un lot, l’écran est stabilisé de façon adaptative, par interrogations successives jusqu’à ce qu’il cesse de changer, et non après un délai fixe. Chaque résultat comporte également des preuves que le modèle est invité à lire : les clics à des coordonnées explicites renvoient un reçu indiquant si les pixels proches ont changé, scroll_until fait défiler vers un texte cible ou le bord de la page et indique s’il est devenu visible, et chaque observation est comparée à la précédente afin qu’un écran inchangé soit explicitement signalé. Les lots peuvent déclarer un subgoal d’une ligne, conservé avec le résultat comme point de contrôle et répété dans les invites de reprise. La boucle de l’agent détecte les blocages d’ancrage (trois actions identiques sur un écran inchangé déclenchent une notification de reprise ; une répétition supplémentaire met fin à l’exécution en demandant une intervention au lieu d’épuiser les tours restants) et l’ambiguïté cumulative (des attentes consécutives non vérifiées déclenchent une notification de nouvel ancrage). La télémétrie de la boucle — tours, latence des outils, captures, protections, verdicts sur les attentes — est apposée sur chaque enregistrement d’outil conservé et résumée à la fin de l’exécution. Les captures parviennent au modèle comme de véritables images sur chaque route de fournisseur — Ollama, Anthropic, Gemini, ainsi que les plugins de chat et Responses compatibles avec OpenAI. Le modèle qui pilote la tâche doit donc être un modèle de vision. Si le fournisseur refuse les images — par exemple avec un modèle uniquement textuel — l’exécution n’échoue pas : les captures sont retirées pour le reste de l’exécution, le modèle reçoit l’instruction de s’appuyer sur les observations textuelles et une note dans la transcription explique la dégradation. Un modèle qui ne voit pas l’écran vérifie cependant beaucoup moins de choses ; privilégiez donc un modèle de vision pour les tâches informatiques. Seules les captures les plus récentes restent dans le contexte actif du modèle, et les transcriptions persistantes de la tâche ne conservent que l’observation textuelle, jamais les octets des images. Le navigateur intègre aussi un blocage de contenu : uBlock Origin Lite pour les publicités et les traqueurs (version épinglée et somme de contrôle vérifiée lors de la construction de l’image, avec le mode de filtrage imposé par une politique gérée), ainsi qu’un mécanisme qui ferme automatiquement les bannières de consentement aux cookies. Les publicités et les murs de consentement gaspillent les captures, les jetons et les clics de l’agent. Les requêtes publicitaires sont neutralisées à la manière d’uBlock : les scripts publicitaires connus sont résolus vers des stubs locaux inoffensifs afin que les pages continuent de fonctionner. L’agent reçoit l’instruction de ne jamais saisir d’identifiants ni résoudre de CAPTCHA ou de défis 2FA ; il signale plutôt le blocage. Pour les tâches non fiables, associez une politique graphique à un résolveur DNS filtrant : un navigateur de bureau rend la politique de sortie réseau plus importante, pas moins.

Audio : l’écran est muet par défaut (règle du navigateur : le son exige un clic) ; le bouton de haut-parleur du volet Écran diffuse en direct le son de l’ordinateur. Dans le bac à sable, PulseAudio joue dans un récepteur nul dont le moniteur est capturé sous forme PCM brute, puis servi sur un second pont WebSocket authentifié et publié sur l’interface de bouclage. Il utilise le même ticket, la même revérification d’accès et la même limite d’observateurs par tâche que l’écran. Cette fonction exige une image graphique construite depuis deploy/work-computer/ avec cette version ou une version ultérieure.

Prise de contrôle : le bouton Prendre le contrôle du volet Écran vous donne la souris et le clavier, afin de vous connecter, de résoudre un CAPTCHA ou d’effectuer toute étape interdite à l’agent ; J’ai terminé rend l’écran à l’agent. Une seule session VNC assure les deux rôles : le serveur du conteneur détient un mot de passe de contrôle complet et un mot de passe en lecture seule (générés pour chaque session, jamais journalisés). Les observateurs ne reçoivent que le mot de passe de lecture, tandis que le mot de passe de contrôle est remis exclusivement au détenteur actuel d’un bail de contrôle. Le bail est limité par une durée de vie (une prise de contrôle abandonnée expire dans les deux minutes), renouvelé tant que l’interface de prise de contrôle est ouverte et coopératif : il ne peut pas être pris de force à un autre utilisateur. Une politique peut désactiver entièrement la prise de contrôle (Autoriser la prise de contrôle de l’écran dans l’éditeur de politiques). Ses tâches masquent alors les commandes Prendre le contrôle et Enseigner, le point de terminaison de prise de contrôle refuse l’opération et la commande request_takeover de l’agent indique que personne ne peut recevoir le contrôle ; l’observation reste disponible. Pendant qu’une personne détient le contrôle, computer_observe et computer_act sont tous deux bloqués. L’agent ne peut donc ni lutter contre vos entrées ni capturer ce que vous saisissez. L’agent peut également demander votre intervention : son outil request_takeover publie une bannière dans le volet Écran avec le motif et attend que vous preniez le contrôle puis le rendiez. Les identifiants saisis pendant une prise de contrôle vont directement de votre clavier à la page ; ils ne passent jamais par le modèle ni par la transcription de la tâche. La prise de contrôle exige une image graphique construite depuis deploy/work-computer/ avec cette version ou une version ultérieure ; les sessions provenant d’images antérieures restent observables, mais en lecture seule pour tous.

Mode d’apprentissage : Enseigner une tâche dans le volet Écran enregistre une démonstration. Vous pilotez l’écran réel — la commande prend le contrôle exactement comme ci-dessus, avec un indicateur d’enregistrement visible — tandis que les actions du pointeur, du clavier et de défilement sont enregistrées selon leurs coordonnées à l’écran. Chaque clic est également ancré : une sonde en lecture seule résout l’élément interactif sous le pointeur (sa balise, son identifiant et son libellé visible) ainsi que l’URL actuelle de la page. Les étapes du guide nomment ainsi leurs cibles — « Click "button#submit (Place order)" » — et relèguent les coordonnées à l’emplacement occupé par la commande pendant la démonstration. L’enregistrement construit un guide de façon déterministe, sans aucun modèle dans la boucle : les frappes sont regroupées en chaînes saisies, un seuil de 8 pixels distingue le clic du glissement, les pauses deviennent des étapes d’attente explicites et le texte saisi qui mentionne du vocabulaire secret ou ressemble à un identifiant (8+ caractères mêlant trois classes de caractères) est caviardé et remplacé par une instruction d’utiliser request_takeover à cette étape. Le guide est une procédure en langage naturel — cibles ancrées en premier, coordonnées comme indications, réinterprétées avec computer_observe — qui comprend les conditions d’utilisation, les entrées, les étapes, la vérification, une portée autorisée dérivée des hôtes réellement visités pendant la démonstration (la relecture doit s’arrêter et demander avant de les quitter : une procédure enseignée n’hérite jamais d’une autorité supérieure à ce qui a été montré), les frontières d’approbation et un traitement des échecs fondé sur l’arrêt et la demande. Il est enregistré comme une compétence ordinaire (préfixe de slug taught-) et apparaît donc sur la page Compétences avec la gestion des versions, la modification et le partage. Les exécutions Work compatibles avec l’ordinateur chargent les compétences enseignées et activées de leur propriétaire dans leur invite système, puis les signalent dans la liste des compétences de l’exécution. Rejouer une tâche enseignée consiste donc en une exécution normale dont la demande correspond à la procédure. Après une exécution terminée, les pastilles de compétence permettent d’indiquer en un clic si elle a fonctionné ou échoué ; cet avis ajoute une ligne datée dans la section Historique de la compétence (la plus récente en premier, nombre limité, chaque ligne constituant une version ordinaire de la compétence). L’historique de la procédure reste ainsi attaché à celle-ci. Ne saisissez pas de véritables mots de passe pendant l’enregistrement : faites la démonstration jusqu’à la connexion, enregistrez-la, puis laissez request_takeover gérer les identifiants lors de la relecture.

Fournisseurs, routage et divulgation des données

Routes de fournisseurs prises en charge

Route	Validation et comportement
Ollama local	Ollama doit être sain et le modèle exact doit annoncer la prise en charge des outils.
Ollama Cloud	Acheminé explicitement via Ollama ; les modèles suffixés cloud affichent l’information sur le fournisseur distant.
Plugin de complétion/chat	Le plugin doit être actif, répertorier le modèle exact et disposer d’un identifiant pour l’administrateur actuel.
Plugin Anthropic	Utilise l’adaptateur de messages et d’outils Anthropic de Work.
Plugin Gemini	Utilise l’adaptateur de contenus et d’appels de fonctions Gemini de Work.
Autres plugins compatibles	Utilisent la forme de requête de style OpenAI pour les messages, outils et choix d’outils.

Le type de fournisseur et l’identifiant du plugin sont stockés à la fois sur la tâche et sur chaque exécution. Le nom d’un modèle ne choisit jamais la route à lui seul. Activer un plugin dont le nom de modèle est identique à celui d’un modèle Ollama ne permet pas d’intercepter une tâche existante.

Données reçues par un fournisseur

À chaque tour du modèle, le fournisseur sélectionné peut recevoir :

• l’invite système Work ;
• les compétences de worker intégrées et les limites d’exécution actuelles ;
• jusqu’aux 30 derniers messages utilisateur ou assistant de la conversation, dans une limite de 256 KB ;
• les définitions des outils Work ;
• l’historique des appels d’outils de l’assistant ; et
• les résultats des outils, qui peuvent inclure des listes de répertoires, le contenu de fichiers demandé, des résultats de recherche, des sorties de commandes et des erreurs.

Le volume nommé n’est pas téléversé dans son ensemble. Toutefois, tout contenu de fichier ou sortie de commande renvoyé par un outil rejoint la conversation du modèle et est envoyé au fournisseur sélectionné. Examinez les politiques de conservation, d’entraînement, de tarification et d’utilisation des fournisseurs distants avant d’utiliser du code source sensible.

Les identifiants des fournisseurs restent sur le backend Libre WebUI, qu’ils soient configurés à l’échelle du déploiement ou pour un utilisateur. Ils servent aux requêtes adressées aux modèles depuis le backend et ne sont jamais montés dans le conteneur Work.

Le chiffrement des identifiants au niveau de l’application ne chiffre pas la tâche entière. Les conversations Work, les résultats des outils, les sorties de commandes et les métadonnées des tâches sont du contenu ordinaire de la base de données, tandis que les fichiers et dépendances de l’espace de travail sont des fichiers ordinaires dans le volume Docker ou le PVC Kubernetes de la tâche. Utilisez les contrôles d’accès de l’hôte et le chiffrement du disque lorsque le modèle de menace du déploiement exige un chiffrement au repos.

Information sur les fournisseurs distants

À des fins d’information, Work considère comme distants les modèles de plugins et les noms Ollama se terminant par :cloud ou -cloud. Leur sélection ouvre une notification masquable qui explique le flux des données vers le fournisseur et la possibilité de plusieurs appels facturables. La préférence de masquage est mémorisée pour chaque utilisateur Libre WebUI.

Toutes les routes de fournisseurs utilisent le même budget WORK_MAX_AGENT_ROUNDS, soit 48 tours par défaut. Il n’existe pas de limite distincte de 12 tours pour les plugins. Le budget de sécurité des appels d’outils est la plus grande valeur entre 128 appels et huit appels par tour configuré. Lorsque le budget de tours est épuisé, Libre WebUI demande au modèle une transmission finale sans outil qui décrit le travail terminé, les contrôles, les obstacles et les étapes restantes. Il enregistre alors l’exécution finale sous Intervention requise au lieu d’exposer une exception brute de limite de tours ou de marquer un travail incomplet comme terminé. Une exécution ultérieure reprend dans le même espace de travail durable. Une seule exécution Work peut néanmoins effectuer de nombreux appels facturables au fournisseur.

Espaces de travail liés à un dossier de l’hôte (facultatif)

Avec le backend Docker, le /workspace d’une tâche est normalement un volume nommé qui n’existe que pour elle ; le modèle ne peut donc pas atteindre vos véritables fichiers. Un déploiement Docker peut aussi autoriser la liaison d’une tâche à un dossier réel de l’hôte. Kubernetes refuse les espaces liés à l’hôte et utilise un PVC appartenant à la tâche.

Définissez les deux variables, puis redémarrez le backend :

WORK_HOST_WORKSPACES_ENABLED=true
WORK_HOST_WORKSPACE_ROOTS=/Users/you/Projects

WORK_HOST_WORKSPACE_ROOTS est une liste de racines séparées par : ; sa valeur par défaut est le répertoire personnel de l’utilisateur du serveur. Lorsque la fonction est activée, l’écran d’accueil de Work affiche un champ facultatif Dossier de l’espace de travail. Laissez-le vide pour conserver le fonctionnement antérieur, avec un volume isolé propre à la tâche.

Avant d’être accepté, un chemin doit être absolu, exister, désigner un répertoire et être résolu — à travers tout lien symbolique — vers un emplacement situé sous l’une des racines configurées. Les répertoires nommés .ssh, .gnupg, .aws, .config, .kube, .docker, .claude, .libre-webui ou node_modules sont refusés sans condition. Le chemin résolu est stocké avec la tâche et affiché dans son en-tête ; le dossier sur lequel agit une tâche reste ainsi toujours visible.

Cela réduit l’isolation du bac à sable

Un espace de travail sur l’hôte signifie que le modèle lit et écrit vos véritables fichiers. Les autres protections du conteneur — utilisateur sans root, capacités supprimées, limites de ressources — ne le séparent plus de ce répertoire. Laissez la fonction désactivée si vous n’en avez pas besoin, définissez les racines les plus étroites possible et privilégiez des répertoires suivis par un gestionnaire de versions.

Persistance et cycle de vie de l’environnement d’exécution

Libre WebUI sépare l’état durable de l’état d’exécution :

État	Stockage	Durée de vie
Propriété, titre, fournisseur et état de la tâche	Base de données Libre WebUI	Jusqu’à la suppression de la tâche ou de son propriétaire
Exécutions, erreurs, messages et activité des outils	Base de données Libre WebUI	Jusqu’à la suppression de la tâche
Fichiers de l’espace de travail	Volume Docker ou PVC K8s propre à la tâche	Survivent à l’annulation d’une exécution, à l’arrêt de l’aperçu et aux redémarrages du bac à sable et de l’application
Système de fichiers racine et fichiers temporaires	Conteneur ou Pod propre à la tâche	Jetables ; peuvent être arrêtés ou recréés
Processus d’aperçu	Bac à sable actif de la tâche	Éphémère ; conservé uniquement tant que son bon fonctionnement est vérifié
Brouillon non enregistré dans l’éditeur	Stockage de session du navigateur	État temporaire pratique pour la session du navigateur

Chaque tâche reçoit un UUID généré par le serveur. Les noms de son bac à sable et de son espace de travail sont dérivés dans le backend et ne sont jamais acceptés depuis une requête du navigateur. Libre WebUI crée les ressources d’exécution avec des étiquettes de gestion et de propriété de la tâche. Avant toute réutilisation ou suppression, il vérifie l’étiquette de propriété et refuse une ressource dont l’étiquette appartient à une autre tâche.

Les bacs à sable sont préparés à la demande. Les opérations d’assistance sur les fichiers arrêtent un bac à sable qui serait autrement inactif ; les commandes l’arrêtent à la fin de leur exécution ; un aperçu dont le bon fonctionnement est vérifié peut le maintenir actif afin que l’utilisateur examine l’application. Le même espace de travail durable est remonté lorsque le bac à sable de la tâche est redémarré ou recréé.

Les administrateurs peuvent définir des politiques d’exécution nommées depuis l’onglet Gestion des utilisateurs des Paramètres : des préréglages qui combinent une image d’exécution, des limites de mémoire, CPU et PID, une taille d’espace de travail (Kubernetes), un délai d’inactivité, une valeur réseau par défaut et deux boutons de capacité. Le premier, Work Computer (interface graphique + navigateur), donne aux tâches de la politique un bureau virtuel et l’onglet Écran. Le second, Autoriser la prise de contrôle de l’écran, détermine si une personne peut prendre le contrôle de ces écrans et, puisque l’apprentissage s’enregistre pendant une prise de contrôle, si ce mode est disponible. Une tâche créée sous une politique utilise cette configuration. Chaque champ laissé vide hérite des valeurs globales du déploiement, et la suppression d’une politique rétablit ces valeurs pour ses tâches lors de la prochaine recréation de leur conteneur. Les politiques modifient uniquement les ressources et ces deux boutons de capacité. Le profil de renforcement (sans root, racine en lecture seule, capacités supprimées, isolation réseau) ne fait pas partie des champs d’une politique et ne peut pas être affaibli pour une politique donnée.

WORK_RUNTIME_IDLE_TIMEOUT_MS limite la durée de grâce de l’aperçu : lorsqu’elle est définie, une tâche de nettoyage arrête tout bac à sable sans activité — aucune commande terminée, aucun terminal attaché, aucune requête d’aperçu via le proxy signé — pendant ce nombre de millisecondes, libérant ainsi son emplacement d’admission. L’arrêt est peu coûteux et l’espace de travail persiste ; un aperçu mis en veille redémarre donc simplement à la prochaine utilisation. La valeur par défaut (0) conserve le comportement actuel : l’aperçu fonctionne jusqu’à son arrêt explicite.

Au démarrage du backend, les exécutions actives sont marquées comme ayant échoué et l’état des aperçus est effacé : la boucle de l’agent et le proxy d’aperçu ont disparu avec le processus et ne peuvent pas reprendre. Le pilote sélectionné répertorie ensuite ses conteneurs ou Pods gérés en une seule requête par étiquette. Les bacs à sable en cours d’exécution et appartenant à des tâches connues sont arrêtés, car une commande interrompue pourrait encore s’exécuter sans superviseur ; ceux qui étaient déjà au repos restent inchangés ; les bacs à sable gérés dont la ligne de tâche n’existe plus sont supprimés. La propriété provient de l’étiquette de tâche, jamais du nom de la ressource. La suppression des orphelins suppose qu’une seule instance Libre WebUI possède un espace de noms d’exécution ou un démon Docker. Ne dirigez pas deux instances vers les mêmes ressources Work. Si le pilote ne peut pas prouver que le nettoyage est terminé, Work reste fermé de manière sûre, réessaie toutes les 10 secondes et bloque les nouvelles opérations modifiables jusqu’au rétablissement de l’accès à l’environnement d’exécution.

Comportement du réseau

Vérifiez la politique réseau sélectionnée

Les tâches dépourvues de politique d’exécution nommée commencent avec le réseau activé. Un administrateur peut définir une politique nommée dont la valeur réseau par défaut est désactivée, et le créateur peut sélectionner cette politique à la création d’une tâche. Il n’existe aucun bouton réseau indépendant propre à une tâche, et modifier la politique exige ensuite de recréer le bac à sable pour que la nouvelle configuration prenne effet.

Sur le backend Docker, les tâches en réseau sont rattachées à un réseau bridge géré et dédié (libre-webui-work par défaut, WORK_NETWORK_NAME), créé avec la communication interconteneurs désactivée (com.docker.network.bridge.enable_icc=false). Il en découle deux conséquences :

• un bac à sable Work ne peut pas ouvrir de connexion vers un autre bac à sable Work ; et
• un bac à sable Work ne peut pas atteindre les propres conteneurs du déploiement sur le bridge partagé par défaut de Docker, notamment une base de données ou un conteneur Ollama colocalisé qui n’est pas délibérément publié.

Libre WebUI refuse de démarrer une tâche en réseau si un réseau portant le nom configuré existe déjà, mais n’est pas le réseau géré, plutôt que d’y rattacher silencieusement les bacs à sable.

Sur Kubernetes, le Pod du bac à sable porte la même étiquette d’activation du réseau. Le chart Helm installe une NetworkPolicy de refus par défaut, une entrée réservée à l’aperçu et une sortie vers internet uniquement pour les Pods dont le réseau est activé, en excluant les plages configurées dans work.networkPolicy.blockedEgressCidrs. Une NetworkPolicy n’est effective que si le CNI du cluster l’applique ; consultez le guide Kubernetes.

La sortie vers le monde extérieur reste autorisée, car les téléchargements de paquets, les opérations Git distantes et les API externes rendent Work utile. Il ne s’agit pas d’un pare-feu sortant. Du code généré peut encore être en mesure d’atteindre :

• des services sur l’hôte Docker ;
• des systèmes du réseau local de l’hôte ;
• des services internet ; et
• des points de terminaison de métadonnées d’infrastructure, selon le déploiement.

Points d’intégration d’une politique de sortie

Pour établir une frontière plus stricte, combinez les éléments suivants :

• WORK_RUNTIME_DNS (Docker) — adresses de résolveurs IPv4 ou IPv6 séparées par des virgules et imposées à chaque bac à sable en réseau (--dns). Le diriger vers un résolveur filtrant fournit des listes d’autorisation et de refus fondées sur les noms sans modifier Libre WebUI. Les entrées qui ne sont pas des adresses sont rejetées et journalisées ; la valeur ne peut donc jamais injecter d’options Docker supplémentaires.
• Des règles de pare-feu de l’hôte ou en amont (Docker) sur le sous-réseau du bridge géré, stable puisque le réseau est nommé et géré.
• WORK_NETWORK_NAME (Docker) dirigé vers un réseau que vous créez au préalable avec vos propres options de pilote. Libre WebUI vérifie qu’il porte l’étiquette gérée et l’option de désactivation ICC ; créez-le donc avec les deux.

Le filtrage DNS limite la résolution des noms, et non la sortie vers des adresses IP brutes. Un déploiement qui doit garantir l’absence de sortie directe par IP nécessite également des règles de pare-feu au niveau de l’hôte, du cluster ou de l’amont.

Ne supposez pas que placer du code dans Work l’empêche de transmettre des données. N’accordez l’accès à Work qu’à des utilisateurs de confiance. Utilisez une politique d’exécution nommée avec réseau désactivé lorsqu’une tâche doit démarrer hors ligne ; aucune variable d’environnement à l’échelle du déploiement ne change la politique par défaut.

L’accès réseau n’ajoute aucun identifiant. Libre WebUI ne monte pas de clés SSH, d’identifiants cloud, de profils de navigateur, de répertoire personnel de l’hôte ni de socket Docker dans les conteneurs des tâches. Le code peut néanmoins transmettre tout identifiant ou secret qu’un utilisateur ou modèle écrit dans /workspace.

Ce trafic du bac à sable est distinct du trafic du modèle. Les requêtes Ollama et des plugins sont toujours envoyées par le backend Libre WebUI à la route de fournisseur explicitement sélectionnée.

Frontière de sécurité du bac à sable

Un conteneur Docker Work :

• s’exécute sans root sous l’UID/GID 1000:1000 ;
• utilise /workspace comme répertoire de travail ;
• monte uniquement le volume nommé de la tâche sélectionnée sous /workspace ;
• utilise un système de fichiers racine en lecture seule et un système temporaire /tmp de taille limitée ;
• supprime toutes les capacités Linux ;
• active no-new-privileges ;
• n’est pas privilégié et utilise un processus init ;
• applique des limites de CPU, mémoire, processus, durée des commandes et taille des sorties ;
• fixe le swap à la limite de mémoire (--memory-swap est égal à --memory), afin que cette limite ne puisse pas être contournée par le swap ;
• se rattache au réseau géré des bacs à sable avec la communication interconteneurs désactivée, ou ne dispose d’aucun réseau ; et
• ne publie que le port d’aperçu configuré vers un port d’hôte attribué par Docker sur l’interface de bouclage.

Chacun de ces éléments est revérifié avec docker inspect avant toute réutilisation d’un conteneur, et l’ensemble est haché dans l’étiquette de conteneur ai.libre-webui.policy. Un conteneur dont la politique est antérieure à une mise à niveau de Libre WebUI est détruit et recréé plutôt que réutilisé ; les modifications de renforcement s’appliquent donc automatiquement aux tâches existantes.

Le pilote Kubernetes applique un contexte de sécurité équivalent au Pod : UID/GID sans root, système de fichiers racine en lecture seule, seccomp RuntimeDefault, aucune élévation de privilèges, toutes les capacités supprimées, stockage éphémère limité, limites de ressources, aucun jeton ServiceAccount et PVC appartenant à la tâche sous /workspace. Il vérifie les étiquettes de tâche et l’empreinte de la politique avant de réutiliser ou supprimer un Pod ou un PVC.

La validation des chemins rejette les chemins absolus, les segments de traversée, les barres obliques inverses, les caractères NUL et les chemins trop longs. Les outils d’assistance des fichiers résolvent les chemins réels et refusent les sorties par lien symbolique. Les écritures utilisent un fichier temporaire et un renommage atomique.

Ces protections réduisent l’exposition accidentelle de l’hôte ; elles ne font pas de Work une machine virtuelle ni un environnement sûr pour l’analyse de logiciels malveillants. Les conteneurs partagent le noyau de l’hôte d’exécution. Une vulnérabilité de Docker, Kubernetes, de l’environnement d’exécution, de l’image, d’une dépendance ou du noyau peut franchir la frontière prévue.

Les volumes nommés Docker n’ont pas de quota disque indépendant. Un projet généré ou l’installation de paquets peut épuiser le stockage Docker : surveillez la croissance des volumes et appliquez des limites de stockage au niveau de l’hôte. Kubernetes demande une taille de PVC ; l’application effective du quota dépend du provisionneur de stockage sélectionné.

Liste de contrôle du renforcement de Docker en production

Cette liste concerne spécifiquement le backend Docker. Les opérateurs Kubernetes doivent également valider le RBAC du chart limité à l’espace de noms, le contexte de sécurité des Pods, la classe de stockage et l’application des NetworkPolicies par le CNI, conformément au guide Kubernetes.

L’application peut définir des options de conteneur, valider les chemins des espaces de travail et protéger sa propre API. Elle ne peut pas imposer la politique de pare-feu de l’hôte, les quotas du pilote de stockage ni le niveau de privilèges du démon Docker qui lui est fourni. Considérez ces éléments comme un travail explicite de déploiement pour une instance cliente privée.

1. Isoler le contrôle de Docker

Le conteneur Libre WebUI principal doit contrôler le démon afin de créer et d’inspecter les conteneurs Work. Un socket Docker monté constitue donc un identifiant du plan de contrôle, et non un montage de données ordinaire : compromettre l’application web peut alors entraîner la compromission de l’hôte Docker.

La première mesure d’atténuation est fournie dans ce dépôt : docker-compose.socket-proxy.yml tient entièrement le socket hors du conteneur Libre WebUI. Un proxy de socket conserve /var/run/docker.sock sur un réseau interne et ne transmet que les sections de l’API utilisées par Work — conteneurs, images, volumes, réseaux, exec et informations — tandis que les points de terminaison swarm, secrets, configs, build, commit et système sont refusés avant d’atteindre le démon. Libre WebUI est dirigé vers ce proxy avec DOCKER_HOST=tcp://docker-socket-proxy:2375 et n’a besoin ni d’un montage du socket ni d’une appartenance à son groupe ; la CLI, le terminal interactif et les diagnostics Docker utilisent tous ce point de terminaison. Le proxy réduit la surface de l’API, mais pas l’impact potentiel des points qu’il transmet : quiconque peut créer des conteneurs peut encore monter des chemins de l’hôte. La frontière ci-dessous reste donc essentielle.

Pour une frontière de production plus robuste, exécutez Libre WebUI et son démon Work sur une machine virtuelle dédiée, sans autre charge de travail. Pour aller plus loin, attribuez à Work un démon Docker sans root dédié ou un hôte d’exécution distinct, et n’exposez que ce démon à Libre WebUI. Vérifiez avec ce démon la propriété des fichiers, le routage des aperçus, le nettoyage et la prise en charge du terminal avant le déploiement. Monter simplement en lecture seule le même socket d’hôte avec root ne rend pas l’API Docker accessible en lecture seule.

2. Bloquer l’accès des bacs à sable aux services de gestion de l’hôte

Désactiver la communication interconteneurs empêche les bacs à sable Work de se joindre entre eux, mais pas d’atteindre les services liés sur l’hôte Docker. Examinez le bridge géré et son sous-réseau réels au lieu de présumer une adresse :

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

Utilisez le gestionnaire de pare-feu persistant de l’hôte pour rejeter le trafic provenant de ce bridge et destiné aux services de gestion de l’hôte, notamment SSH, l’API Docker, les bases de données et les ports de surveillance ou d’administration. Testez la règle depuis un conteneur jetable attaché à libre-webui-work, testez les téléchargements de paquets autorisés, puis rendez la règle persistante. La chaîne DOCKER-USER de Docker contrôle le trafic transféré ; le trafic dont la destination est l’hôte Docker lui-même peut aussi nécessiter une règle INPUT ou un hook d’entrée sur l’interface du bridge.

3. Limiter les destinations sortantes

Bloquez les points de terminaison de métadonnées cloud, les plages d’infrastructure privées et les plages du réseau local du client depuis le sous-réseau Work, sauf si un projet en a explicitement besoin. Combinez un résolveur filtrant via WORK_RUNTIME_DNS avec des règles de pare-feu de l’hôte ou en amont. Une adresse IP littérale contourne le filtrage DNS. Un proxy HTTP seul est également insuffisant tant que des commandes arbitraires peuvent ouvrir des connexions réseau directes ; appliquez la politique de routage hors du conteneur.

Conservez des politiques d’exécution nommées distinctes lorsque les clients ont besoin de comportements différents, par exemple un environnement hors ligne ou sans réseau, un environnement limité aux registres de paquets et un environnement à sortie ouverte. La politique nommée détermine si Libre attache le réseau au bac à sable ; les règles externes de pare-feu et de proxy continuent d’appliquer les restrictions par destination pour une politique avec réseau.

4. Appliquer de véritables quotas de stockage

Les limites de CPU, mémoire, swap et PID ne limitent pas le volume nommé. Avant de servir plusieurs clients, choisissez un backend de stockage qui applique des quotas par espace de travail, par exemple les quotas de projet XFS, des volumes logiques soumis à quota ou un pilote de volume ou PVC avec limite de taille. Le pilote Docker local par défaut sur un système de fichiers ext4 ordinaire n’obtient pas un quota fiable par volume simplement parce qu’une taille est documentée.

Surveillez chaque volume ai.libre-webui.managed=true ainsi que la racine de données Docker, déclenchez une alerte avant que le système de fichiers soit plein et testez le mode d’échec. Un compteur dans l’interface ou un contrôle du périodique peut avertir, mais ne constitue pas une frontière d’application : un conteneur peut consommer l’espace disque restant entre deux contrôles.

5. Vérifier la politique déployée

Après chaque modification de l’image ou de la politique du démon, créez une tâche Work jetable et vérifiez l’état effectif avec docker inspect : UID sans root, racine en lecture seule, toutes les capacités supprimées, no-new-privileges, limites de mémoire, swap, CPU et PID, seul volume de la tâche monté et réseau prévu. Vérifiez également que le conteneur Libre WebUI principal ne possède que les montages voulus et que l’entrée publique atteint l’application via le proxy inverse ou le tunnel authentifié, et non par un port Docker ou d’aperçu publié par erreur.

Sécurité et accessibilité des aperçus

Pour une tâche Docker, le pilote publie le port d’aperçu configuré vers un port attribué dynamiquement sur l’interface de bouclage du backend. Pour Kubernetes, le backend dans le cluster cible directement l’adresse IP du Pod du bac à sable. Ni le modèle ni le navigateur ne peut choisir arbitrairement l’amont. Libre WebUI signe une URL de capacité pour la tâche et le point de terminaison exacts, vérifie à chaque requête que l’aperçu fonctionne toujours et transmet le trafic HTTP et WebSocket via /api/work/previews. Arrêter ou redémarrer l’aperçu révoque l’ancienne URL.

Les réponses de l’aperçu retirent les identifiants Libre WebUI et les cookies de l’amont. Le HTML est limité à la fois par un bac à sable iframe et par une CSP de réponse qui autorisent les scripts, formulaires, fenêtres modales et téléchargements sans accorder l’accès à la même origine. La CSP protège aussi un aperçu ouvert dans un onglet distinct. Le code généré de l’application reste non fiable et peut utiliser la sortie réseau pour transmettre tout ce qu’il lit dans son propre espace de travail ou dans les entrées du navigateur. Considérez une URL d’aperçu active comme un secret à courte durée de vie et ne la partagez pas.

Comme le navigateur charge le proxy depuis l’origine publique de Libre WebUI, les navigateurs distants et les proxys inverses HTTPS fonctionnent sans exposer les ports Docker ni les adresses IP des Pods et sans déclencher de blocage du contenu mixte. Les proxys inverses doivent préserver les mises à niveau WebSocket pour /api/work/previews/ ; la configuration Nginx fournie le fait.

L’application principale n’autorise comme sources de frames que sa propre origine et Cloudflare Turnstile. Les réponses d’aperçu contournent la politique Helmet principale afin de pouvoir diffuser les corps de requête et appliquer la politique de bac à sable plus étroite décrite ci-dessus. La politique d’intégration interorigine reste désactivée, car les serveurs de développement générés n’émettent généralement pas d’en-têtes de ressources compatibles.

Matrice de déploiement

La disponibilité de Work dépend de la machine et du processus qui exécutent le backend Libre WebUI, et pas seulement du navigateur ou de l’interface de bureau.

Déploiement	Exécutions et fichiers Work	Aperçu intégré
npx libre-webui sur un ordinateur local	Pris en charge lorsque Docker est installé, actif et appelable par l’utilisateur du backend.	Pris en charge via le proxy signé sur l’origine de l’application.
Développement depuis le code source sur un ordinateur local	Pris en charge avec les mêmes exigences relatives à Docker et au fournisseur.	Pris en charge via l’origine de l’API de développement sur le port 3001.
Client de bureau Electron	Conditionnel. Electron utilise un backend Libre WebUI externe et ne fournit aucun environnement Work distinct.	Pris en charge via l’URL du proxy signé de ce backend.
Backend bare metal ou VM sur un hôte distant	Les exécutions, fichiers et appels aux fournisseurs fonctionnent lorsque Docker est disponible sur cet hôte.	Pris en charge lorsque le proxy inverse public préserve le trafic HTTP et WebSocket.
Docker Compose standard du dépôt	Pris en charge par défaut sur Docker Desktop : l’image contient la CLI Docker, Compose monte le socket Docker de l’hôte et les ports Work transitent par host.docker.internal. Docker Engine natif exige en plus un WORK_PREVIEW_BIND non public et joignable.	Pris en charge sur la même origine publique que Libre WebUI.
Déploiement Kubernetes/Helm actuel	Pris en charge avec --set work.enabled=true : les bacs à sable s’exécutent comme des Pods avec des espaces PVC (exécutions, fichiers, commandes, Git, terminaux interactifs, écran et audio Work Computer à l’adresse IP du Pod), sous un Role limité à l’espace de noms et des NetworkPolicies de refus par défaut, sans aucun socket Docker. Consultez le guide Kubernetes.	Pris en charge lorsque le backend s’exécute dans le cluster : le proxy signé cible directement l’adresse IP du Pod du bac à sable.

Exécuter Work lorsque Libre WebUI se trouve lui-même dans Docker

Chaque fichier Compose du dépôt active Work : l’image contient la CLI Docker et le fichier Compose monte /var/run/docker.sock. Docker Desktop fonctionne avec les valeurs de routage fournies. Docker Engine natif exige en plus que WORK_PREVIEW_BIND pointe vers une interface hôte non publique, joignable depuis les conteneurs voisins, comme décrit plus bas.

Work pilote le démon de l’hôte via ce socket. Les conteneurs des tâches sont donc des frères du conteneur Libre WebUI plutôt que ses enfants. Ils apparaissent dans docker ps sur l’hôte et sont nettoyés selon les mêmes règles de cycle de vie qu’une installation native.

Monter le socket Docker dans une application web donne à ce conteneur un contrôle équivalent à root sur l’hôte Docker. Work ne peut pas fonctionner sans lui ; Libre WebUI l’active donc plutôt que de livrer une fonction qui ne fait silencieusement rien. La conséquence est explicite : chaque administrateur Libre WebUI est, dans les faits, administrateur de l’hôte Docker. Les opérateurs assument les conséquences liées à la sécurité du démon, au réseau, au cycle de vie, aux sauvegardes et au contrôle d’accès. Supprimez la ligne /var/run/docker.sock de votre fichier Compose pour désactiver Work ; rien d’autre n’en dépend.

Pour conserver Work sans remettre le socket à l’application web, déployez plutôt docker-compose.socket-proxy.yml : un proxy de socket sur un réseau interne détient le socket et ne transmet que les sections de l’API utilisées par Work, tandis que Libre WebUI y accède via DOCKER_HOST. Consultez Isoler le contrôle de Docker pour comprendre ce que cette frontière couvre ou non.

Trois conditions doivent être réunies, et le volet Work indique celle qui échoue :

1. La CLI Docker doit être présente dans l’image. Elle est incluse dans l’image officielle ; une image personnalisée nécessite docker-cli ou un WORK_DOCKER_COMMAND qui y mène. Sinon : The "docker" CLI is not installed….
2. Le socket doit être monté. Sinon : No Docker daemon is reachable….
3. L’utilisateur du backend doit appartenir au groupe du socket. L’image s’exécute sous nodejs (uid 1001) et le socket appartient généralement à root ou docker. Compose transmet donc group_add: ['${DOCKER_GID:-0}']. La valeur par défaut convient à Docker Desktop ; un hôte Linux a besoin de son propre identifiant de groupe. Sinon : 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

Les ports d’aperçu des tâches restent liés à l’interface de bouclage de l’hôte Docker. Libre WebUI expose chaque aperçu actif via une URL de proxy signée et de même origine, notamment pour les ressources HTTP et les mises à niveau WebSocket. Ce fonctionnement est compatible avec HTTPS et les tunnels distants sans ouvrir les ports Docker éphémères au réseau. Les documents d’aperçu reçoivent une politique de bac à sable restrictive dans le navigateur, et l’arrêt ou le redémarrage d’un aperçu révoque son URL antérieure.

Lorsque le backend s’exécute lui-même dans Docker, la publication et la connexion peuvent utiliser des adresses différentes. Conservez WORK_PREVIEW_BIND=127.0.0.1 pour éviter d’exposer les ports éphémères, et définissez WORK_DOCKER_PUBLISHED_HOST sur l’adresse de l’hôte Docker accessible depuis le conteneur du backend (host.docker.internal avec Docker Desktop). Les profils Compose fournis définissent ces deux valeurs et mappent ce nom d’hôte. Les déploiements Linux natifs doivent remplacer WORK_PREVIEW_BIND par la passerelle du pont Docker (ou une autre interface hôte non publique et explicitement accessible) ; mapper uniquement host.docker.internal ne rend pas accessible un écouteur lié à l’interface de bouclage de l’hôte. Ne liez jamais ces ports éphémères bruts à 0.0.0.0.

La simultanéité est limitée séparément : WORK_MAX_ACTIVE_RUNTIMES_PER_USER vaut 2 par défaut et WORK_MAX_ACTIVE_RUNTIMES_GLOBAL vaut 3. Un administrateur peut donc exécuter une seconde tâche pendant que la première est occupée. La réponse des capacités indique les deux limites et l’occupation actuelle. Augmentez-les si l’hôte dispose de suffisamment de mémoire et de CPU.

Pour Kubernetes, installez le chart avec work.enabled=true au lieu d’exposer le socket d’un environnement d’exécution de nœud. Le chart crée le RBAC limité, l’espace de noms des bacs à sable, les politiques réseau et la configuration Pod/PVC décrits dans le guide Kubernetes.

Configuration de l’environnement d’exécution

Work lit les variables suivantes dans le processus du backend :

Variable	Valeur par défaut	Fonction
WORK_RUNTIME_BACKEND	docker	Pilote du bac à sable : docker ou kubernetes
WORK_RUNTIME_IMAGE	node:22.22-bookworm@sha256:2d178f2785b96dfbf62a416ca2e40f50e30150b4ff3320d706f0d96e90600eb3	Image utilisée pour les bacs à sable des tâches
WORK_DOCKER_COMMAND	docker	Exécutable de la CLI pour le backend Docker
WORK_COMMAND_TIMEOUT_MS	120000	Délai d’expiration par défaut d’une commande
WORK_MAX_OUTPUT_CHARS	50000	Taille maximale capturée des sorties de commandes ou recherches
WORK_MAX_AGENT_ROUNDS	48	Budget par exécution de tours modèle/outils, indépendant du fournisseur
WORK_MEMORY_LIMIT	2g	Limite de mémoire par conteneur
WORK_CPU_LIMIT	2	Limite de CPU par conteneur
WORK_PIDS_LIMIT	256	Limite de processus par conteneur
WORK_PREVIEW_PORT	4173	Port que l’application doit écouter dans le conteneur
WORK_PREVIEW_BIND	127.0.0.1	Interface de l’hôte sur laquelle le port d’aperçu est publié
WORK_DOCKER_PUBLISHED_HOST	identique à WORK_PREVIEW_BIND	Hôte ou IP appelé par le backend pour les ports Work publiés par Docker
WORK_COMPUTER_SCREEN_PORT	6080	Port WebSocket du pont d’écran dans le conteneur
WORK_COMPUTER_AUDIO_PORT	6081	Port WebSocket du pont audio dans le conteneur
WORK_RUN_LEASE_WAIT_MS	60000	Durée pendant laquelle une exécution attend le détenteur transitoire d’un bail d’exécution
WORK_MAX_ACTIVE_RUNTIMES_GLOBAL	3	Tâches simultanées reposant sur des conteneurs par instance Libre WebUI
WORK_MAX_ACTIVE_RUNTIMES_PER_USER	2	Tâches simultanées reposant sur des conteneurs par administrateur
WORK_MAX_TASKS_GLOBAL	500	Limite de tâches Work persistantes par instance Libre WebUI
WORK_MAX_TASKS_PER_USER	100	Limite de tâches Work persistantes par administrateur
WORK_NETWORK_NAME	libre-webui-work	Réseau bridge géré des bacs à sable en réseau
WORK_RUNTIME_DNS	non défini	IP de résolveurs séparées par des virgules et imposées aux tâches en réseau
WORK_DOCKER_SOCKET	DOCKER_HOST si unix:// ou tcp://, sinon /var/run/docker.sock	Point de terminaison Docker Engine utilisé par les terminaux interactifs
WORK_TERMINAL_MAX_SESSIONS_PER_TASK	2	Terminaux interactifs simultanés par tâche
WORK_TERMINAL_IDLE_TIMEOUT_MS	900000	Délai d’inactivité avant la fermeture d’une session de terminal
WORK_RUNTIME_IDLE_TIMEOUT_MS	0 (désactivé)	Arrêt d’un bac à sable après cette durée d’inactivité, aperçus compris
WORK_K8S_NAMESPACE	libre-webui-work	Espace de noms des Pods et PVC de bac à sable Kubernetes
WORK_K8S_STORAGE_CLASS	valeur par défaut du cluster	StorageClass des PVC d’espace de travail Kubernetes
WORK_K8S_WORKSPACE_SIZE	5Gi	Taille par défaut du PVC Kubernetes de chaque tâche
WORK_K8S_POD_READY_TIMEOUT_MS	900000	Attente maximale avant qu’un Pod de bac à sable soit prêt
WORK_K8S_POD_GONE_TIMEOUT_MS	60000	Attente maximale avant la disparition d’un Pod supprimé

Utilisez une version d’image ou un digest fixe en production. Une étiquette d’image modifiable peut changer à la fois les outils en ligne de commande disponibles et la frontière de sécurité sans modification de Libre WebUI.

Les opérations d’exécution, d’aperçu, d’assistance des fichiers, de commande et de recréation des bacs à sable partagent le même décompte de capacité dans le processus. Une opération imbriquée sur une tâche déjà comptée ne compte pas comme une tâche supplémentaire. Les requêtes dépassant une limite d’admission de tâche ou d’environnement d’exécution renvoient HTTP 429.

Limites fixes du protocole et de l’interface

Élément	Limite
Message d’une nouvelle tâche ou exécution	65,536 caractères et octets UTF-8
Identifiant du modèle lors de la création ou mise à jour d’une tâche	500 caractères et octets UTF-8
Identifiant du fournisseur plugin	200 caractères
Exécutions actives par tâche	1
Texte d’une commande	20,000 caractères
Délai de commande demandé par un outil	1 à 600 secondes
Préparation de l’aperçu	15 secondes
Lecture ou écriture de fichier	2,000,000 octets de texte UTF-8
Liste directe d’un répertoire	1,000 premières entrées
Page de messages	Jusqu’à 200 messages et 1,000,000 octets
Message individuel conservé	100 KB
Contexte de conversation envoyé au modèle	30 derniers messages utilisateur ou assistant, jusqu’à 256 KB
Sortie d’outil conservée	Environ 20,000 caractères sources et un marqueur
Coloration en direct de l’éditeur	8,000 caractères et 400 lignes
Mise en forme côté navigateur	100,000 caractères et 4,000 lignes
Sortie d’état Git	2,000,000 caractères capturés
Sortie de différence Git	600,000 caractères capturés
Historique Git	20 commits locaux
Chemins dans une demande d’indexation Git	200
Message de commit Git	4,000 caractères
Boucle de l’agent, toutes routes de fournisseur	48 tours par défaut, configurés par WORK_MAX_AGENT_ROUNDS
Budget de sécurité des appels d’outils	max(128, configured rounds × 8) appels

L’accès aux fichiers concerne le texte UTF-8. L’éditeur intégré n’est pas un éditeur de fichiers binaires et un fichier de plus de 2 MB ne peut pas être ouvert via l’API de fichiers Work.

Résumé de l’API

Tous les points de terminaison se trouvent sous /api/work et exigent une authentification ainsi que l’accès Work actuel indiqué par la base de données. Work est réservé aux administrateurs par défaut ; un administrateur peut ouvrir les opérations ordinaires sur les tâches aux utilisateurs actifs. La sélection de dossiers de l’hôte et les points de terminaison administratifs liés aux politiques et à l’accès restent réservés aux administrateurs.

Méthode	Chemin	Fonction
GET	/capabilities	Disponibilité et limites du fournisseur et de l’environnement sélectionnés
GET	/tasks	Répertorier les tâches de l’administrateur actuel
POST	/tasks	Créer une tâche et sa première exécution asynchrone
GET	/tasks/:id	Charger l’état de la tâche et ses messages récents
GET	/tasks/:id/messages	Paginer les anciens messages
PATCH	/tasks/:id	Renommer ou modifier la route explicite du modèle
DELETE	/tasks/:id	Supprimer la tâche et l’espace de travail durable
POST	/tasks/:id/runs	Démarrer une exécution ultérieure
POST	/tasks/:id/messages	Envoyer un message à l’agent pendant une exécution active
GET	/tasks/:taskId/runs/:runId/events	Diffuser en direct les événements authentifiés de l’exécution avec SSE
POST	/tasks/:id/cancel	Annuler l’exécution active
GET	/tasks/:id/approvals	Approbations en attente et état de la vérification automatique de la tâche
PUT	/tasks/:id/approvals	Activer ou désactiver les approbations pour la tâche
POST	/tasks/:id/approvals/:approvalId	Décider d’une approbation en attente (une fois, toujours, refus)
DELETE	/tasks/:id/approval-rules/:ruleId	Supprimer une règle « Toujours autoriser »
GET	/computer/setup	État de configuration de Work Computer (administration)
POST	/computer/setup	Construire l’image graphique et créer la politique (administration)
POST	/tasks/:id/computer/start	Démarrer la session Work Computer de la tâche
GET	/tasks/:id/computer/control	Personne qui pilote l’écran ; demande de prise de contrôle de l’agent
POST	/tasks/:id/computer/control	Prendre le contrôle de l’écran ou le renouveler
DELETE	/tasks/:id/computer/control	Rendre l’écran à l’agent
POST	/tasks/:id/computer/teach	Enregistrer une démonstration comme compétence enseignée
POST	/tasks/:id/computer/anchor	Résoudre l’élément sous un clic enregistré
POST	/computer/skills/:slug/trace	Ajouter une ligne de réussite ou d’échec à une compétence enseignée
GET	/tasks/:id/files	Répertorier un répertoire de l’espace de travail
GET	/tasks/:id/file	Lire un fichier texte de l’espace de travail
PUT	/tasks/:id/file	Enregistrer un fichier texte de l’espace de travail
GET	/tasks/:id/git	Lire l’état Git local protégé et son historique
GET	/tasks/:id/git/diff	Lire une différence locale limitée
POST	/tasks/:id/git/init	Initialiser Git en local
POST	/tasks/:id/git/stage	Indexer des chemins explicites de l’espace
POST	/tasks/:id/git/commit	Valider les modifications indexées
POST	/tasks/:id/git/branches	Créer une branche locale
POST	/tasks/:id/git/switch	Passer à une branche locale propre existante
POST	/tasks/:id/preview/start	Démarrer l’aperçu géré
POST	/tasks/:id/preview/stop	Arrêter l’aperçu géré

L’identifiant de la tâche est toujours vérifié par rapport au propriétaire authentifié. L’état actuel du compte, son rôle et la politique d’accès à Work sont lus dans la base de données à chaque requête ; une révocation prend donc effet même si un ancien JWT contient des déclarations de rôle obsolètes.

Le schéma de mise à jour des tâches conserve un champ backend networkEnabled pour la compatibilité interne. Il n’est pas exposé comme commande indépendante dans l’interface Work. Sélectionnez à la création de la tâche une politique d’exécution nommée dont la valeur réseau par défaut est celle voulue ; n’utilisez pas le champ brut comme API de configuration durable.

Suppression, modifications de compte et sauvegarde

Suppression d’une tâche

La suppression d’une tâche est volontairement destructive :

1. Le backend marque la tâche comme en cours de retrait afin qu’aucune nouvelle opération modifiable ne puisse commencer.
2. Toute exécution active est annulée et le bac à sable de la tâche est arrêté.
3. Libre WebUI valide les étiquettes de propriété de la tâche sur les ressources d’exécution.
4. Le conteneur ou Pod ainsi que le volume nommé ou PVC sont supprimés.
5. La tâche est supprimée de la base de données, avec ses exécutions et messages en cascade.
6. Les brouillons du navigateur pour cette tâche sont effacés après la réussite de l’API.

Si le nettoyage de l’environnement échoue, Libre WebUI conserve l’enregistrement de la tâche dans la base et renvoie une erreur. L’opérateur peut ainsi réparer le backend Docker ou Kubernetes et réessayer. Les métadonnées ne sont pas supprimées silencieusement en laissant un bac à sable ou un espace de travail non suivi.

Arrêter une exécution ou un aperçu diffère d’une suppression : l’exécution s’arrête, mais le volume nommé et la conversation sont préservés.

Rétrogradation d’un administrateur et suppression d’un utilisateur

Lorsqu’un administrateur est rétrogradé, Libre WebUI conserve la révocation du rôle avant de dépendre du nettoyage de l’environnement. Chaque requête Work ultérieure vérifie le rôle actuel et le mode d’accès. Le backend suspend ensuite les tâches Work de l’utilisateur lorsque le nouveau rôle ne dispose plus de l’accès et tente d’interrompre les exécutions actives et d’arrêter leurs bacs à sable. En cas d’échec du nettoyage, l’accès reste révoqué et la mise à jour du rôle signale l’échec afin qu’un opérateur puisse rétablir l’environnement et réessayer.

La suppression d’un autre utilisateur commence par retirer toutes ses ressources Work gérées. Si le nettoyage de l’environnement externe échoue, l’enregistrement de l’utilisateur est conservé pour qu’un administrateur puisse réessayer sans perdre les métadonnées de propriété nécessaires à un nettoyage sûr.

Sauvegarder la tâche complète

Une sauvegarde Work complète exige à la fois :

• la base de données Libre WebUI, qui contient la propriété des tâches, les noms de ressources Docker ou Kubernetes, le routage des fournisseurs, les exécutions, les messages et l’activité ; et
• chaque volume Docker ou PVC Kubernetes portant l’étiquette ai.libre-webui.managed=true, qui contient les fichiers Work.

Les conteneurs jetables et les processus d’aperçu n’ont pas besoin d’être sauvegardés. Pour obtenir une sauvegarde cohérente, interrompez toute nouvelle activité Work et arrêtez le backend avant de capturer la base de données et les espaces de travail. Suivez la procédure d’instantané des volumes Docker ou du fournisseur de stockage Kubernetes pour le backend utilisé.

Restaurez ensemble la base de données et les espaces de travail correspondants. Recréez chaque volume ou PVC sous le nom exact enregistré dans la base et restaurez ses métadonnées de propriété, notamment ai.libre-webui.task=<task UUID> et ai.libre-webui.managed=true. Copier uniquement les fichiers ne préserve pas les étiquettes Docker ou Kubernetes. Restaurer uniquement la base crée des enregistrements de tâches dont les fichiers sont absents ; restaurer uniquement le stockage perd la propriété des tâches et les noms de ressources générés que Libre WebUI utilise pour les retrouver et les valider.

Si l’installation utilise également des identifiants de fournisseurs chiffrés, suivez les principales consignes de sauvegarde de Libre WebUI pour son répertoire de données et sa clé de chiffrement.

Localisation et écriture arabe de droite à gauche

L’intégralité de l’interface Work est traduite dans les 25 langues prises en charge : anglais, arabe, bengali, tchèque, danois, allemand, espagnol, français, hindi, indonésien, islandais, italien, japonais, coréen, malais, néerlandais, polonais, portugais, russe, suédois, thaï, turc, ukrainien, vietnamien et chinois.

L’arabe applique lang="ar" et dir="rtl" avant le rendu de React. La barre latérale se déplace à droite, Conversation occupe le côté droit de la division sur ordinateur, Espace de travail le côté gauche, les icônes directionnelles sont inversées, la navigation par onglets suit l’ordre RTL et le redimensionnement par glissement ou au clavier utilise une sémantique RTL visuelle.

Les contenus techniques restent de gauche à droite lorsque le sens affecte leur exactitude :

• code et coloration syntaxique ;
• chemins du système de fichiers ;
• identifiants de modèles ;
• commandes et journaux d’aperçu ;
• sorties et métadonnées des outils ; et
• contenu des blocs de code.

Les noms de tâches, les invites en langage naturel, les erreurs, les noms de fichiers et les commandes d’aperçu utilisent le sens automatique du texte lorsque cela convient.

Dépannage

Environnement d’exécution indisponible avec npx

npx libre-webui exécute le backend sur l’hôte, mais n’installe pas Docker. Exécutez docker info sous le même utilisateur du système d’exploitation que celui qui démarre Libre WebUI. Si la commande est absente ou ne peut pas joindre le démon, installez ou démarrez Docker, ou corrigez les autorisations de cet utilisateur sur le démon, puis rechargez Work.

Vérifiez également qu’Ollama est sain ou qu’au moins un plugin de complétion ou de chat actif possède un modèle et des identifiants configurés pour l’administrateur actuel.

Environnement d’exécution indisponible dans Docker ou Kubernetes

Un déploiement Compose provenant du dépôt ne devrait pas signaler ce problème : l’image contient la CLI Docker et le fichier Compose monte le socket de l’hôte. Si cela arrive, le volet indique la cause : CLI absente d’une image personnalisée, montage du socket supprimé ou absent, ou groupe du socket auquel n’appartient pas l’utilisateur du conteneur. Dans ce dernier cas, définissez DOCKER_GID et recréez le conteneur. Consultez Exécuter Work lorsque Libre WebUI se trouve lui-même dans Docker.

Sur Kubernetes, activez l’environnement natif avec --set work.enabled=true. Libre indique alors kubernetes, sonde l’API Kubernetes et exécute les bacs à sable sous forme de Pods avec des espaces de travail PVC. Ne montez pas le socket de l’environnement de conteneurs d’un nœud ; consultez le guide Kubernetes.

Aucun modèle compatible avec Work

Pour Ollama, examinez ou choisissez un modèle qui annonce tools. Pour un plugin, vérifiez que :

• son type est complétion ou chat ;
• il est actif ;
• le modèle exact figure dans sa table de modèles configurée ;
• l’administrateur actuel possède une clé d’API utilisable ; et
• le modèle distant met en œuvre les appels d’outils de ce fournisseur.

Work ne se rabat jamais sur un autre fournisseur.

Échec d’une installation de paquet ou d’une commande Git distante

Vérifiez que la politique d’exécution nommée sélectionnée pour la tâche active l’accès réseau. Il n’existe pas de bouton réseau indépendant propre à la tâche. Examinez ensuite la configuration DNS, du proxy, du pare-feu ou de la NetworkPolicy, du registre, des certificats, de l’environnement d’exécution et du service en amont. Vérifiez également que l’image d’exécution sélectionnée contient la commande appelée.

L’onglet Git fonctionne uniquement en local et n’effectue jamais d’opération distante. N’utilisez le Terminal ou les commandes du modèle pour des opérations Git distantes que si la politique réseau et d’identifiants de la tâche les autorise délibérément. Ne collez aucun jeton d’accès de longue durée dans l’espace de travail d’une tâche.

Une exécution s’arrête à une limite de l’agent

Le modèle a peut-être épuisé le budget configuré de tours ou le budget de sécurité dérivé des appels d’outils. Work demande une transmission finale sans outils avant de terminer l’exécution ; examinez donc le travail achevé et les étapes restantes. La tâche reste sous Intervention requise, état final de cette exécution qui ne prétend délibérément pas que le travail est terminé. Démarrez une exécution ultérieure pour continuer dans le même espace durable, ou augmentez délibérément WORK_MAX_AGENT_ROUNDS pour tous les fournisseurs si l’hôte et la politique de coût du fournisseur distant autorisent des exécutions plus longues.

Erreur HTTP 429 au démarrage de Work

L’instance ou l’administrateur a atteint une limite d’admission des environnements actifs ou des tâches persistantes. Attendez l’arrêt d’une autre exécution ou d’un aperçu, supprimez les tâches obsolètes ou augmentez délibérément le réglage WORK_MAX_* correspondant sur un hôte disposant de ressources suffisantes.

L’aperçu ne devient pas prêt

Vérifiez que la commande continue de s’exécuter, se lie à 0.0.0.0 et écoute sur WORK_PREVIEW_PORT dans les 15 secondes. Lorsque le champ de commande est vide, Work détecte automatiquement un script dev de package.json ou un fichier index.html simple, y compris une seule application imbriquée. Si l’erreur signale plusieurs applications ou aucun point d’entrée pris en charge, saisissez une commande explicite dans le champ facultatif. Les commandes personnalisées démarrent dans /workspace ; utilisez donc cd <app-directory> && ... pour une application imbriquée.

L’aperçu fonctionne sur le serveur, mais pas dans un navigateur distant

Vérifiez que le déploiement exécute un build doté du proxy signé d’aperçu Work, puis redémarrez l’aperçu afin de remplacer toute ancienne URL de bouclage. Si les pages ordinaires se chargent, mais pas le rechargement à chaud, vérifiez que le proxy inverse et le tunnel autorisent les mises à niveau WebSocket sur /api/work/previews/. Le port publié par Docker doit rester sur l’interface de bouclage du backend et ne nécessite aucune ouverture dans le pare-feu.

Les fichiers subsistent, mais l’aperçu s’est arrêté

Ce comportement est attendu après une annulation, un redémarrage du backend, un arrêt explicite de l’aperçu ou l’échec des contrôles de préparation. Le processus d’aperçu est éphémère ; le volume nommé est durable. Rouvrez la tâche et redémarrez l’aperçu.

Impossible d’ouvrir ou d’enregistrer un fichier

L’API de fichiers intégrée accepte les fichiers texte UTF-8 d’une taille maximale de 2 MB. Si l’enregistrement signale que le fichier a changé depuis son ouverture, rechargez-le avant de le modifier de nouveau afin de ne pas écraser les changements d’un autre modèle ou navigateur.

La coloration syntaxique passe volontairement au texte brut au-delà de 8,000 caractères ou 400 lignes. La mise en forme possède une limite distincte de 100,000 caractères et 4,000 lignes et ne prend en charge que les familles de fichiers documentées.

Work indique qu’il récupère les bacs à sable

Le démarrage ou la suppression n’a pas pu prouver l’arrêt d’un ou plusieurs bacs à sable connus. Work reste fermé de manière sûre et réessaie toutes les 10 secondes. Rétablissez l’accès au démon Docker ou à l’API Kubernetes et examinez le journal du backend. Ne supprimez pas les lignes des tâches dans la base tant que leurs ressources d’exécution étiquetées doivent encore être rapprochées.

Échec de la suppression d’une tâche

Vérifiez que l’environnement d’exécution sélectionné est accessible. Une ressource en conflit dépourvue de l’étiquette ai.libre-webui.task attendue est délibérément refusée plutôt que supprimée. Résolvez soigneusement ce conflit de nom ou de propriété, puis réessayez la suppression.

Résumé de la sécurité

Avant d’activer Work dans une installation, retenez les points suivants :

• Work est réservé aux administrateurs par défaut. L’ouvrir à tous les utilisateurs fait de chaque compte actif un opérateur de bac à sable ; prenez cette décision délibérément. Les espaces liés à un dossier de l’hôte restent réservés aux administrateurs dans tous les modes.
• Le backend doit contrôler le démon Docker configuré ou l’espace de noms des bacs à sable Kubernetes.
• Les conteneurs réduisent l’exposition du système de fichiers, mais ne sont pas des machines virtuelles.
• Les tâches sans politique hors ligne nommée disposent d’une sortie réseau ; les politiques nommées choisissent la valeur par défaut, tandis que les restrictions par destination restent à la charge de l’opérateur.
• Les volumes Work n’ont aucun quota disque indépendant.
• L’onglet Git fonctionne uniquement en local ; son API ne monte ni n’accepte jamais d’identifiants distants.
• La politique de pare-feu de l’hôte, l’isolation du démon, les restrictions sortantes et les véritables quotas de volume restent des contrôles appliqués par l’opérateur.
• Les fournisseurs distants reçoivent les résultats d’outils demandés et peuvent occasionner plusieurs appels par exécution.
• Les ports d’aperçu restent sur l’interface de bouclage du backend et ne sont exposés que par des URL de proxy signées et révocables.
• Docker Compose standard fournit l’environnement Docker ; Kubernetes/Helm fournit l’environnement natif Pod/PVC lorsque work.enabled=true.
• Une sauvegarde complète exige à la fois la base de données Libre WebUI et les volumes Work.

Documentation connexe

• Démarrage rapide
• Travailler avec les modèles
• Raccourcis clavier
• Variables d’environnement
• Docker
• Kubernetes
• Authentification
• Dépannage