La Control UI d’OpenClaw

Vous avez installé OpenClaw, démarré la passerelle, et lu quelque part qu’il existe un tableau de bord dans le navigateur. L’ouvrir tient en une URL, mais la page affiche un champ Gateway secret que personne ne vous a remis, et l’adresse LAN imprimée dans le terminal ne répond parfois pas depuis votre portable. Voici ce qu’est vraiment la Control UI, ce que ce champ unique accepte, et ce que contient le répertoire d’agents derrière.

Ce que la passerelle sert sur le port 18789

• La Control UI est une petite application monopage Vite et Lit servie par la passerelle elle-même, à l’adresse http://your-host:18789/ par défaut, avec un préfixe facultatif si vous définissez gateway.controlUi.basePath, par exemple /openclaw. Elle parle directement au WebSocket de la passerelle sur le même port : aucun second service à démarrer, aucun hôte d’API distinct à renseigner.
• Sur l’hôte de la passerelle, ouvrez http://127.0.0.1:18789/ ou http://localhost:18789/. Si la page ne charge pas du tout, démarrez d’abord la passerelle avec openclaw gateway.
• gateway.controlUi.enabled s’applique à chaud. Désactivez-le et la passerelle cesse de servir les pages et les ressources du tableau de bord pendant que les bots et les connexions existantes continuent ; réactivez-le et le service reprend, les ressources manquantes étant préparées en arrière-plan. Changer le chemin de base servi ou la racine des ressources exige toujours un redémarrage de la passerelle.
• Si l’URL LAN fonctionne sur l’hôte mais pas depuis une autre machine, soupçonnez l’hôte avant le réseau. Sur les liaisons LAN natives de Windows, le Pare-feu Windows ou une Group Policy gérée par l’organisation peut bloquer l’URL LAN annoncée alors même que 127.0.0.1 fonctionne sur l’hôte de la passerelle, et openclaw gateway status --deep, lancé sur cet hôte Windows, signale les ports probablement bloqués, les profils incohérents et les règles de pare-feu locales que la stratégie peut ignorer.

Une connexion directe en loopback ne contourne pas l’authentification par jeton ou par mot de passe.

Pourquoi la page ouverte sur votre machine réclame quand même un secret

L’authentification se joue pendant la poignée de main WebSocket, pas dans un formulaire de connexion que l’application pourrait discrètement sauter pour les visiteurs locaux. La passerelle accepte le secret partagé configuré dans connect.params.auth.token ou dans connect.params.auth.password, gateway.auth.mode désignant la valeur configurée qui s’applique ; elle accepte aussi les en-têtes d’identité Tailscale Serve quand gateway.auth.allowTailscale vaut true, et les en-têtes d’identité de proxy de confiance quand gateway.auth.mode vaut trusted-proxy. L’authentification de la passerelle passe avant l’appairage des appareils : un navigateur prouve son identité avec le secret partagé avant même de pouvoir déposer une demande d’appairage. Un navigateur en loopback direct se passe de secret partagé uniquement quand gateway.auth.mode vaut explicitement none, ce qui désactive entièrement l’authentification de la passerelle et n’est pas la configuration recommandée pour la Control UI.

Un champ, deux types de valeur

• L’écran de connexion et Settings, puis Gateway, utilisent le même champ unique Gateway secret : collez le jeton ou saisissez le mot de passe. Le navigateur ne choisit pas le mode ; gateway.auth.mode l’a déjà choisi sur l’hôte.
• Après une connexion réussie, l’interface conserve le secret dans le stockage de session, limité à l’onglet courant et à l’origine de la passerelle, et seulement quand la passerelle annonce une authentification par jeton. Les mots de passe restent en mémoire et ne sont jamais persistés, et une fois l’appareil appairé, le navigateur peut utiliser son jeton par appareil lors des connexions suivantes.
• Un code de configuration copié depuis Devices, Pair device, Copy setup code est un identifiant différent. Collez-le dans Gateway secret et l’interface affiche une indication avant la connexion : ce code va dans Settings, puis Gateway, de l’application mobile OpenClaw, tandis que la Control UI attend le jeton partagé renvoyé par openclaw gateway auth-token --show, lancé dans un terminal interactif sur l’hôte de la passerelle.

Un état ressemble à un bogue sans en être un. L’intégration locale génère un Gateway secret en mode jeton par défaut, sans sélecteur jeton ou mot de passe, et préserve un mode mot de passe existant ; la mise en place explicite d’un mot de passe passe par --gateway-auth password ou --gateway-password suivi de la valeur choisie, et Tailscale Funnel exige le mode mot de passe. Mais si la passerelle démarre en mode jeton sans jeton configuré, elle génère à la place un jeton d’exécution éphémère pour ce processus. Ce jeton n’est pas écrit dans la configuration, il est donc irrécupérable, et un navigateur en loopback qui ne l’a pas est rejeté : le champ devant vous réclame une valeur que vous ne pouvez lire nulle part. La sortie consiste à lancer openclaw doctor --generate-gateway-token, à redémarrer la passerelle, puis à lancer openclaw gateway auth-token --show dans un terminal interactif et à coller le résultat dans Gateway secret ; le doctor d’OpenClaw détaille ce que cet outil de réparation peut toucher par ailleurs, et la passerelle expliquée décrit le processus qui possède ce port.

Le répertoire d’agents et le mode équipe

Ouvrez Agents dans la barre latérale, choisissez All agents dans le sélecteur d’agent, ou visitez /agents : vous obtenez un répertoire plutôt qu’une conversation, avec une carte par agent configuré montrant son identité, son modèle, son statut de travail actuel, sa dernière activité et un aperçu de sa conversation principale, les agents au travail en tête et les plus récemment actifs derrière. Open chat ouvre la session principale de cet agent, Manage agents ouvre /settings/agents, et New agent ouvre la conversation du custodian, qui recommande un chef de cabinet, un chercheur, un rédacteur, un relecteur, ou une petite équipe réunissant les quatre, à partir des mêmes modèles de rôle que la ligne de commande et en attendant l’approbation de l’opérateur avant toute création. Choisir Show all agents active le mode équipe : les sessions se regroupent sous des en-têtes d’agent repliables dans l’ordre du répertoire configuré, la rangée supérieure devient un en-tête d’espace de travail portant le nom d’affichage configuré de la passerelle, et la portée de page partagée bascule par défaut sur All agents, si bien qu’Automations, Dashboards, Sessions, Tasks et Usage affichent des lignes multi-agents avec l’identité de l’agent attachée. Le mode équipe est une préférence de navigateur, désactivée par défaut et mémorisée par passerelle dans ce navigateur : la même passerelle atteinte depuis un autre profil ou via l’accès distant à OpenClaw démarre en mode agent unique tant que vous ne l’activez pas là aussi. La façon dont plusieurs agents isolés cohabitent dans un seul processus de passerelle est un sujet en soi, traité dans plusieurs agents dans une seule passerelle.

Sur Diali

Diali héberge OpenClaw, si bien que le port, le jeton et le certificat cessent d’être votre affaire : chaque client fait tourner son propre assistant sur sa propre instance, et nous servons la Control UI en HTTPS sur une adresse réelle plutôt que sur une URL LAN en clair. La configuration d’exécution est générée depuis votre tableau de bord Diali et réécrite à chaque version, de sorte que ce qui tourne corresponde toujours à ce que vous avez choisi, et l’état de l’agent réside sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali décrit ce que comprend l’assistant hébergé, et Tarifs Diali présente les formules.

• Le tableau de bord est la passerelle elle-même, sur un seul port.
• Un navigateur en loopback réclame toujours le secret configuré.
• Un jeton d’exécution éphémère ne se relit jamais.