Interface de contrôle

• Discutez avec le modèle via le WebSocket du Gateway (chat.history, chat.send, chat.abort, chat.inject).
• Les actualisations de l’historique du chat demandent une fenêtre récente limitée avec des plafonds de texte par message, afin que les longues sessions n’obligent pas le navigateur à afficher la totalité de la transcription avant que le chat soit utilisable.
• Le survol ou la sélection au clavier d’un lien public vers une demande d’extraction ou un ticket GitHub affiche son état, son titre, son auteur, son activité récente, ses commentaires et ses statistiques de modifications. Le Gateway connecté récupère et met en cache les métadonnées publiques sans modifier la destination du lien, y compris lorsque l’interface utilise un Gateway distant. Le Gateway utilise GH_TOKEN ou GITHUB_TOKEN lorsqu’ils sont disponibles, après avoir confirmé que le dépôt est public ; sinon, il utilise l’API anonyme de GitHub avec une durée de cache plus longue.
• Conversez au moyen de sessions en temps réel dans le navigateur. OpenAI utilise directement WebRTC, Google Live utilise sur WebSocket un jeton de navigateur à usage unique et à portée limitée, et les plugins vocaux en temps réel réservés au back-end utilisent le transport relais du Gateway. Les sessions dont le fournisseur est géré par le client démarrent avec talk.client.create ; les sessions relayées par le Gateway démarrent avec talk.session.create. Le relais conserve les identifiants du fournisseur sur le Gateway tandis que le navigateur diffuse le flux PCM du microphone via talk.session.appendAudio, transmet les appels d’outils du fournisseur openclaw_agent_consult via talk.client.toolCall afin d’appliquer la politique du Gateway et d’utiliser le modèle OpenClaw configuré de plus grande capacité, et achemine le pilotage vocal d’une exécution active via talk.client.steer ou talk.session.steer.
• Diffusez les appels d’outils et les cartes de sortie en direct des outils dans le Chat (événements de l’agent). L’activité des outils s’affiche sous forme de lignes adaptées à leur type : les commandes shell affichent la commande avec coloration syntaxique et une sortie de style terminal ; les appels de modification et d’écriture pris en charge affichent des différences intégrées et limitées, les numéros de ligne lorsqu’ils sont disponibles et des statistiques +added -removed ; les appels consécutifs sont regroupés dans un résumé tel que « 13 commandes exécutées, 6 fichiers lus, 9 fichiers modifiés ». Pendant une exécution en direct, l’appel en cours le plus récent donne son nom à l’en-tête du groupe. Développez une ligne pour examiner ses arguments restants et sa sortie brute.
• Titres facultatifs générés par l’IA pour préciser l’objectif des appels d’outils complexes (longues commandes shell, outils de plugins comportant de nombreux arguments), activés avec gateway.controlUi.toolTitles: true (désactivés par défaut). Les titres proviennent de la méthode groupée chat.toolTitles au moyen du routage standard des modèles utilitaires — un utilityModel explicite (fournisseur choisi par l’opérateur, comme pour les autres tâches utilitaires), ou à défaut le petit modèle déclaré par défaut par le fournisseur de la session — et sont mis en cache côté Gateway pour chaque agent. Lorsque cette option facultative est désactivée ou qu’aucun modèle économique n’est utilisable, les lignes conservent leurs libellés déterministes et aucun appel de modèle n’est effectué.
• Lancez ou ignorez les tâches de suivi éphémères suggérées par le modèle ; les suggestions acceptées ouvrent une nouvelle session de worktree géré avec l’invite proposée.
• Onglet Activité proposant des résumés de l’activité en direct des outils, stockés localement dans le navigateur et privilégiant la suppression des données sensibles, à partir de la diffusion existante des événements session.tool et des outils.

• Canaux : état des canaux intégrés et des canaux de plugins groupés/externes, connexion par code QR et configuration par canal (channels.status, web.login.*, config.patch).
• Les actualisations des sondes de canaux conservent l’instantané précédent visible pendant l’exécution des vérifications lentes des fournisseurs, et signalent les instantanés partiels lorsqu’une sonde ou un audit dépasse le temps imparti par l’interface.
• Sessions : répertorier par défaut les sessions des agents configurés, épingler les sessions fréquentes, les renommer, archiver ou restaurer les sessions inactives, se rabattre depuis les clés de session obsolètes d’agents non configurés et appliquer des réglages prioritaires par session pour le modèle/la réflexion/le mode rapide/le mode détaillé/la trace/le raisonnement (sessions.list, sessions.patch). Les sessions épinglées sont triées au-dessus des sessions récentes non épinglées ; les sessions archivées figurent dans la vue des archives de la page Sessions et conservent leurs transcriptions. Les lignes affichent un point de non-lecture pour les sessions ayant enregistré une activité depuis leur dernière lecture, avec des actions permettant de les marquer comme non lues ou lues (sessions.patch { unread }), ainsi qu’une action Dupliquer qui crée une nouvelle branche de la transcription dans une nouvelle session (sessions.create { parentSessionKey, fork: true }). Les vignettes d’aperçu au-dessus du tableau résument l’ensemble chargé (nombre de sessions, exécutions en direct, sessions non lues, nombre total de jetons) ; chaque ligne comporte un pictogramme de type accompagné d’un point d’exécution en direct, l’état s’affiche sous forme d’un simple point avec un libellé, et la colonne Jetons affiche une jauge d’utilisation de la fenêtre de contexte lorsque la session indique le nombre de jetons et la taille du contexte. Les actions de gestion des lignes se trouvent dans un menu propre à chacune d’elles (bouton à trois points verticaux ou clic droit), qui reprend le menu de session de la barre latérale, et le volet de la ligne affiche l’environnement d’exécution de l’agent et la durée de l’exécution avec les autres détails de la session.
• Regroupement des sessions : une commande Regrouper par organise le tableau des sessions en sections selon les groupes personnalisés, le canal, le type, l’agent ou la date. Les groupes personnalisés sont conservés pour chaque session via sessions.patch (category), de sorte que les sessions démarrées depuis les canaux de messagerie (Discord, Telegram, WhatsApp, ...) puissent également être classées ; affectez des groupes en faisant glisser des lignes sur une section ou à l’aide du sélecteur de groupe propre à chaque ligne, et créez des groupes avec l’action Nouveau groupe.
• Mémoire (un onglet de la page Agents, limité à l’agent sélectionné) : état de Dreaming, option d’activation/désactivation et lecteur du Journal des rêves (doctor.memory.status, doctor.memory.dreamDiary, config.patch).

• Automatisations (tâches cron) : cartes de statistiques (nombre d’automatisations, nombre d’échecs, état du planificateur, prochain réveil) au-dessus d’un sélecteur d’onglets Automatisations/Historique des exécutions ; l’onglet Automatisations répertorie les tâches dans un tableau filtrable (Toutes/Actives/En pause, recherche, filtres de planification et de dernière exécution, menu d’actions par ligne) avec des suggestions de démarrage en dessous, tandis que l’onglet Historique des exécutions affiche les exécutions récentes de toutes les automatisations (cron.*).
• Tâches : registre en direct des tâches d’arrière-plan actives et récentes, avec sessions liées et possibilité d’annulation (tasks.*).
• Plugins : parcourez l’inventaire installé et la boutique sélectionnée, recherchez dans ClawHub, installez et supprimez du code de plugin, et activez ou désactivez les plugins installés (plugins.*) ; les lignes des serveurs MCP modifient mcp.servers au moyen des méthodes de configuration.
• Skills : état, activation/désactivation, installation, mises à jour des clés d’API (skills.*).
• Appareils : un inventaire unique réunit les enregistrements d’appareils appairés, le catalogue de nœuds et la présence en direct (device.pair.list, node.list, system-presence). L’hôte du Gateway est épinglé en premier ; les clients appairés affichent l’état de la connexion, les rôles, les jetons, les capacités et les commandes. Les appairages en double sont regroupés dans un groupe extensible, et Nettoyer N éléments obsolètes supprime en masse, après confirmation de l’administrateur, les doublons hors ligne qui ont été approuvés automatiquement (local silencieux, CIDR de confiance ou vérification SSH) ou qui sont antérieurs à la provenance des approbations. Les entrées peuvent être supprimées (node.pair.remove, device.pair.remove), l’appairage des appareils et les nouvelles approbations des nœuds sont gérés directement (device.pair.*, node.pair.approve/reject), et les codes de configuration mobile sont créés depuis la même carte.
• Approbations d’exécution : modifiez les listes d’autorisation du Gateway ou des nœuds, ainsi que la politique de demande pour exec host=gateway/node (exec.approvals.*).

• Consultez/modifiez ~/.openclaw/openclaw.json (config.get, config.set).
• Profil : page de paramètres affichant l’identité de l’agent par défaut ainsi que les statistiques d’utilisation cumulées — jetons sur toute la durée de vie, journée de pointe, session la plus longue, séries d’activité, carte thermique des jetons sur un an, principaux outils et points forts des canaux (usage.cost, sessions.usage).
• MCP dispose d’une page de paramètres dédiée comprenant des lignes de serveurs en lecture seule (transport, activation, résumés OAuth/filtres/parallélisme), des commandes courantes pour les opérateurs et l’éditeur de configuration mcp limité à cette section ; l’ajout, l’activation/désactivation et la suppression des serveurs s’effectuent sur la page Plugins.
• Fournisseurs de modèles : page de paramètres répertoriant chaque fournisseur de modèles configuré avec son icône de marque, son état d’authentification (models.authStatus), la disponibilité des modèles (models.list), les données en direct sur le forfait, les quotas et la facturation lorsque le fournisseur les communique (usage.status), ainsi que les dépenses des sessions locales au cours des 30 derniers jours (sessions.usage). Une action Actualiser relit l’état des identifiants et l’utilisation du fournisseur.
• Connexion : page de paramètres (sous Connexions) qui gère la propre liaison du tableau de bord au Gateway — URL WebSocket, jeton du Gateway, mot de passe et clé de session par défaut — ainsi que le dernier instantané de la poignée de main (état, durée de fonctionnement, intervalle des battements, dernière actualisation des canaux). L’écran de connexion hors ligne gère le cas de déconnexion ; cette page modifie la connexion lorsqu’elle est établie.
• Appliquez et redémarrez avec validation (config.apply), puis réveillez la dernière session active.
• Les écritures incluent une protection par hachage de base afin d’éviter d’écraser des modifications simultanées.
• Les écritures (config.set/config.apply/config.patch) vérifient au préalable la résolution des SecretRef actives pour les références présentes dans la charge utile de configuration envoyée ; les références actives envoyées qui ne peuvent pas être résolues sont rejetées avant l’écriture.
• Les enregistrements de formulaires ignorent les espaces réservés masqués devenus obsolètes qui ne peuvent pas être restaurés depuis la configuration enregistrée, tout en conservant les valeurs masquées qui correspondent encore à des secrets enregistrés.
• Le schéma et le rendu du formulaire proviennent de config.schema / config.schema.lookup, notamment les champs title/description, les indications d’interface correspondantes, les résumés des enfants immédiats, les métadonnées de documentation sur les nœuds imbriqués de type objet/joker/tableau/composition, ainsi que les schémas des plugins et des canaux lorsqu’ils sont disponibles. L’éditeur JSON brut est disponible uniquement lorsque l’instantané permet un aller-retour brut sûr ; sinon, l’interface de contrôle impose le mode Formulaire.
• Dans l’éditeur JSON brut, « Réinitialiser à la version enregistrée » préserve la structure créée en mode brut (mise en forme, commentaires, disposition de $include) au lieu de restituer un instantané aplati, afin que les modifications externes survivent à une réinitialisation lorsque l’instantané permet un aller-retour sûr.
• Les valeurs d’objet SecretRef structurées sont affichées en lecture seule dans les champs de texte du formulaire afin d’éviter toute corruption accidentelle lors de la conversion d’un objet en chaîne.

• L’analyse des jetons et des coûts estimés dérivée des sessions reste distincte de la facturation des fournisseurs.
• Les cartes des fournisseurs appellent usage.status et affichent en direct les noms des forfaits, les fenêtres de quota, les soldes, les dépenses et les budgets communiqués par les plugins de fournisseurs configurés.
• Une erreur d’utilisation d’un fournisseur ne bloque pas le tableau de bord des sessions et des coûts ; les cartes des fournisseurs indisponibles affichent leur propre état d’erreur.

• Débogage : instantanés de l’état, de l’intégrité et des modèles, journal des événements et appels RPC manuels (status, health, models.list).
• Le journal des événements comprend les durées d’actualisation et des appels RPC de l’interface de contrôle, les durées de rendu lentes du chat et de la configuration, ainsi que des entrées sur la réactivité du navigateur pour les longues trames d’animation ou les tâches longues lorsque le navigateur expose ces types d’entrées PerformanceObserver.
• Journaux : suivi en direct des journaux de fichiers du Gateway avec filtrage/exportation (logs.tail).
• Mise à jour : exécutez une mise à jour du paquet ou de Git suivie d’un redémarrage (update.run) avec un rapport de redémarrage, puis interrogez update.status après la reconnexion afin de vérifier la version du Gateway en cours d’exécution.

• La sélection d’une ligne ouvre une vue détaillée en pleine page avec un commutateur Actif/En pause et Exécuter maintenant dans l’en-tête (exécuter si l’échéance est atteinte, cloner et supprimer dans son menu) ; l’onglet Paramètres permet de modifier l’automatisation directement (invite, détails, fréquence, remplacements avancés), tandis que l’onglet Historique des exécutions affiche les exécutions de cette automatisation.
• Les automatisations de démarrage situées sous le tableau préremplissent le formulaire de création avec une invite et une planification modifiables.
• Pour les tâches isolées, la livraison utilise par défaut l’annonce d’un résumé ; choisissez aucune pour les exécutions strictement internes.
• Les champs de canal et de cible apparaissent lorsque l’annonce est sélectionnée.
• Le mode Webhook utilise delivery.mode = "webhook" avec delivery.to défini sur une URL de Webhook HTTP(S) valide.
• Pour les tâches de la session principale, les modes de livraison Webhook et aucune sont disponibles.
• Les contrôles de modification avancés comprennent la suppression après l’exécution, l’effacement du remplacement de l’agent, les options cron exactes/décalées, les remplacements du modèle et du niveau de réflexion de l’agent, ainsi que les commutateurs de livraison au mieux.
• La validation du formulaire s’effectue directement avec des erreurs au niveau des champs ; les valeurs non valides désactivent le bouton d’enregistrement jusqu’à leur correction.
• Définissez cron.webhookToken pour envoyer un jeton Bearer dédié ; s’il est omis, le Webhook est envoyé sans en-tête d’authentification.
• cron.webhook est une solution de repli héritée et obsolète : exécutez openclaw doctor --fix pour migrer les tâches enregistrées qui utilisent encore notify: true vers une livraison Webhook explicite par tâche ou une livraison à l’achèvement.

• chat.send est non bloquant : il envoie immédiatement un accusé de réception avec { runId, status: "started" }, puis la réponse est diffusée via les événements chat. Les clients Control UI de confiance peuvent également recevoir des métadonnées facultatives sur le délai d'accusé de réception à des fins de diagnostic local.
• Les téléversements dans le chat acceptent les images ainsi que les fichiers non vidéo. Les images conservent leur chemin d'image natif ; les autres fichiers sont stockés comme médias gérés et affichés dans l'historique sous forme de liens vers des pièces jointes.
• Un nouvel envoi avec le même idempotencyKey renvoie { status: "in_flight" } pendant l'exécution, puis { status: "ok" } une fois celle-ci terminée.
• La taille des réponses chat.history est limitée pour garantir la sécurité de l'interface utilisateur. Lorsque les entrées de transcription sont trop volumineuses, le Gateway peut tronquer les longs champs de texte, omettre les blocs de métadonnées lourds et remplacer les messages surdimensionnés par un espace réservé ([chat.history omitted: message too large]).
• Lorsqu'un message visible de l'assistant a été tronqué dans chat.history, le lecteur latéral peut récupérer à la demande l'entrée complète de la transcription normalisée pour l'affichage via chat.message.get, à partir de sessionKey, de la agentId active si nécessaire et de la messageId de transcription. Si le Gateway ne peut toujours pas en renvoyer davantage, le lecteur affiche explicitement un état d'indisponibilité au lieu de répéter silencieusement l'aperçu tronqué.
• Les images générées ou produites par l'assistant sont conservées sous forme de références à des médias gérés et resservies via des URL de médias authentifiées du Gateway ; les rechargements ne dépendent donc pas de la présence persistante des charges utiles d'image base64 brutes dans la réponse de l'historique du chat.
• Lors du rendu de chat.history, la Control UI supprime du texte visible de l'assistant les balises de directive intégrées destinées uniquement à l'affichage (par exemple [[reply_to_*]] et [[audio_as_voice]]), les charges utiles XML d'appel d'outil en texte brut (notamment <tool_call>...</tool_call>, <function_call>...</function_call>, <tool_calls>...</tool_calls>, <function_calls>...</function_calls> et les blocs d'appel d'outil tronqués), ainsi que les jetons de contrôle du modèle ASCII ou pleine chasse qui ont fuité. Elle omet les entrées de l'assistant dont l'intégralité du texte visible se réduit au jeton silencieux exact NO_REPLY / no_reply ou au jeton d'accusé de réception du Heartbeat HEARTBEAT_OK.
• Pendant un envoi actif et l'actualisation finale de l'historique, la vue du chat maintient visibles les messages utilisateur et assistant optimistes locaux si chat.history renvoie brièvement un instantané plus ancien ; la transcription canonique remplace ces messages locaux dès que l'historique du Gateway est à jour.
• Les événements chat en direct représentent l'état de livraison, tandis que chat.history est reconstruit à partir de la transcription durable de la session. Après les événements finaux d'outil, la Control UI recharge l'historique et ne fusionne qu'une petite fin optimiste ; la limite de la transcription est documentée dans WebChat.
• chat.inject ajoute une note de l'assistant à la transcription de la session et diffuse un événement chat pour les mises à jour de l'interface utilisateur uniquement (aucune exécution d'agent, aucune livraison sur un canal).
• La barre latérale répertorie chaque session active chargée, par section d'agent et dans les catégories épinglées/canal/travail/personnalisées/Chats, avec une seule action Nouvelle session qui ouvre la boîte de dialogue de brouillon. L'ouverture d'une ligne visible déplace uniquement la surbrillance. Les groupes personnalisés sont repliables et réorganisables par glisser-déposer, et les sessions peuvent être déposées dans un groupe ou dans Chats ; les noms et l'ordre des groupes sont synchronisés via le Gateway, tandis que leur état replié reste enregistré dans le navigateur. Une nouvelle session du tableau de bord reçoit de façon asynchrone un titre généré concis à partir de son premier message qui n'est pas une commande ; les noms explicites ne sont jamais remplacés. Définissez agents.defaults.utilityModel (ou agents.list[].utilityModel) pour acheminer cet appel de modèle distinct vers un modèle moins coûteux. Le développement de la section d'un autre agent permet de parcourir les sessions de cet agent sans quitter le chat ouvert.
• La recherche de sessions se trouve dans la palette de commandes (⌘K ou le champ Recherche en haut de la barre latérale) : la saisie d'une requête parcourt un nombre limité de pages correspondantes parmi les agents, filtre les lignes internes enfants/Cron et répertorie les correspondances visibles à côté des commandes de navigation. La page Sessions conserve la liste exhaustive consultable avec des filtres.
• Chaque ligne de la barre latérale conserve un accès direct à l'épinglage ainsi qu'un menu contextuel complet pour l'état non lu, le renommage, la duplication, le regroupement, l'archivage et la suppression. Les lignes sélectionnées simultanément (Cmd/Ctrl-clic, Maj-clic pour les plages) disposent d'un menu d'actions groupées couvrant l'état non lu, le regroupement, l'archivage et la suppression ; l'archivage et la suppression groupés restent désactivés sauf si toutes les sessions sélectionnées peuvent être archivées. Une exécution active et la session principale d'un agent ne peuvent pas être archivées. L'archivage ou la suppression de la session actuellement sélectionnée fait revenir le chat à la session principale de cet agent.
• Dans l'application macOS, la marque OpenClaw utilise la bande autrement vide de la barre de titre native, à côté des commandes de la fenêtre, au lieu d'occuper une ligne de la barre latérale.
• Sur les largeurs d'écran de bureau, les commandes du chat restent sur une seule ligne compacte et se replient lors du défilement vers le bas dans la transcription ; le défilement vers le haut, le retour au début ou l'arrivée à la fin rétablit les commandes.
• Les messages consécutifs identiques composés uniquement de texte s'affichent dans une seule bulle avec un badge indiquant leur nombre. Les messages contenant des images, des pièces jointes, une sortie d'outil ou des aperçus Canvas ne sont pas regroupés.
• Lorsque l'extraction d'une session se trouve sur une branche non définie par défaut d'un dépôt GitHub, la vue du chat épingle des pastilles de demandes de tirage au-dessus de la zone de rédaction : numéro de PR, dépôt, branche, nombre de différences, pastille de CI et état brouillon/fusionné/fermé, chaque élément comportant un lien vers la PR. La ligne affiche au maximum deux pastilles — les PR actives (ouvertes/brouillons) en premier — et un bouton « Afficher plus » révèle l'historique fusionné/fermé replié. La pastille de CI ouvre une petite fenêtre contextuelle de suivi de la CI avec le nombre de vérifications réussies/échouées/en cours/ignorées et un lien vers la page des vérifications de la PR. La détection s'exécute côté serveur via controlUi.sessionPullRequests, qui réutilise les valeurs GH_TOKEN/GITHUB_TOKEN du Gateway lorsqu'elles sont définies. Lorsque la limite de débit de l'API GitHub est atteinte, les pastilles conservent le dernier état connu et affichent un avertissement indiquant que cet état peut être obsolète ; fermer une pastille la masque pour cette session dans le profil de navigateur actuel. Avant qu'une PR n'existe, la ligne affiche la branche elle-même — dépôt, nom de la branche et taille +/− des différences par rapport à la base de fusion de la branche par défaut (travail validé et non validé) — avec un bouton Créer une PR qui ouvre la page de création d'une demande de tirage de GitHub. La ligne apparaît dès que la branche poussée contient des commits à comparer et se masque lorsqu'une PR ouverte ou en brouillon existe. La ligne de branche provient uniquement du dépôt Git local ; elle reste donc disponible pendant la limitation du débit de GitHub et présente le même avertissement d'état obsolète, car l'indication « aucune PR trouvée » ne peut être considérée comme fiable avant la réinitialisation de la limite.
• Le panneau des différences de session montre ce que l'extraction d'une session a réellement modifié : le bouton de branche (dans l'en-tête du volet de l'espace de travail, dans l'en-tête du volet fractionné ou sur le bouton flottant du chat à volet unique) ouvre le panneau détaillé avec les différences fichier par fichier des travaux de branche, non validés et non suivis par rapport à la base de fusion de la branche par défaut de l'extraction — point d'état, flèche de renommage, nombres +/− par fichier, fichiers repliables et marqueurs « N lignes non modifiées » entre les blocs de différences. Les différences sont calculées côté serveur via la méthode Gateway sessions.diff (portée operator.read) ; les fichiers binaires et surdimensionnés sont réduits à des entrées contenant uniquement des statistiques, et le bouton n'apparaît que lorsque le Gateway connecté annonce sessions.diff.
• Le volet de l'espace de travail de la session dans chaque panneau de Chat répertorie les fichiers de session, les fichiers du projet et les artefacts. Il est ancré par défaut sur le bord droit du panneau ; faites glisser son en-tête (ou utilisez le bouton d'ancrage) pour le déplacer vers le bas, et ce choix est enregistré dans le profil de navigateur actuel. Un volet replié n'occupe absolument aucun espace : rouvrez-le avec ⇧⌘B, le bouton des fichiers dans l'en-tête du volet fractionné ou le bouton flottant des fichiers dans le chat à volet unique (les deux affichent un badge indiquant le nombre de fichiers modifiés). Le panneau détaillé distinct consacré aux fichiers, aux outils et à Canvas n'est pas affecté.
• Un clic sur une référence de fichier dans le chat, sur un chemin de fichier dans une carte d'outil de lecture/modification/écriture développée ou sur une ligne de fichier dans le volet de l'espace de travail ouvre le panneau détaillé du fichier : une vue du code basée sur CodeMirror avec coloration syntaxique, numéros de ligne, accès direct à une ligne, recherche dans le fichier, actions de copie et menu d'ouverture dans un éditeur externe. Lorsque le Gateway annonce sessions.files.set à une connexion operator.admin, le panneau ajoute un mode Modification avec suivi des modifications non enregistrées et enregistrement par Cmd/Ctrl-S ; les brouillons non enregistrés persistent pendant la navigation entre les fichiers, les panneaux et les sessions dans l'onglet actuel du navigateur, jusqu'à leur enregistrement ou leur abandon explicite. Les enregistrements utilisent une opération de comparaison et permutation fondée sur une empreinte du contenu renvoyée par sessions.files.get : si le fichier a été modifié sur le disque depuis son chargement (par exemple parce que l'agent a continué à travailler), le panneau affiche un avis de conflit avec les actions Reload (utiliser le contenu le plus récent) et Overwrite (conserver la modification locale). Les écritures passent par les mêmes protections sécurisées du système de fichiers de l'espace de travail que les lectures — confinement du chemin, rejet des liens symboliques/liens physiques et limite UTF-8 de 256 KB — et ne remplacent que des fichiers existants ; l'éditeur n'en crée ni n'en supprime jamais.
• Le volet des tâches en arrière-plan de chaque panneau de Chat répertorie les tâches en arrière-plan et les sous-agents de l'agent actuel (tasks.list limité à l'agent et tenu à jour par les événements task) : les travaux en cours affichent en direct le temps écoulé, le nombre d'utilisations d'outils, l'outil actuellement utilisé et une commande d'arrêt ; la section repliable des travaux terminés ajoute la durée des exécutions ; et un lien Afficher la transcription ouvre la session enfant de la tâche dans le panneau. Ouvrez-le avec le bouton d'activité dans l'en-tête du volet fractionné ou le bouton flottant d'activité dans le chat à volet unique — l'instantané des tâches est chargé de manière anticipée, de sorte que les deux affichent un badge du nombre de tâches en cours sans qu'il soit nécessaire d'ouvrir d'abord le volet. La page Tâches reste le registre complet couvrant tous les agents.
• Le volet de l'espace de travail, le volet des tâches en arrière-plan et le panneau détaillé s'adaptent à la largeur propre de chaque panneau plutôt qu'à celle de la fenêtre : dans un panneau étroit ou une fenêtre compacte, les deux volets se présentent sous forme de bandes inférieures (les commandes d'ancrage latéral restent masquées jusqu'à ce que le panneau s'élargisse ; le volet de l'espace de travail est prioritaire pour l'emplacement latéral lorsqu'une seule colonne tient), et le panneau détaillé s'empile sous le fil avec une poignée de redimensionnement horizontale au lieu de partager la même ligne. Sur les écrans de la taille d'un téléphone, le panneau détaillé s'ouvre toujours en plein écran.
• Les sélecteurs de modèle et de réflexion dans l'en-tête du chat mettent immédiatement à jour la session active via sessions.patch ; il s'agit de remplacements persistants pour la session, et non d'options d'envoi valables pour un seul tour.
• Vue fractionnée : ouvrez-la depuis la rangée de boutons flottants en haut à droite (à côté des boutons des différences de session, des tâches en arrière-plan et des fichiers de session), puis fractionnez le panneau actif vers la droite ou vers le bas, autant de fois que l'espace le permet. Chaque panneau dispose de sa propre session, transcription, zone de rédaction et flux d'outils.
• Faites glisser une session de la barre latérale vers le chat pour l'ouvrir dans un panneau. Un aperçu animé du dépôt glisse entre les zones et indique le résultat — « Fractionner » sur la moitié exacte qu'occupera un nouveau panneau, « Ouvrir ici » sur un panneau entier — et les dépôts fonctionnent également depuis le mode à panneau unique.
• Le panneau fractionné actif détermine la sélection dans la barre latérale et l'URL. Chaque panneau possède sa propre ligne d'en-tête avec le titre de la session ainsi que les commandes du volet de l'espace de travail, de fractionnement et de fermeture ; les séparateurs redimensionnent les colonnes et les panneaux empilés, et le navigateur enregistre localement la disposition entre les rechargements.
• Sur les écrans étroits, la vue fractionnée conserve la disposition, mais n'affiche que le panneau actif, y compris son en-tête avec la commande de fermeture.
• Si vous envoyez un message alors qu'une modification du sélecteur de modèle pour la même session est encore en cours d'enregistrement, la zone de rédaction attend la fin de la mise à jour de cette session avant d'appeler chat.send, afin que l'envoi utilise le modèle sélectionné.
• La saisie de /new crée la même nouvelle session de tableau de bord que Nouveau chat et y bascule, sauf si session.dmScope: "main" est configuré et que le parent actuel est la session principale de l'agent ; dans ce cas, cette session principale est réinitialisée sur place. La saisie de /reset conserve la réinitialisation explicite sur place du Gateway pour la session actuelle.
• Le sélecteur de modèle du chat demande la vue des modèles configurés du Gateway. Si agents.defaults.models est présent, cette liste d'autorisation pilote le sélecteur, y compris les entrées provider/* qui maintiennent dynamiques les catalogues propres aux fournisseurs. Sinon, le sélecteur affiche les entrées models.providers.*.models explicites ainsi que les fournisseurs disposant d'une authentification utilisable. Le catalogue complet reste disponible via l'appel RPC de débogage models.list avec view: "all".
• Lorsque les rapports récents d’utilisation de la session du Gateway incluent le nombre actuel de jetons du contexte, la barre d’outils de la zone de rédaction du chat affiche un petit anneau d’utilisation du contexte indiquant le pourcentage utilisé. Ouvrez l’anneau pour afficher la fenêtre de contexte actuelle, le nombre de jetons de la dernière exécution et le coût total estimé, l’identité du fournisseur et du modèle, ainsi que la répartition des coûts d’entrée, de sortie et de cache de la dernière réponse du fournisseur, lorsqu’elle est communiquée. L’anneau adopte un style d’avertissement lorsque la pression sur le contexte est élevée et, aux niveaux de Compaction recommandés, affiche un bouton compact qui exécute le processus normal de Compaction de la session. Les instantanés obsolètes du nombre de jetons sont masqués jusqu’à ce que le Gateway communique de nouveau des données d’utilisation récentes.

Le mode Conversation utilise un fournisseur vocal en temps réel enregistré. Configurez OpenAI avec talk.realtime.provider: "openai" ainsi qu’un profil de clé API openai, talk.realtime.providers.openai.apiKey ou OPENAI_API_KEY. OpenAI Realtime utilise l’API publique de la plateforme et nécessite une clé API de la plateforme ; une connexion OAuth Codex ne satisfait pas cette interface. Configurez Google avec talk.realtime.provider: "google" ainsi que talk.realtime.providers.google.apiKey. Le navigateur ne reçoit jamais de clé API standard du fournisseur : OpenAI reçoit un secret client Realtime éphémère pour WebRTC, tandis que Google Live reçoit un jeton d’authentification à usage unique et à portée limitée pour l’API Live destiné à une session WebSocket du navigateur, les instructions et les déclarations d’outils étant verrouillées dans le jeton par le Gateway. Les fournisseurs qui n’exposent qu’un pont dorsal en temps réel utilisent le transport relais du Gateway, de sorte que les identifiants et les sockets du fournisseur restent côté serveur tandis que l’audio du navigateur transite par des RPC Gateway authentifiés. L’invite de session Realtime est assemblée par le Gateway ; talk.client.create n’accepte pas les remplacements d’instructions fournis par l’appelant.

Les valeurs par défaut persistantes du fournisseur, du modèle, de la voix, du transport, de l’effort de raisonnement, du seuil VAD exact, de la durée de silence et du remplissage de préfixe se trouvent dans Settings → Communications → Talk ; leur modification nécessite l’accès operator.admin. La configuration du relais Gateway impose le chemin de relais dorsal ; la configuration de WebRTC laisse la session sous le contrôle du client et échoue, au lieu de revenir silencieusement au relais, si le fournisseur ne peut pas créer de session de navigateur.

Le contrôle Conversation lui-même est le bouton du microphone dans la barre d’outils de rédaction. Son chevron répertorie System default et tous les microphones exposés par le navigateur, y compris les entrées USB, Bluetooth et virtuelles. L’identifiant de l’appareil sélectionné reste local au navigateur et n’est jamais envoyé au Gateway ; si cet appareil précis disparaît, Conversation vous demande de choisir une autre entrée au lieu d’enregistrer silencieusement avec un autre microphone. Lorsque Conversation est active, le bouton du microphone devient une pastille affichant l’indicateur de niveau d’entrée en direct ; cliquer dessus arrête l’entrée vocale et le survol révèle le glyphe d’arrêt. Les lecteurs d’écran annoncent Connecting voice input..., Listening... ou Asking OpenClaw... lorsqu’un appel d’outil en temps réel consulte le modèle plus volumineux configuré au moyen de talk.client.toolCall. L’arrêt d’une réponse d’agent en cours reste un contrôle carré Stop distinct à côté de la pastille.

Test de fonctionnement en direct pour les mainteneurs : OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts vérifie le pont WebSocket dorsal d’OpenAI, l’échange SDP WebRTC d’OpenAI dans le navigateur, la configuration WebSocket de Google Live dans le navigateur avec un jeton à portée limitée et l’adaptateur de navigateur du relais Gateway avec un média de microphone simulé. La commande affiche uniquement l’état du fournisseur et ne journalise aucun secret.

• Cliquez sur Stop (appelle chat.abort).
• Tant qu’une exécution est active, les suivis normaux sont mis en file d’attente. Cliquez sur Steer sur un message en attente pour injecter ce suivi dans le tour en cours.
• Saisissez /stop (ou des phrases d’abandon autonomes comme stop, stop action, stop run, stop openclaw, please stop) pour effectuer un abandon hors bande.
• chat.abort prend en charge { sessionKey } (sans runId) afin d’abandonner toutes les exécutions actives de cette session.

• Lorsqu’une exécution est abandonnée, le texte partiel de l’assistant peut toujours être affiché dans l’interface utilisateur.
• Le Gateway conserve le texte partiel abandonné de l’assistant dans l’historique de la transcription lorsqu’une sortie mise en mémoire tampon existe.
• Les entrées conservées incluent des métadonnées d’abandon afin que les consommateurs de la transcription puissent distinguer les sorties partielles abandonnées des sorties issues d’un achèvement normal.

{  gateway: {    controlUi: { allowInsecureAuth: true },    bind: "tailnet",    auth: { mode: "token", token: "replace-me" },  },}

allowInsecureAuth est uniquement une option de compatibilité locale :

• Elle permet aux sessions de la Control UI sur localhost de fonctionner sans identité d’appareil dans des contextes HTTP non sécurisés.
• Elle ne contourne pas les vérifications d’appairage.
• Elle n’assouplit pas les exigences d’identité d’appareil pour les connexions distantes (hors localhost).

• Une authentification réussie par proxy de confiance peut autoriser des sessions opérateur de la Control UI sans identité d’appareil.
• Cela ne s’étend pas aux sessions de la Control UI ayant le rôle de Node.
• Les proxys inverses en boucle locale sur le même hôte ne satisfont toujours pas l’authentification par proxy de confiance ; consultez Authentification par proxy de confiance.

• gatewayUrl est enregistré dans localStorage après le chargement, puis supprimé de l’URL.
• Si vous transmettez un point de terminaison ws:// ou wss:// complet via gatewayUrl, encodez la valeur dans l’URL afin que le navigateur analyse correctement la chaîne de requête.
• Dans la mesure du possible, token doit être transmis dans le fragment d’URL (#token=...). Les fragments ne sont pas envoyés au serveur, ce qui évite les fuites dans les journaux de requêtes et via Referer. Les anciens paramètres de requête ?token= sont encore importés une fois à des fins de compatibilité, mais uniquement comme solution de repli, puis sont supprimés immédiatement après l’amorçage.
• password est conservé uniquement en mémoire.
• Lorsque gatewayUrl est défini, l’interface ne se rabat pas sur les identifiants provenant de la configuration ou de l’environnement. Fournissez explicitement token (ou password) ; l’absence d’identifiants explicites constitue une erreur.
• Utilisez wss:// lorsque le Gateway se trouve derrière TLS (Tailscale Serve, proxy HTTPS, etc.).
• gatewayUrl est uniquement accepté dans une fenêtre de premier niveau, et non dans un contenu intégré, afin d’empêcher le détournement de clic.
• Les déploiements publics de la Control UI hors boucle locale doivent définir explicitement gateway.controlUi.allowedOrigins avec des origines complètes. Les chargements privés depuis le LAN/Tailnet et de même origine provenant de la boucle locale, d’hôtes RFC1918/à liaison locale, .local, .ts.net ou Tailscale CGNAT sont acceptés sans activer la solution de repli fondée sur l’en-tête Host.
• Le démarrage du Gateway peut initialiser des origines locales telles que http://localhost:<port> et http://127.0.0.1:<port> à partir de l’adresse d’écoute et du port effectifs à l’exécution, mais les origines des navigateurs distants nécessitent toujours des entrées explicites.
• N’utilisez pas gateway.controlUi.allowedOrigins: ["*"], sauf pour des tests locaux strictement contrôlés ; cela signifie autoriser n’importe quelle origine de navigateur, et non « faire correspondre l’hôte que j’utilise ».
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true active le mode de repli de l’origine fondé sur l’en-tête Host, mais il s’agit d’un mode de sécurité dangereux.