Canal WebChat OpenClaw

WebChat communique avec le OpenClaw Gateway via une connexion WebSocket utilisant trois opérations principales : • chat.history — Récupérer l'historique de conversation depuis le Gateway • chat.send — Transmettre les messages utilisateur à l'assistant IA • chat.inject — Ajouter des notes de l'assistant directement aux transcriptions et les diffuser vers l'interface sans déclencher d'exécution de l'agent Contrairement aux autres canaux qui s'appuient sur des services externes et des webhooks, WebChat est entièrement natif au Gateway. Les messages ne quittent jamais votre infrastructure — la connexion WebSocket est directe entre le client UI et le processus Gateway. Le routage est déterministe : les réponses de l'IA reviennent toujours à la session WebChat qui a initié la conversation.

L'authentification est requise pour toutes les connexions WebChat, même en boucle locale (localhost). Cela empêche tout accès non autorisé à votre assistant IA. OpenClaw supporte deux modes d'authentification : • token — Un secret partagé transmis lors du handshake WebSocket. Idéal pour l'accès programmatique et les configurations mono-utilisateur. • password — Authentification par mot de passe. Adapté aux environnements multi-utilisateurs où chaque utilisateur possède ses propres identifiants. Au moins un des modes token ou password doit être configuré pour que WebChat accepte les connexions. Configurez-les dans les paramètres gateway.auth de votre openclaw.json.

{
  "gateway": {
    "auth": {
      "mode": "token",
      "token": "a-strong-random-token-here"
    }
  }
}

WebChat supporte la connectivité distante sans nécessiter de serveur web séparé. Deux approches sont recommandées : • Tunnel SSH — Redirigez le port du Gateway via SSH : ssh -L 3000:localhost:3000 user@remote-host. Cela vous permet d'accéder à WebChat localement tandis que le Gateway fonctionne sur une machine distante. • Tailscale — Connectez vos appareils via le VPN mesh de Tailscale. Le Gateway devient accessible à son adresse IP Tailscale sans redirection de port ni configuration de pare-feu. Pour les connexions distantes, configurez les paramètres gateway.remote avec l'URL WebSocket cible et les identifiants d'authentification. Le client natif gère automatiquement la reconnexion lors des changements de conditions réseau.

{
  "gateway": {
    "remote": {
      "url": "wss://your-remote-host:3000",
      "token": "YOUR_REMOTE_TOKEN"
    }
  }
}

WebChat utilise des sessions gérées par le Gateway pour maintenir le contexte de conversation. Chaque connexion WebChat est associée à une session qui stocke l'historique de conversation et le contexte IA. Les sessions sont persistantes entre les reconnexions — si le WebSocket se déconnecte et se reconnecte, la conversation reprend là où elle s'était arrêtée. L'opération chat.history récupère l'intégralité de la conversation depuis le Gateway lors de la reconnexion. La configuration des sessions est gérée via les paramètres session.* dans openclaw.json, incluant le backend de stockage et les clés de session par défaut.

Lorsque le Gateway devient injoignable, WebChat passe automatiquement en mode lecture seule. Dans cet état : • L'historique de conversation précédent reste visible • Les nouveaux messages ne peuvent pas être envoyés • L'interface indique le statut de déconnexion • Des tentatives de reconnexion automatique s'effectuent en arrière-plan Une fois le Gateway de nouveau en ligne, WebChat se reconnecte automatiquement et restaure l'ensemble des fonctionnalités. Aucun message n'est perdu dans l'historique de conversation puisque tout l'historique provient du Gateway.

WebChat est implémenté en tant qu'application SwiftUI native sur les plateformes Apple : • macOS — Expérience bureau complète avec raccourcis clavier, notifications système et intégration à la barre de menus • iOS — Interface optimisée pour mobile avec notifications push et rafraîchissement en arrière-plan L'implémentation native offre une expérience réactive et spécifique à la plateforme, sans la surcharge d'un navigateur embarqué ou d'un wrapper Electron. Le rendu du texte, le défilement et la gestion des entrées utilisent tous les composants natifs de la plateforme. Pour les autres plateformes (Windows, Linux, Android), accédez à WebChat via l'onglet chat de Control UI dans n'importe quel navigateur web moderne.

WebChat gère la distribution des messages via la connexion WebSocket avec un découpage configurable pour les longues réponses IA : • textChunkLimit — Nombre maximum de caractères par fragment de message (par défaut : 2000). Les réponses longues sont automatiquement découpées. • blockStreaming — Lorsqu'activé, les réponses sont envoyées par blocs au fur et à mesure de leur génération, offrant un retour en temps réel. Les messages sont distribués instantanément via le WebSocket — il n'y a ni polling ni délai de webhook. La connexion WebSocket bidirectionnelle permet l'envoi et la réception en temps réel.

{
  "channels": {
    "webchat": {
      "textChunkLimit": 2000,
      "blockStreaming": true
    }
  }
}

La sécurité de WebChat repose sur la couche d'authentification du Gateway. Suivez ces bonnes pratiques pour des déploiements sécurisés : • Toujours configurer l'authentification — Aucun accès anonyme n'est autorisé • Utiliser le chiffrement TLS — Connectez-vous via wss:// (WebSocket Secure) pour toutes les connexions distantes • Restreindre l'adresse de liaison — Utilisez gateway.bind: "127.0.0.1" pour un accès local uniquement ; évitez de lier à 0.0.0.0 sauf derrière un reverse proxy • Utiliser des identifiants forts — Générez des tokens aléatoires ou des mots de passe robustes • Reverse proxy — Pour les déploiements en production, placez le Gateway derrière un reverse proxy (nginx, Caddy) avec terminaison TLS Si vous utilisez un reverse proxy sur la même machine, configurez gateway.trustedProxies pour assurer la détection correcte de l'IP du client.