Interface utilisateur de contrôle

• Discuter avec le modèle via Gateway WS (chat.history, chat.send, chat.abort, chat.inject).
• Les actualisations de l’historique de chat demandent une fenêtre récente bornée avec des plafonds de texte par message afin que les grandes sessions n’obligent pas le navigateur à rendre une charge utile de transcription complète avant que le chat ne devienne utilisable.
• Converser via des sessions temps réel du navigateur. OpenAI utilise WebRTC direct, Google Live utilise un jeton de navigateur contraint à usage unique sur WebSocket, et les plugins vocaux temps réel uniquement backend utilisent le transport relais du Gateway. Les sessions de fournisseur détenues par le client commencent par talk.client.create ; les sessions relais du Gateway commencent par talk.session.create. Le relais conserve les identifiants du fournisseur sur le Gateway pendant que le navigateur diffuse le PCM du microphone via talk.session.appendAudio, transmet les appels d’outils fournisseur openclaw_agent_consult via talk.client.toolCall pour la stratégie du Gateway et le plus grand modèle OpenClaw configuré, et route le pilotage vocal de l’exécution active via talk.client.steer ou talk.session.steer.
• Diffuser les appels d’outils + les cartes de sortie d’outils en direct dans Chat (événements d’agent).
• Onglet Activité avec des résumés locaux au navigateur et privilégiant la rédaction de l’activité d’outils en direct à partir de la livraison existante session.tool / événements d’outils.

• Canaux : état des canaux intégrés et des canaux de plugins groupés/externes, connexion QR et configuration par canal (channels.status, web.login.*, config.patch).
• Les actualisations de sondes de canal gardent l’instantané précédent visible pendant que les vérifications lentes du fournisseur se terminent, et les instantanés partiels sont étiquetés lorsqu’une sonde ou un audit dépasse son budget d’interface.
• Instances : liste de présence + actualisation (system-presence).
• Sessions : lister par défaut les sessions d’agents configurés, épingler les sessions fréquentes, les renommer, archiver ou restaurer les sessions inactives, revenir depuis les clés de session d’agent non configuré obsolètes, et appliquer des remplacements par session de modèle/thinking/fast/verbose/trace/reasoning (sessions.list, sessions.patch). Les sessions épinglées sont triées au-dessus des sessions récentes non épinglées ; les sessions archivées résident dans la vue archivée de la page Sessions et conservent leurs transcriptions.
• Rêves : état de Dreaming, bascule activer/désactiver et lecteur du Journal des rêves (doctor.memory.status, doctor.memory.dreamDiary, config.patch).

• Tâches Cron : lister/ajouter/modifier/exécuter/activer/désactiver + historique d’exécution (cron.*).
• Skills : état, activation/désactivation, installation, mises à jour de clés d’API (skills.*).
• Nœuds : liste + capacités (node.list), créer des codes de configuration mobile et approuver l’association d’appareil (device.pair.*).
• Approbations exec : modifier les listes d’autorisation de gateway ou de nœud + stratégie de demande pour exec host=gateway/node (exec.approvals.*).

• Affichez/modifiez ~/.openclaw/openclaw.json (config.get, config.set).
• MCP dispose d’une page de paramètres dédiée aux serveurs configurés, à leur activation, aux récapitulatifs OAuth/filtre/parallèles, aux commandes opérateur courantes et à l’éditeur de configuration mcp limité au périmètre.
• Appliquez + redémarrez avec validation (config.apply) et réveillez la dernière session active.
• Les écritures incluent une protection par hachage de base pour éviter d’écraser des modifications concurrentes.
• Les écritures (config.set/config.apply/config.patch) précontrôlent la résolution des SecretRef actifs pour les références dans la charge utile de configuration soumise ; les références soumises actives non résolues sont rejetées avant l’écriture.
• Les enregistrements de formulaire écartent les espaces réservés caviardés obsolètes qui ne peuvent pas être restaurés depuis la configuration enregistrée, tout en préservant les valeurs caviardées qui correspondent encore à des secrets enregistrés.
• Rendu du schéma + formulaire (config.schema / config.schema.lookup, y compris les champs title / description, les indications d’interface correspondantes, les résumés d’enfants immédiats, les métadonnées de documentation sur les nœuds imbriqués objet/joker/tableau/composition, ainsi que les schémas de plugin + canal lorsqu’ils sont disponibles) ; l’éditeur JSON brut n’est disponible que lorsque l’instantané permet un aller-retour brut sûr.
• Si un instantané ne peut pas faire un aller-retour sûr avec du texte brut, Control UI force le mode Formulaire et désactive le mode Brut pour cet instantané.
• Dans l’éditeur JSON brut, « Réinitialiser aux valeurs enregistrées » préserve la forme rédigée en brut (mise en forme, commentaires, disposition $include) au lieu de restituer un instantané aplati, de sorte que les modifications externes survivent à une réinitialisation lorsque l’instantané peut effectuer un aller-retour sûr.
• Les valeurs d’objet SecretRef structurées sont affichées en lecture seule dans les champs texte du formulaire afin d’éviter une corruption accidentelle d’objet en chaîne.

• Débogage : instantanés status/health/models + journal d’événements + appels RPC manuels (status, health, models.list).
• Le journal d’événements inclut les minutages de rafraîchissement/RPC de Control UI, les minutages de rendu lent de chat/configuration et les entrées de 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 filtre/export (logs.tail).
• Mise à jour : exécutez une mise à jour package/git + redémarrage (update.run) avec un rapport de redémarrage, puis interrogez update.status après reconnexion pour vérifier la version du Gateway en cours d’exécution.

• Pour les tâches isolées, la livraison utilise par défaut l’annonce du récapitulatif. Vous pouvez passer à aucune si vous voulez des exécutions uniquement internes.
• Les champs canal/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 session principale, les modes de livraison webhook et aucune sont disponibles.
• Les contrôles d’édition avancés incluent la suppression après exécution, l’effacement du remplacement d’agent, les options cron exactes/échelonnées, les remplacements de modèle/réflexion d’agent et les bascules de livraison au mieux.
• La validation du formulaire est en ligne avec des erreurs au niveau des champs ; les valeurs non valides désactivent le bouton d’enregistrement jusqu’à 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.
• Repli obsolète : exécutez openclaw doctor --fix pour migrer les tâches héritées stockées avec notify: true de cron.webhook vers une livraison webhook ou d’achèvement explicite par tâche.

• chat.send est non bloquant : il accuse réception immédiatement avec { runId, status: "started" } et la réponse est diffusée via les événements chat. Les clients Control UI de confiance peuvent aussi recevoir des métadonnées facultatives de minutage d’ACK pour les diagnostics locaux.
• Les téléversements de chat acceptent les images ainsi que les fichiers non vidéo. Les images conservent le chemin d’image natif ; les autres fichiers sont stockés comme médias gérés et affichés dans l’historique comme liens de pièces jointes.
• Un nouvel envoi avec le même idempotencyKey renvoie { status: "in_flight" } pendant l’exécution, puis { status: "ok" } après l’achèvement.
• Les réponses chat.history sont limitées en taille pour la sécurité de l’interface. Lorsque les entrées de transcription sont trop volumineuses, Gateway peut tronquer les longs champs 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 transcription normalisée pour l’affichage via chat.message.get au moyen de sessionKey, de l’agentId actif si nécessaire, et du messageId de transcription. Si Gateway ne peut toujours pas renvoyer davantage, le lecteur affiche un état explicitement indisponible au lieu de répéter silencieusement l’aperçu tronqué.
• Les images d’assistant/générées sont conservées comme références de médias gérés et resservies via des URL de médias Gateway authentifiées, de sorte que les rechargements ne dépendent pas du maintien des charges utiles d’image base64 brutes dans la réponse d’historique du chat.
• Lors du rendu de chat.history, Control UI supprime du texte visible de l’assistant les balises de directives en ligne uniquement destinées à l’affichage (par exemple [[reply_to_*]] et [[audio_as_voice]]), les charges utiles XML d’appels d’outils en texte brut (y compris <tool_call>...</tool_call>, <function_call>...</function_call>, <tool_calls>...</tool_calls>, <function_calls>...</function_calls> et les blocs d’appels d’outils tronqués), ainsi que les jetons de contrôle de modèle ASCII/pleine chasse divulgués, et omet les entrées d’assistant dont tout le texte visible est uniquement le jeton silencieux exact NO_REPLY / no_reply ou le jeton d’accusé de réception Heartbeat HEARTBEAT_OK.
• Pendant un envoi actif et le rafraîchissement final de l’historique, la vue de chat garde visibles les messages utilisateur/assistant optimistes locaux si chat.history renvoie brièvement un instantané plus ancien ; la transcription canonique remplace ces messages locaux une fois que l’historique Gateway a rattrapé son retard.
• Les événements chat en direct représentent l’état de livraison, tandis que chat.history est reconstruit depuis la transcription durable de la session. Après les événements finaux d’outil, Control UI recharge l’historique et ne fusionne qu’une petite fin optimiste ; la limite de transcription est documentée dans WebChat.
• chat.inject ajoute une note d’assistant à la transcription de session et diffuse un événement chat pour les mises à jour uniquement d’interface (pas d’exécution d’agent, pas de livraison de canal).
• La barre latérale liste les sessions récentes avec une action Nouvelle session, un lien Toutes les sessions et un bouton de recherche de session qui ouvre le sélecteur complet de sessions (limité au périmètre de l’agent sélectionné, avec recherche et pagination). Le changement d’agent n’affiche que les sessions liées à cet agent et revient à la session principale de cet agent lorsqu’il n’a encore aucune session de tableau de bord enregistrée.
• Chaque ligne du sélecteur de sessions peut renommer, épingler ou archiver la session. Une exécution active et la session principale d’un agent ne peuvent pas être archivées. L’archivage de la session actuellement sélectionnée fait revenir Chat à la session principale de cet agent.
• Sur les largeurs de bureau, les contrôles de chat restent sur une ligne compacte et se replient lors du défilement vers le bas de la transcription ; le défilement vers le haut, le retour en haut ou l’arrivée en bas restaure les contrôles.
• Les messages texte seuls consécutifs en double sont rendus comme une seule bulle avec un badge de nombre. Les messages qui transportent des images, des pièces jointes, une sortie d’outil ou des aperçus de canevas ne sont pas regroupés.
• Les sélecteurs de modèle et de réflexion de l’en-tête du chat corrigent immédiatement la session active via sessions.patch ; ce sont des remplacements de session persistants, et non des options d’envoi limitées à un seul tour.
• Si vous envoyez un message pendant qu’une modification du sélecteur de modèle pour la même session est encore en cours d’enregistrement, le composeur attend la correction de cette session avant d’appeler chat.send afin que l’envoi utilise le modèle sélectionné.
• Saisir /new dans Control UI crée et bascule vers la même nouvelle session de tableau de bord que Nouveau chat, sauf lorsque session.dmScope: "main" est configuré et que le parent actuel est la session principale de l’agent ; dans ce cas, cela réinitialise la session principale sur place. Saisir /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 de modèles configurée par Gateway. Si agents.defaults.models est présent, cette liste d’autorisation pilote le sélecteur, y compris les entrées provider/* qui gardent dynamiques les catalogues limités au fournisseur. Sinon, le sélecteur affiche les entrées explicites models.providers.*.models ainsi que les fournisseurs disposant d’une authentification utilisable. Le catalogue complet reste disponible via la RPC de débogage models.list avec view: "all".
• Lorsque de nouveaux rapports d’utilisation de session Gateway incluent les jetons de contexte actuels, la barre d’outils du composeur de chat affiche un petit anneau d’utilisation du contexte avec le pourcentage utilisé ; le détail complet des jetons figure dans son info-bulle. L’anneau passe en 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 chemin normal de Compaction de session. Les instantanés de jetons obsolètes sont masqués jusqu’à ce que Gateway signale à nouveau une utilisation à jour.

Le mode parole utilise un fournisseur vocal temps réel enregistré. Configurez OpenAI avec talk.realtime.provider: "openai" plus un profil d’authentification par clé API openai, talk.realtime.providers.openai.apiKey ou OPENAI_API_KEY ; les profils OAuth OpenAI ne configurent pas la voix temps réel. Configurez Google avec talk.realtime.provider: "google" plus talk.realtime.providers.google.apiKey. Le navigateur ne reçoit jamais de clé API de fournisseur standard. OpenAI reçoit un secret client Realtime éphémère pour WebRTC. Google Live reçoit un jeton d’authentification Live API contraint à usage unique pour une session WebSocket de navigateur, avec les instructions et les déclarations d’outils verrouillées dans le jeton par Gateway. Les fournisseurs qui n’exposent qu’un pont temps réel backend passent par le transport relais Gateway, de sorte que les identifiants et les sockets fournisseur restent côté serveur pendant que l’audio du navigateur passe par des RPC Gateway authentifiées. L’invite de session Realtime est assemblée par Gateway ; talk.client.create n’accepte pas les remplacements d’instructions fournis par l’appelant.

Le composeur de Chat inclut un bouton d’options Talk à côté du bouton de démarrage/arrêt Talk. Les options s’appliquent à la prochaine session Talk et peuvent remplacer le fournisseur, le transport, le modèle, la voix, l’effort de raisonnement, le seuil VAD, la durée de silence et le padding de préfixe. Lorsqu’une option est vide, le Gateway utilise les valeurs par défaut configurées lorsqu’elles sont disponibles, ou la valeur par défaut du fournisseur. Sélectionner le relais Gateway force le chemin de relais backend ; sélectionner WebRTC garde la session sous contrôle du client et échoue au lieu de basculer silencieusement vers le relais si le fournisseur ne peut pas créer de session navigateur.

Dans le composeur de Chat, le contrôle Talk est le bouton en forme d’ondes à côté du bouton de dictée au microphone. Au démarrage de Talk, la ligne d’état du composeur affiche Connecting Talk..., puis Talk live pendant que l’audio est connecté, ou Asking OpenClaw... pendant qu’un appel d’outil en temps réel consulte le modèle plus grand configuré via talk.client.toolCall.

Smoke live mainteneur : OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts vérifie le pont WebSocket backend OpenAI, l’échange SDP WebRTC navigateur OpenAI, la configuration WebSocket navigateur Google Live à jetons contraints, et l’adaptateur navigateur de relais Gateway avec un média de microphone factice. La commande affiche uniquement l’état du fournisseur et ne journalise pas les secrets.

• Cliquez sur Stop (appelle chat.abort).
• Lorsqu’une exécution est active, les suivis normaux sont mis en file d’attente. Cliquez sur Steer sur un message en file d’attente pour injecter ce suivi dans le tour en cours d’exécution.
• Saisissez /stop (ou des phrases d’abandon autonomes comme stop, stop action, stop run, stop openclaw, please stop) pour abandonner hors bande.
• chat.abort prend en charge { sessionKey } (sans runId) pour 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.
• Gateway conserve le texte partiel abandonné de l’assistant dans l’historique de transcript 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 transcript puissent distinguer les fragments partiels abandonnés de la sortie de fin normale.

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

allowInsecureAuth est uniquement un bouton d’activation de compatibilité locale :

• Il permet aux sessions Control UI localhost de continuer sans identité d’appareil dans des contextes HTTP non sécurisés.
• Il ne contourne pas les vérifications d’appairage.
• Il n’assouplit pas les exigences d’identité d’appareil distant (non-localhost).

• Une authentification trusted-proxy réussie peut admettre des sessions Control UI opérateur sans identité d’appareil.
• Cela ne s’étend pas aux sessions Control UI de rôle nœud.
• Les proxys inverses loopback sur le même hôte ne satisfont toujours pas l’authentification trusted-proxy ; voir Authentification par proxy de confiance.

• gatewayUrl est stocké 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 en URL la valeur gatewayUrl afin que le navigateur analyse correctement la chaîne de requête.
• token doit être transmis via le fragment d’URL (#token=...) chaque fois que possible. Les fragments ne sont pas envoyés au serveur, ce qui évite les fuites dans les journaux de requêtes et le Referer. Les anciens paramètres de requête ?token= sont encore importés une seule fois pour compatibilité, mais uniquement comme solution de repli, et sont supprimés immédiatement après l’amorçage.
• password est conservé uniquement en mémoire.
• Lorsque gatewayUrl est défini, l’interface utilisateur ne se rabat pas sur les identifiants de configuration ou d’environnement. Fournissez explicitement token (ou password). L’absence d’identifiants explicites est une erreur.
• Utilisez wss:// lorsque le Gateway est derrière TLS (Tailscale Serve, proxy HTTPS, etc.).
• gatewayUrl n’est accepté que dans une fenêtre de premier niveau (non intégrée) afin d’empêcher le clickjacking.
• Les déploiements Control UI publics non-loopback doivent définir explicitement gateway.controlUi.allowedOrigins (origines complètes). Les chargements privés de LAN/Tailnet de même origine depuis loopback, RFC1918/link-local, .local, .ts.net ou des hôtes Tailscale CGNAT sont acceptés sans activer la solution de repli par 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> depuis le bind et le port d’exécution effectifs, mais les origines de 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 « correspondre à l’hôte que j’utilise ».
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true active le mode de solution de repli d’origine par en-tête Host, mais il s’agit d’un mode de sécurité dangereux.