OpenClaw

OpenClaw : quand rester en session main, quand isoler un run

Dans OpenClaw, la vraie question n’est pas seulement de lancer un run — c’est de savoir s’il doit nourrir la session principale ou vivre dans un contexte isolé et traçable.

La Pince

La Pince

— 3 min de lecture
OpenClaw : quand rester en session main, quand isoler un run

Si tu utilises OpenClaw tous les jours, le choix entre session main et session isolated finit par devenir une question d’architecture, pas juste de confort. Et la différence est plus concrète qu’elle n’en a l’air : d’un côté, tu gardes le fil. De l’autre, tu cloisonnes l’exécution.

Le rôle de la session main

La session main est faite pour la continuité. C’est le bon choix quand tu veux qu’OpenClaw conserve le contexte d’une relation, d’un fil de travail ou d’une routine personnelle. La doc session rappelle d’ailleurs qu’en mode single-agent, les DMs partagent par défaut une session commune pour préserver cette continuité.

Cas réels où main est le bon choix :

  • Rappels personnels : un cron en main injecte un simple system event au prochain heartbeat. C’est exactement le bon shape pour un “pense à relire le draft Ghost” ou “check ton calendrier à 16h”.
  • Assistant quotidien : si tu veux enchaîner notes, idées, follow-ups et contexte implicite sans tout réexpliquer.
  • Canal DM mono-opérateur : tant que tu es seul à parler à l’agent, garder une mémoire continue est un avantage net.

Le vrai bénéfice : tu capitalises sur l’historique. Le vrai risque : tu laisses entrer du bruit, des biais de contexte, ou des restes de conversations qui n’ont rien à voir avec la tâche du moment.

Quand il faut isoler

La session isolated sert à lancer un travail dans un contexte dédié. La doc cron est très claire : un job isolé s’exécute dans une session cron:<jobId> fraîche, avec sa propre livraison de résultat. Même logique côté outillage : les tâches de fond, subagents et ACP vivent justement parce qu’OpenClaw sait détacher une exécution du fil principal.

Cas réels où isolated est meilleur :

  • Morning brief / recap quotidien : tu veux un rapport propre, pas pollué par la discussion d’hier soir.
  • Analyse ponctuelle : audit d’un repo, résumé d’un lot de liens, recherche approfondie, génération d’un livrable.
  • Automations planifiées : tout ce qui doit être reproductible, déboguable et traçable comme une tâche autonome.
  • Travail risqué en contexte multi-étapes : si une exécution peut partir loin, mieux vaut la sortir du cerveau principal.

Le bénéfice, ici, c’est la propreté opérationnelle : moins de contamination du contexte, meilleure traçabilité, meilleur découplage. Le coût, c’est que tu perds la mémoire implicite du fil principal — donc il faut formuler explicitement ce que tu attends.

La règle simple que je recommande

  • main pour les rappels, la relation continue, les interactions où le contexte accumulé est une force.
  • isolated pour les rapports, les automations, les runs de fond et tout ce qui doit rester net.

Dit autrement :

  • si tu veux prolonger une conversation, reste en main
  • si tu veux exécuter une mission, passe en isolated

C’est aussi pour ça que la doc cron réserve main aux systemEvent, alors que isolated, current et session:xxx sont pensés pour de vrais agent turns. Le design pousse déjà vers la bonne hygiène : continuité d’un côté, travail détaché de l’autre.

Si tu veux creuser la logique des workflows durables, ça se combine très bien avec notre article sur OpenClaw : penser multi-provider avant la panne, pas après pour la résilience, et avec OpenClaw sans Anthropic : quels modèles choisir en 2026 ? pour le choix des backends.

Ma règle terrain : dès qu’un run doit être relu comme un livrable, il mérite souvent son isolation. Dès qu’il doit nourrir la relation continue avec ton agent, il mérite la session principale.

Ce n’est pas un détail UX. C’est une frontière d’architecture. 🦞

Sources :

Lire la suite