--- read_when: - Vous voulez comprendre le routage et l’isolation des sessions - Vous souhaitez configurer la portée des messages directs pour les configurations multi-utilisateurs - Vous déboguez des réinitialisations de session quotidiennes ou après inactivité summary: Comment OpenClaw gère les sessions de conversation title: Gestion des sessions x-i18n: generated_at: "2026-05-07T13:15:56Z" model: gpt-5.5 provider: openai source_hash: 4e5ec741a33262ce5c42caf021ad81892e89b3315db31ac7b141d5a13e8b22a2 source_path: concepts/session.md workflow: 16 --- OpenClaw organise les conversations en **sessions**. Chaque message est routé vers une session selon sa provenance : DM, discussions de groupe, tâches cron, etc. ## Comment les messages sont routés | Source | Comportement | | --------------- | ----------------------------- | | Messages directs | Session partagée par défaut | | Discussions de groupe | Isolée par groupe | | Salles/canaux | Isolée par salle | | Tâches cron | Nouvelle session à chaque exécution | | Webhooks | Isolée par hook | ## Isolation des DM Par défaut, tous les DM partagent une session pour assurer la continuité. Cela convient aux configurations mono-utilisateur. Si plusieurs personnes peuvent envoyer des messages à votre agent, activez l'isolation des DM. Sans cela, tous les utilisateurs partagent le même contexte de conversation : les messages privés d'Alice seraient visibles par Bob. **La correction :** ```json5 { session: { dmScope: "per-channel-peer", // isolate by channel + sender }, } ``` Autres options : - `main` (par défaut) -- tous les DM partagent une session. - `per-peer` -- isole par expéditeur (sur tous les canaux). - `per-channel-peer` -- isole par canal + expéditeur (recommandé). - `per-account-channel-peer` -- isole par compte + canal + expéditeur. Si la même personne vous contacte depuis plusieurs canaux, utilisez `session.identityLinks` pour lier ses identités afin qu'elles partagent une même session. ### Ancrer les canaux liés Les commandes d'ancrage permettent à un utilisateur de déplacer la route de réponse de la session de discussion directe actuelle vers un autre canal lié sans démarrer une nouvelle session. Consultez [Ancrage de canal](/fr/concepts/channel-docking) pour des exemples, la configuration et le dépannage. Vérifiez votre configuration avec `openclaw security audit`. ## Cycle de vie des sessions Les sessions sont réutilisées jusqu'à leur expiration : - **Réinitialisation quotidienne** (par défaut) -- nouvelle session à 4 h 00, heure locale, sur l'hôte du Gateway. La fraîcheur quotidienne est basée sur le moment où le `sessionId` actuel a démarré, et non sur les écritures de métadonnées ultérieures. - **Réinitialisation après inactivité** (facultative) -- nouvelle session après une période d'inactivité. Définissez `session.reset.idleMinutes`. La fraîcheur d'inactivité est basée sur la dernière interaction réelle utilisateur/canal, de sorte que les événements système heartbeat, cron et exec ne maintiennent pas la session active. - **Réinitialisation manuelle** -- saisissez `/new` ou `/reset` dans la discussion. `/new ` change aussi le modèle. Lorsque les réinitialisations quotidienne et après inactivité sont toutes deux configurées, la première qui expire l'emporte. Les tours Heartbeat, cron, exec et autres événements système peuvent écrire des métadonnées de session, mais ces écritures ne prolongent pas la fraîcheur des réinitialisations quotidienne ou après inactivité. Lorsqu'une réinitialisation fait basculer la session, les notifications d'événements système en file d'attente pour l'ancienne session sont supprimées afin que les mises à jour d'arrière-plan obsolètes ne soient pas ajoutées au début de la première invite de la nouvelle session. Les sessions avec une session CLI active appartenant au fournisseur ne sont pas interrompues par la valeur quotidienne implicite par défaut. Utilisez `/reset` ou configurez explicitement `session.reset` lorsque ces sessions doivent expirer selon un minuteur. ## Où réside l'état Tout l'état de session appartient au **Gateway**. Les clients d'interface interrogent le Gateway pour obtenir les données de session. - **Stockage :** `~/.openclaw/agents//sessions/sessions.json` - **Transcriptions :** `~/.openclaw/agents//sessions/.jsonl` `sessions.json` conserve des horodatages de cycle de vie distincts : - `sessionStartedAt` : moment où le `sessionId` actuel a commencé ; la réinitialisation quotidienne l'utilise. - `lastInteractionAt` : dernière interaction utilisateur/canal qui prolonge la durée d'inactivité. - `updatedAt` : dernière mutation de ligne du stockage ; utile pour l'affichage et l'élagage, mais pas faisant autorité pour la fraîcheur des réinitialisations quotidienne/après inactivité. Les anciennes lignes sans `sessionStartedAt` sont résolues à partir de l'en-tête de session JSONL de la transcription lorsqu'il est disponible. Si une ancienne ligne n'a pas non plus `lastInteractionAt`, la fraîcheur d'inactivité revient à l'heure de début de cette session, et non aux écritures comptables ultérieures. ## Maintenance des sessions OpenClaw borne automatiquement le stockage des sessions au fil du temps. Par défaut, il s'exécute en mode `warn` (signale ce qui serait nettoyé). Définissez `session.maintenance.mode` sur `"enforce"` pour un nettoyage automatique : ```json5 { session: { maintenance: { mode: "enforce", pruneAfter: "30d", maxEntries: 500, }, }, } ``` Pour les limites `maxEntries` de taille production, les écritures d'exécution du Gateway utilisent un petit tampon de seuil haut et nettoient par lots jusqu'au plafond configuré. Les lectures du stockage de sessions n'élaguent ni ne plafonnent les entrées au démarrage du Gateway. Cela évite d'exécuter un nettoyage complet du stockage à chaque démarrage ou session cron isolée. `openclaw sessions cleanup --enforce` applique le plafond immédiatement. La maintenance préserve les pointeurs durables vers des conversations externes, y compris les sessions de groupe et les sessions de discussion limitées à un fil, tout en permettant aux entrées synthétiques cron, hook, heartbeat, ACP et sous-agent de vieillir. Si vous utilisiez auparavant l'isolation des messages directs puis avez remis `session.dmScope` à `main`, prévisualisez les lignes de DM obsolètes indexées par pair avec `openclaw sessions cleanup --dry-run --fix-dm-scope`. L'application du même indicateur retire ces anciennes lignes de DM directs et conserve leurs transcriptions comme archives supprimées. Prévisualisez avec `openclaw sessions cleanup --dry-run`. ## Inspecter les sessions - `openclaw status` -- chemin du stockage de sessions et activité récente. - `openclaw sessions --json` -- toutes les sessions (filtrer avec `--active `). - `/status` dans la discussion -- utilisation du contexte, modèle et bascules. - `/context list` -- ce qui se trouve dans l'invite système. ## Pour aller plus loin - [Élagage de session](/fr/concepts/session-pruning) -- réduction des résultats d'outils - [Compaction](/fr/concepts/compaction) -- résumé des longues conversations - [Outils de session](/fr/concepts/session-tool) -- outils d'agent pour le travail intersessions - [Analyse approfondie de la gestion des sessions](/fr/reference/session-management-compaction) -- schéma de stockage, transcriptions, politique d'envoi, métadonnées d'origine et configuration avancée - [Multi-agent](/fr/concepts/multi-agent) — routage et isolation des sessions entre agents - [Tâches en arrière-plan](/fr/automation/tasks) — comment le travail détaché crée des enregistrements de tâches avec des références de session - [Routage de canal](/fr/channels/channel-routing) — comment les messages entrants sont routés vers les sessions ## Connexe - [Élagage de session](/fr/concepts/session-pruning) - [Outils de session](/fr/concepts/session-tool) - [File de commandes](/fr/concepts/queue)