Session Management in OpenClaw: So behält dein Agent den Überblick

Kennst du das Problem? Dein Agent chattet mit mehreren Personen gleichzeitig und plötzlich vermischt er die Kontexte. Ein Nutzer fragt nach etwas Privatem und der nächste erhält eine Antwort, die eigentlich nicht für ihn bestimmt war. Das Management von Sessions über verschiedene Plattformen hinweg ist oft chaotisch und führt schnell zu Fehlern.

Ohne eine klare Trennung der Gespräche riskierst du, dass private Informationen durchsickern. OpenClaw bietet dir eine strukturierte Lösung, um Sessions sauber zu verwalten, egal ob in Direct Messages (DMs) oder Gruppen-Chats.

Voraussetzungen

• Eine laufende OpenClaw Gateway Instanz
• Zugriff auf die Konfigurationsdatei ~/.openclaw/openclaw.json

Schnellstart

Um deinen Agent für mehrere Nutzer sicher zu machen, solltest du den Secure DM mode aktivieren. Damit verhinderst du, dass Nutzer den Gesprächsverlauf anderer einsehen können.

Ergänze deine Konfiguration in der ~/.openclaw/openclaw.json:

~/.openclaw/openclaw.json

{
  session: {
    // Secure DM mode: Isoliert den DM-Kontext pro Channel + Sender.
    dmScope: "per-channel-peer",
  },
}

Dieser Schritt sorgt dafür, dass jeder Nutzer eine eigene Session erhält, anstatt sich den main-Kontext mit allen anderen zu teilen.

Gateway ist die “Source of Truth”

In OpenClaw gehört der Session-Status allein dem Gateway. UI-Clients wie die macOS App oder der WebChat lesen keine lokalen Dateien aus, sondern fragen das Gateway nach Session-Listen und Token-Counts.

Wenn du im remote mode arbeitest, liegt der Session-Speicher auf dem Remote-Host des Gateways. Die in der UI angezeigten Token-Werte stammen direkt aus den Feldern des Gateway-Stores (inputTokens, outputTokens, totalTokens, contextTokens). Die Clients parsen keine JSONL-Transkripte, um Summen zu korrigieren.

Wo die Daten liegen

Alle Session-Daten werden auf dem Gateway-Host gespeichert:

• Store-Datei: ~/.openclaw/agents/<agentId>/sessions/sessions.json (pro Agent).
• Transkripte: ~/.openclaw/agents/<agentId>/sessions/<SessionId>.jsonl.

Der Store ist ein Map-Objekt (sessionKey -> { sessionId, updatedAt, ... }). Du kannst Einträge sicher löschen; sie werden bei Bedarf automatisch neu erstellt.

Session-Lifecycle und Resets

Sessions werden standardmäßig so lange wiederverwendet, bis sie ablaufen. Die Prüfung erfolgt bei der nächsten eingehenden Nachricht.

• Daily Reset: Standardmäßig um 4:00 Uhr morgens (Lokalzeit des Gateways).
• Idle Reset: Über idleMinutes kannst du ein Inaktivitätsfenster festlegen.
• Manuelle Trigger: Nachrichten wie /new oder /reset starten sofort eine frische Session.

Du kannst diese Regeln global oder pro Typ anpassen:

{
  session: {
    reset: {
      mode: "daily",
      atHour: 4,
      idleMinutes: 120,
    },
    resetByType: {
      thread: { mode: "daily", atHour: 4 },
      direct: { mode: "idle", idleMinutes: 240 },
    },
  },
}

Send Policy (Optional)

Du kannst die Auslieferung für bestimmte Session-Typen blockieren, ohne einzelne IDs auflisten zu müssen. Das ist nützlich, um zum Beispiel Nachrichten in Discord-Gruppen oder von Cron-Jobs zu unterbinden.

{
  session: {
    sendPolicy: {
      rules: [
        { action: "deny", match: { channel: "discord", chatType: "group" } },
        { action: "deny", match: { keyPrefix: "cron:" } },
      ],
      default: "allow",
    },
  },
}

Alles im Blick behalten

Nutze die CLI oder Chat-Befehle, um den Status deiner Sessions zu prüfen:

• openclaw status: Zeigt den Pfad zum Store und aktuelle Sessions.
• openclaw sessions --json: Gibt alle Einträge im JSON-Format aus.
• /status: Sende dies als Nachricht im Chat, um die Erreichbarkeit und Kontext-Nutzung zu sehen.
• /context list: Zeigt dir, was sich aktuell im System-Prompt und im Workspace befindet.

Fehlerbehebung

• Kontext-Leak zwischen Nutzern: Prüfe, ob dmScope auf main steht. Stelle es auf per-channel-peer um, falls mehrere Personen den Agent nutzen.
• Session wird nicht zurückgesetzt: Kontrolliere die Uhrzeit auf dem Gateway-Host. Der Daily Reset orientiert sich an der lokalen Systemzeit des Hosts.
• Veraltete Tool-Ergebnisse: OpenClaw entfernt standardmäßig alte Tool-Ergebnisse aus dem Memory-Kontext vor LLM-Aufrufen. Das ist normales Verhalten und verändert nicht die JSONL-Historie.
• Remote-Verbindung: Wenn die UI falsche Daten anzeigt, stelle sicher, dass sie mit dem richtigen Gateway verbunden ist. Die UI berechnet keine Token selbst.

Hast du Fragen zur Einrichtung? Nutze den AI Setup Assistant.

Nächste Schritte

• Security Guide
• Memory Concepts
• Session Pruning
• Compaction Details