Les worktrees gérés

Les agents qui modifient du code ont besoin d’un endroit où travailler. Le faire dans le dépôt que vous utilisez aussi revient à avoir deux auteurs sur un même index, et des répertoires temporaires qui survivent à la tâche. Les worktrees gérés donnent à chaque tâche sa propre branche et sa propre copie de travail, enregistrées dans la base d’état partagée, hors du dépôt source. À la fin de la tâche, le contenu est capturé dans un instantané avant toute suppression, si bien qu’une copie abandonnée reste récupérable au lieu d’être perdue.

Où vivent les copies

• Par défaut, OpenClaw range les copies gérées dans un dossier de worktrees situé à l’intérieur du répertoire d’état, et une option globale permet de les placer dans un autre dossier ou sur un autre disque au moyen d’un chemin absolu sur l’hôte de la passerelle ou d’un chemin situé dans le dossier personnel de l’utilisateur de la passerelle, les chemins relatifs étant refusés.
• Chaque copie se trouve sous une empreinte de dépôt formée des 16 premiers caractères hexadécimaux d’une empreinte SHA-256 calculée sur le répertoire git commun canonique et l’URL d’origine, et un nom fourni doit respecter un motif en minuscules d’au plus 64 caractères, faute de quoi OpenClaw génère un nom lisible inspiré des crustacés comme brisk-lobster.
• OpenClaw crée une branche nommée d’après le worktree à la référence de base demandée et, sans référence, il interroge origin, utilise la branche par défaut distante lorsqu’elle est disponible et se rabat sur le HEAD local si le dépôt est hors ligne ou n’a pas de distant utilisable.
• Chaque ajout de copie pendant la création ou la restauration d’un instantané dispose de cinq minutes, y compris une nouvelle tentative de création depuis le HEAD local, tandis que les autres commandes git des worktrees gérés conservent un délai de deux minutes, tout comme le script facultatif de préparation du dépôt.

Les fichiers ignorés n’entrent jamais dans la base d’objets du dépôt.

Espace disque et capacité

OpenClaw considère 100 worktrees gérés actifs par répertoire d’état comme un objectif de nettoyage et non comme un plafond d’admission, si bien que le nombre seul ne bloque jamais une création ni une restauration. L’espace disque disponible borne malgré tout les nouvelles allocations, et une création n’évince jamais une autre session pour faire de la place. Avant d’allouer une copie, OpenClaw vérifie les volumes de destination, de métadonnées git, de copie source et d’état. Il garde dix pour cent de chaque volume libre, avec une réserve minimale de 4 Gio et maximale de 16 Gio, plus deux fois la taille estimée de la copie git et des fichiers provisionnés. Un modèle de source réutilisable et validé remplace la provision complète par une estimation des métadonnées de clonage et des écritures d’index, tandis qu’un modèle froid et tout repli natif sur git exigent de nouveau la provision complète juste avant l’allocation. Un script de préparation exécutable réclame en plus le plus grand des deux volumes suivants : 4 Gio ou l’empreinte actuelle de la copie source hors métadonnées git. L’espace est revérifié avant le provisionnement et la préparation, puis une nouvelle fois après. Ce sont des estimations prudentes et non un quota, car les commandes shell, les outils de déploiement et les sorties de compilation peuvent consommer le même volume. La suppression d’un instantané utilise une réserve plus faible de 128 Mio plus les écritures estimées, afin qu’un nettoyage sûr reste possible sous la réserve opérationnelle.

Accélération et modèles

• OpenClaw utilise automatiquement l’accélération du système de fichiers pour les nouveaux worktrees gérés lorsqu’elle est prise en charge, avec des instantanés Btrfs natifs sur Linux, un clone de répertoire APFS sur macOS qui préserve le contenu des fichiers, les droits d’exécution et les liens symboliques, et des clones de blocs ReFS sous Windows, y compris sur les volumes Dev Drive.
• Un seul modèle réutilisable ne contenant que la source est conservé par dépôt et par racine de destination, reconstruit dès que le commit demandé ou la politique de copie change, et le nettoyage retire les modèles inutilisés depuis sept jours.
• Les modèles ne contiennent que la source extraite, si bien que le provisionnement des fichiers ignorés et le script de préparation du dépôt s’exécutent séparément pour chaque nouveau worktree avec leurs permissions habituelles, et que ni les dépendances ni les sorties de préparation ne sont partagées par le modèle.

Un worktree n’a d’intérêt qu’à côté du reste de la configuration de l’agent : le Les espaces de travail des agents auquel il est rattaché, et les Les sessions qui le possèdent. Un worktree détenu par une session sert à chaque exécution de l’agent dans cette session, et supprimer la session capture puis retire la copie.

Pourquoi la suppression est prudente

Le nettoyage doit supposer qu’une copie abandonnée contient encore du travail que personne n’a poussé. C’est pourquoi la suppression crée d’abord un commit synthétique des fichiers suivis et des fichiers non suivis qui ne sont pas ignorés, l’épingle sous une référence d’instantané, et pourquoi un instantané raté interrompt la suppression à moins qu’une suppression forcée explicite n’abandonne cette sécurité. À la fin d’une exécution, un worktree n’est retiré que si l’état est propre et qu’aucun commit non poussé ne subsiste, sinon OpenClaw se contente de relâcher le verrou d’activité. Le nettoyage au démarrage puis toutes les heures capture et retire ensuite les worktrees non verrouillés détenus par Workboard ou par une session et inactifs depuis plus de sept jours, même modifiés, tandis que les worktrees manuels ne sont jamais retirés automatiquement. La même prudence détermine ce qui s’exécute dans une nouvelle copie : l’L’exécution de commandes du script de préparation du dépôt est réservée à un appelant doté du rôle administrateur, et les hooks de dépôt ainsi que la surveillance du système de fichiers sont toujours désactivés, ce qui compte lorsque l’agent lui-même tourne dans un Le bac à sable. Les enregistrements d’instantané restent restaurables pendant 30 jours avant que la référence et la ligne de registre ne soient supprimées.

Sur Diali

Diali exécute OpenClaw hébergé sur Diali pour vous, un assistant par client, avec une configuration d’exécution générée depuis le tableau de bord et remplacée à chaque version. L’état vit sur un volume persistant, si bien que le travail laissé par un agent est toujours là après une mise à jour ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). Le détail des offres se trouve sur Les tarifs Diali.

• Chaque tâche obtient sa branche et sa copie, hors du dépôt source.
• La suppression capture d’abord, et les instantanés durent 30 jours.
• Ce sont les contrôles de disque qui bornent les nouvelles allocations.