Reprendre une session OpenClaw

Vous avez commencé la conversation dans l’interface de contrôle OpenClaw, la réponse est à moitié utile, et la suite réclame votre terminal et vos fichiers. Coller la transcription dans un nouveau chat jette la session, ses métadonnées de routage et tout ce qui tourne encore dedans. La réponse d’OpenClaw est que la conversation ne bouge jamais : le terminal, un client mobile et un harnais de code se rattachent tous à la session que la passerelle possède déjà. Voici comment se passe ce relais, ce que signifient les liens courts de ces URL, et la règle d’identifiants qui surprend tout le monde.

Ce qui est réellement partagé

• La passerelle conserve l’état de session partagé, et l’interface de contrôle, les clients mobiles, ACP, openclaw tui et openclaw attach projettent cet état au lieu d’en garder des copies indépendantes. C’est ce qui permet d’ouvrir une même session dans plusieurs clients sans exporter ni copier sa transcription.
• Utilisez openclaw tui pour continuer la conversation dans un terminal. Utilisez openclaw attach pour placer un harnais de code à côté de la session, avec une autorisation MCP temporaire limitée à cette seule session.
• Le mode local embarqué est autre chose : openclaw tui --local, openclaw chat et openclaw terminal utilisent le runtime d’agent local et n’acceptent aucune cible de session. Si la conversation que vous visez vit sur une passerelle, ces commandes n’y mènent pas.
• Un nœud mobile reste un périphérique connecté à la passerelle et ne devient pas un second propriétaire de session. La plupart des clés de session d’agent joignent trois parties par des deux-points, le littéral agent, l’identifiant de l’agent et un segment final, où cette fin peut être un simple nom, plusieurs segments de routage séparés par des deux-points, ou une valeur se terminant par un UUID.

La passerelle possède les lignes de session, l’historique des transcriptions, les métadonnées de routage et les exécutions actives.

Un seul propriétaire, plusieurs vues

Les clients choisissent une clé de session puis lisent ou modifient ce même état via le protocole de la passerelle : il n’y a donc rien à synchroniser entre eux, ni seconde copie qui dérive. Une passerelle configurée en portée de session globale utilise à la place la session canonique globale, et quand une URL ne désignant qu’un agent est ouverte sur une telle passerelle, la CLI lui demande sa portée de session et résout l’URL vers cette session canonique. Collez une URL de session complète à la racine de la CLI et le TUI s’ouvre sur la clé de session canonique renvoyée par la passerelle : il ne clone pas la transcription et ne crée pas de nouvelle session. Une clé introuvable donne des indications de récupération plutôt qu’une session vide, et les contrôles d’accès de la session s’appliquent toujours à qui a collé le lien.

Les trois syntaxes de cible

• Une URL complète de l’interface de contrôle, par exemple https://claw.example.com/dashboard/main/deploy-monitor-6db92d48. Une URL ou un raccourci de passerelle sélectionne de façon autoritaire une seule origine de passerelle normalisée.
• Un raccourci de passerelle, la forme compacte hôte, agent et référence, par exemple claw.example.com/main/deploy-monitor-6db92d48.
• Une référence courte nue ou une clé complète, par exemple deploy-monitor-6db92d48 ou agent:main:telegram:12345. Les références nues utilisent la passerelle configurée ou celle par défaut, sans en choisir une elles-mêmes.

La référence courte n’est pas un surnom. Pour une clé dont la fin se termine par un UUID, la forme courte partageable prend 8 à 32 caractères hexadécimaux minuscules au début de cet UUID, tirets retirés, et c’est cet identifiant court qui fait autorité ; le slug du nom affiché est décoratif, sauf si deux sessions partagent le même préfixe, auquel cas une correspondance exacte de slug tranche. Pour les cibles de lien court en CLI, le segment d’agent est lui aussi décoratif, car la passerelle résout l’identifiant court sans le restreindre à l’agent nommé dans l’URL. La résolution appartient à la méthode sessions.resolve de la passerelle, qui couvre les clés exactes, les identifiants de session bruts, les libellés et les identifiants courts, filtre les sélecteurs de découverte selon la visibilité de session du client appelant, et renvoie au plus dix candidats récents quand un identifiant court est ambigu, afin que le client vous demande un préfixe plus long au lieu de deviner. Une exigence traverse tout cela : les liens courts réclament une passerelle à jour, et une passerelle ancienne ou personnalisée qui refuse le sélecteur shortId vous oblige à copier la clé de session complète à la main. Pour la couche en dessous, Comment OpenClaw route les sessions explique comment un message entrant atterrit dans une session précise, et La passerelle OpenClaw expliquée explique le processus qui les possède.

Continuer dans le terminal, et ce que la commande ne transporte pas

Dans l’interface de contrôle, ouvrez le menu d’en-tête de la session et choisissez Continue in terminal. La boîte de dialogue copie une commande openclaw resume sans identifiants, portant un seul argument de relais opaque et versionné qui n’encode que la clé de session exacte qualifiée par l’agent et l’URL WebSocket de passerelle retenue, cette clé étant bornée à 512 caractères perçus par l’utilisateur. Son alphabet compatible URL n’exige aucun échappement de shell, si bien que la même ligne collée reste sûre dans les shells POSIX courants, dans PowerShell et dans cmd.exe. Ce qu’elle ne transporte pas, c’est l’autorisation, car les URL de session ne doivent pas contenir d’identifiants : lancez-la dans un profil CLI OpenClaw déjà configuré pour cette passerelle, puisque le terminal s’authentifie de son côté, et passez --token ou --password séparément lors du premier appairage avec une origine. Les URL de passerelle routées par requête ne peuvent pas produire cette commande sans identifiants, l’authentification de passerelle et la portée d’appareil stockée n’étant pas conscientes de la requête : utilisez alors une cible CLI authentifiée manuellement, ou configurez une URL de passerelle sans requête. Appairage et approbation des appareils couvre l’approbation de cette première connexion, après quoi les connexions suivantes vers la même origine peuvent utiliser le jeton d’appareil stocké. L’autre moitié, c’est openclaw attach : la passerelle résout d’abord la session, puis émet une autorisation temporaire limitée à celle-ci et lance le harnais de code avec une configuration MCP stricte, le jeton porteur voyage dans l’environnement du processus enfant plutôt que dans argv, et un lancement normal révoque l’autorisation à la sortie du harnais ; OpenClaw et Claude Code est l’outil à l’autre bout.

Sur Diali

Diali héberge OpenClaw, si bien que la passerelle propriétaire de ces lignes de session est la nôtre à maintenir en marche, pas la vôtre. Chaque client fait tourner son propre assistant, sa configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque version, et son état vit sur un volume persistant : la session ouverte la semaine dernière est donc toujours là pour être reprise aujourd’hui ; des instantanés quotidiens et une restauration en un clic sont disponibles grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali présente ce que comprend le runtime hébergé, et Tarifs Diali ce que coûtent les formules.

• La session reste sur la passerelle, seul le client change.
• L’identifiant court fait l’identité, le slug n’est qu’un décor.
• Appairez le terminal avec l’origine avant que la commande copiée fonctionne.