OpenClaw 2.0: Funktionen, Migration und Sicherheitsgrenzen

Was ist OpenClaw 2.0?

OpenClaw ist ein quelloffenes Gateway, das KI-Modelle mit Messaging-Kanälen, Geräten, Dateien und Werkzeugen verbindet. Nutzer greifen unter anderem über Browser, Terminal oder Messenger auf Agenten und laufende Sessions zu. Die Version `v2026.8.1` trägt offiziell den Zusatz „AKA OpenClaw 2.0“.

Der stabile GitHub-Release erschien am 31. August 2026 um 03:30:51 UTC und verweist auf den getaggten Commit `ea806575e6450e4d1efdfc72c19f04be982a1b9b`. Der Release war zum Recherchezeitpunkt nicht als Prerelease markiert. Der getaggte Paketstand nennt Version `2026.8.1`, MIT-Lizenz und pnpm 12.1.0.

Kerndatum	Stand
Release	`v2026.8.1`, offiziell OpenClaw 2.0
Veröffentlichung	31.08.2026, 03:30:51 UTC
Hauptsprache	TypeScript
Lizenz	MIT laut `package.json` des Tags und npm
Node.js	`>=22.22.3 <23`, `>=24.15.0 <25` oder `>=25.9.0`
GitHub-Stars	388.206 am 31.08.2026, dynamischer Wert
Preis	Quellcode kostenlos unter MIT; Modelle, Hosting, Cloud Worker und Drittanbieter können separate Kosten verursachen

Wichtig bei der Lizenzangabe: Die GitHub-API führte das Repository zum Snapshot auf Repository-Ebene als `NOASSERTION`. Das getaggte `package.json` und das npm-Paket weisen dagegen MIT aus. Deshalb ist „Code und Paket laut Tag und npm unter MIT“ präziser als eine pauschale Aussage über die GitHub-Lizenzerkennung.

Was ändert OpenClaw 2.0 wirklich?

Die auffälligste Änderung ist nicht ein neues Basismodell, sondern eine breitere Control Plane. OpenClaw verknüpft Browser, entfernte Ausführungsorte, Teamzugriffe, Credentials, Sessions und Memory enger miteinander.

Funktion	Was v2026.8.1 dokumentiert	Kritische Einordnung
Control UI	Chat-orientierte Browser-Oberfläche für Sessions, Dateien, Freigaben, Einstellungen und laufende Arbeit	Bessere Bedienbarkeit, aber kein Beleg für bessere Agentenentscheidungen
Cloud Sessions	Ausführung auf Gateway, gepaarten Geräten oder kurzlebigen Cloud Workern	Remote-Ausführung erweitert die Betriebs- und Angriffsfläche
Shared Sessions und Teamrollen	Eigentümer, Sichtbarkeit, Teilnahme und benannte Rollen	Kollaborationskontrollen, keine harte Mandantentrennung
Shared Credential Store	Teambezogene Secrets und Environment-Werte in SQLite, Secret-Werte write-only, geschützter Egress an deklarierte Hosts	Reduziert einzelne Exfiltrationspfade, löst Prompt Injection nicht
Personal Conversation Recall	Begrenzter Abruf privater Konversationen desselben Agenten bei aktivem Memory	Gruppen und Channels ausgeschlossen; unabhängige Qualitätsmessung fehlt
Grounded Dreaming	Modellgestützte Memory-Konsolidierung mit Herkunftsbezug und Dream Diary, standardmäßig aktiv	Kann falsche oder unerwünschte Schlüsse dauerhaft verstetigen
Automatic Self-Learning	Wiederverwendbare Lessons und freigegebene Skills können automatisch übernommen werden	Zusätzliche Supply-Chain- und Governance-Fragen
Incognito Threads	Transkript und Kompaktierungszustand nur im Gateway-RAM bis zum Neustart, Memory Flush deaktiviert	Kein vollständiger Privatmodus für Provider, Logs oder Tool-Schreibzugriffe
Backups	Globale und agentenspezifische SQLite-Snapshots sowie verifizierte portable Backup-Archive	Ein SQLite-Snapshot deckt nicht automatisch jeden externen Zustand ab
Parallelität	CPU-skalierter Standard von 8 bis 16 gleichzeitigen Top-Level-Läufen	Kann API-Kosten, RAM-Bedarf und Rate-Limit-Druck erhöhen

Warum die Browser-Oberfläche mehr als ein neues Dashboard ist

Die Control UI wird direkt vom Gateway ausgeliefert und spricht über dessen WebSocket-Schnittstelle mit dem System. Laufende Arbeit, Freigaben, Sessions und Konfiguration rücken damit in eine gemeinsame Oberfläche. Für neue Nutzer ist das eine relevante Vereinfachung gegenüber einem primär terminalorientierten Einstieg.

Die offizielle Ankündigung beschreibt den Browser bewusst als zentralen Einstieg. Das ist Produktisierung: Ein vorhandenes Agentensystem wird leichter bedienbar, beobachtbar und konfigurierbar. Ob Nutzer damit zuverlässiger oder schneller arbeiten, ist wenige Stunden nach dem Release noch nicht unabhängig belegt.

Was Cloud Sessions technisch bedeuten

Bei Cloud Sessions bleibt das Gateway Eigentümer des kanonischen Transkripts, der Modell-Credentials, des abgeglichenen Workspace-Zustands und der Platzierungsdaten. Befehle, Dateiänderungen und andere Werkzeugschritte können dagegen auf einer gepaarten Maschine oder einem Cloud Worker laufen. Fällt die entfernte Maschine aus, bleibt der dauerhafte Session-Zustand am Gateway erhalten.

Diese Trennung ist sinnvoll, aber keine neue Sicherheitsdomäne. Der entfernte Ausführungsort verarbeitet zwangsläufig die für seine Aufgabe notwendigen Dateien, Befehle und Tool-Daten. Betreiber müssen deshalb Worker-Images, Netzwerkzugriffe, Workspace-Inhalte und Lebenszyklus genauso prüfen wie das Gateway selbst.

Warum ist OpenClaw 2.0 kein belegter Intelligenzsprung?

Die OpenClaw-Ankündigung nennt 933 Contributors, darunter 569 Erstbeitragende, und mehr als 16.000 Pull Requests. Das sind Herstellerangaben zum Umfang des Releases. Sie belegen weder Codequalität noch höhere Agentenintelligenz.

Die Größenordnung ist trotzdem relevant: Laut OpenClaw berührt das Update Installation, Messaging, Memory, Skills, Modelle, Automationen, Browser, native Apps, Plugins und Security. Genau diese Breite erhöht zugleich das Migrationsrisiko. Je mehr Zustandsformate, Plugins und Ausführungswege eine Installation nutzt, desto weniger aussagekräftig ist ein erfolgreicher Clean Install für ein bestehendes Produktivsystem.

Eine unabhängige Desk-Analyse von RuntimeWire bestätigt die strategische Verschiebung zu Browser und Teams, dokumentiert jedoch keinen eigenen Hands-on-Test. Im unmittelbaren Launchfenster fehlen belastbare unabhängige Daten zu:

• Upgrade-Erfolgsquoten über unterschiedliche Installationsarten,
• Stabilität längerer Cloud Sessions,
• Qualität und Fehlerquote des neuen Memory-Verhaltens,
• tatsächlichen Produktivitätsgewinnen,
• Plugin-Kompatibilität in stark angepassten Installationen.

Der korrekte Schluss lautet daher: OpenClaw 2.0 erweitert die Infrastruktur und Bedienoberfläche erheblich. Ob daraus praktisch bessere Ergebnisse entstehen, muss sich erst zeigen.

Wie funktionieren Memory, Dreaming und Self-Learning?

OpenClaw speichert Memory laut Memory-Dokumentation weiterhin in nachvollziehbaren Dateien im Agent-Workspace. Dazu gehören unter anderem `USER.md`, `MEMORY.md`, datierte Notizen unter `memory/` und optional `DREAMS.md`. Neu ist vor allem, wie das System vorhandene Gespräche und Beobachtungen automatisiert abruft, verdichtet und wiederverwendet.

Personal Conversation Recall

Bei aktivem Memory kann OpenClaw begrenzten Kontext aus privaten Konversationen desselben Agenten abrufen. Das gilt standardmäßig für persönliche Installationen ohne konfigurierte DM-Isolation. Gruppen und Channels sind ausgeschlossen, und die Funktion lässt sich abschalten.

Das reduziert Kontextverluste, vergrößert aber den Kreis älterer Informationen, die eine aktuelle Antwort beeinflussen können. Wer mehrere Rollen, Kunden oder sensible Projekte in einer Installation bearbeitet, sollte Quellenzuordnung und DM-Isolation nicht als Komfortoption behandeln.

Grounded Dreaming

Grounded Dreaming konsolidiert Memory im Hintergrund mit einem Modell. Die Release Notes nennen Herkunftsbezug, ein Dream Diary und eine explizite Abschaltmöglichkeit. In v2026.8.1 ist die Funktion standardmäßig aktiv.

„Grounded“ bedeutet hier nicht unfehlbar. Wenn ein Modell eine Beobachtung falsch zusammenfasst oder aus schwachen Signalen eine Regel ableitet, kann diese Aussage spätere Sessions beeinflussen. Der praktische Gegenentwurf ist klar: Dream Diary prüfen, Quellen aus Memory ausschließen und identifizierbare abgeleitete Erinnerungen über die dokumentierten Löschpfade entfernen.

Automatic Self-Learning

Automatic Self-Learning übernimmt starke wiederverwendbare Lessons sowie scanner-freigegebene oder vom Workshop verwaltete Skills standardmäßig automatisch. Änderungen an nutzereigenen Skills bleiben laut Release Notes zunächst ausstehend. Das ist ein sinnvoller Governance-Unterschied, aber kein Ersatz für die Prüfung von Skill-Herkunft, Berechtigungen und Änderungen.

Wo liegen die Sicherheitsgrenzen von OpenClaw 2.0?

Der wichtigste Satz der offiziellen Security-Dokumentation lautet sinngemäß: ein Gateway, eine Trust Boundary. Unterstützt werden ein einzelner Operator oder ein Team, dessen Mitglieder einander vertrauen. Gegenseitig nicht vertrauende oder adversariale Nutzer gehören nicht auf dasselbe Gateway.

Warum Multiplayer keine Multi-Tenancy ist

Teamrollen können festlegen, welche Agenten, Sessions und Operator-Funktionen ein verifizierter Nutzer erreichen darf. Shared Sessions begrenzen Sichtbarkeit und Teilnahme. Das sind wertvolle Zugriffskontrollen innerhalb eines Teams.

Sie bilden aber keine „hostile-tenant isolation“. Wenn externe Kunden, konkurrierende Teams oder nicht vertrauenswürdige Nutzer denselben Dienst verwenden sollen, brauchst du getrennte Gateways, getrennte Credentials und idealerweise getrennte Betriebssystem-Nutzer oder Hosts. Eine Rollenmatrix auf einem gemeinsamen Gateway ersetzt diese Isolation nicht.

Was die neue Credential-Verwaltung schützt

Der Shared Credential Store hält teambezogene Secret- und Environment-Einträge in SQLite. Secret-Werte sind write-only, und geschützter Egress kann an deklarierte Hosts gebunden werden. Der optionale 1Password-Broker arbeitet mit Service Account, Secret-Auswahl und Freigaben ohne den Wert im Audit zu protokollieren.

Die Grenze steht ebenfalls in den Release Notes: Liest ein Agenten-Tool ein ausgewähltes 1Password-Feld, kann dieser Wert dem Modell für genau diese Ausführung zugänglich werden. „Secrets gelangen nie an das Modell“ wäre deshalb falsch. Die neuen Kontrollen verkleinern den Blast Radius, sie entfernen den sensiblen Datenfluss nicht vollständig.

Warum Prompt Injection weiterhin offen bleibt

OpenClaw geht ausdrücklich davon aus, dass Modelle durch fremde Inhalte manipulierbar sind. Das Risiko kommt nicht nur aus offenen Direktnachrichten. Auch Webseiten, E-Mails, Dokumente, Anhänge, Logs und Tool-Ergebnisse können Anweisungen enthalten, die mit dem eigentlichen Nutzerauftrag kollidieren.

Sinnvolle Schutzschichten sind:

• DM-Pairing und Allowlists,
• getrennte DM-Kontexte bei mehreren Nutzern,
• minimale Tool- und Dateirechte,
• Sandboxing für riskante Werkzeuge,
• Browser, `exec` und Webzugriff nur bei tatsächlichem Bedarf,
• Reader-Agenten ohne Schreib- oder Ausführungsrechte für fremde Inhalte,
• Secrets weder im Prompt noch in frei erreichbaren Dateien,
• `openclaw security audit –deep` nach Änderungen.

Teamrollen, Secret Host Binding und Sandboxing begrenzen mögliche Folgen. Sie beweisen nicht, dass Prompt Injection gelöst ist.

Wie historische Sicherheitslücken einzuordnen sind

Die CVE-2026-25253 betraf OpenClaw-Versionen vor `2026.1.29`. Der von NVD gespiegelte MITRE-Datensatz beschreibt die ungefragte Verbindung zu einer manipulierten `gatewayUrl` und die Übertragung des Tokens; der OpenClaw-Advisory leitet daraus eine vollständige Gateway-Kompromittierung bis hin zu RCE ab. Der CVSS-Wert beträgt 8,8 (High). Das ist keine offene Schwachstelle von v2026.8.1.

Oasis Security dokumentierte im Februar 2026 eine weitere Website-to-Local-Agent-Angriffskette und nennt einen Fix innerhalb von 24 Stunden sowie Version `2026.2.25` oder neuer als Gegenmaßnahme. Auch dieser Fund betrifft eine frühere Version. Beide Fälle begründen konsequente Updates, minimale Rechte und vorsichtiges Gateway-Exposure, aber keine pauschale Behauptung, OpenClaw 2.0 sei verwundbar.

Welche Breaking Changes musst du vor dem Update prüfen?

v2026.8.1 enthält zwei direkte Migrationsänderungen und angekündigte Plugin-SDK-Umstellungen. Besonders stark angepasste Installationen sollten deshalb nicht ungeprüft über die bestehende Produktivinstanz aktualisiert werden.

OpenProse wurde aus dem Paket entfernt

Das gebündelte OpenProse-Plugin und der Befehl `/prose` wurden entfernt. Vorhandene `.prose`-Quelldateien bleiben erhalten. Der offizielle Migrationsweg beginnt mit:

openclaw doctor --fix

Der Doctor bereinigt veraltete Plugin-Einträge. Anschließend folgt die Migration zum Upstream Agent Skill. Die vorhandenen Quelldateien sind nicht automatisch ein lauffähiger Ersatz für das entfernte Plugin.

OpenAI-Routen werden vereinheitlicht

Alte Modellreferenzen unter `codex/*` und `openai-codex/*` werden zusammen mit Provider-Konfigurationen, gespeicherten Sessions und Automationsrouten auf `openai/*` migriert. Auch dafür ist `openclaw doctor –fix` der dokumentierte Reparaturweg.

Der Doctor markiert Konflikte für den Operator. Daraus folgt ausdrücklich nicht, dass jede individuelle Konfiguration automatisch und verlustfrei repariert wird. Prüfe nach der Migration insbesondere Modelle, Fallbacks, Automationen und gespeicherte Session-Routen.

Wie aktualisierst du OpenClaw sicher auf v2026.8.1?

Ein automatisches Konfigurationsbackup des Updaters ist kein vollständiger Wiederherstellungspunkt. Sichere deshalb Zustand und Konfiguration vor dem ersten Schreibzugriff. Die folgenden Befehle stammen aus der offiziellen Update- und Backup-Dokumentation.

1. Verifiziertes portables Backup erstellen

mkdir -p ~/Backups/openclaw
openclaw backup create --output ~/Backups/openclaw --verify

Backup-Archive können Credentials und Auth-Profile enthalten. Speichere sie nur mit Owner-only-Zugriff und prüfe, ob agentenspezifische Verzeichnisse außerhalb des üblichen State-Verzeichnisses enthalten sind.

Das Archiv ist kein bytegenaues Systemabbild: OpenClaw lässt dokumentierte flüchtige und regenerierbare Artefakte aus; externe Laufzeitabhängigkeiten und absichtlich ausgeschlossene Dateien müssen bei Bedarf separat gesichert werden.

2. Update ausführen

openclaw update

Der Updater erkennt npm-, pnpm-, Bun- oder Git-Installationen, lädt die Zielversion, führt `openclaw doctor` aus und startet das Gateway neu. Für Docker, Podman und Kubernetes gilt ein separater Container-Update-Pfad; die Befehle für eine Host-Installation solltest du nicht blind auf Container übertragen.

3. Migration und Diagnose ausführen

openclaw doctor --fix

Wenn du vor automatischen Reparaturen nur prüfen willst, verwende:

openclaw doctor

Kontrolliere die Ausgabe auf OpenProse-Reste, OpenAI-Routenkonflikte und externe Plugins. Bei einer stark angepassten Installation ist ein Test in Staging oder auf einem VM-Snapshot sicherer als ein direkter Produktivlauf.

4. Gateway, Health und Security prüfen

openclaw gateway restart
openclaw health
openclaw security audit --deep

Ein erfolgreicher Prozessstart reicht nicht. Prüfe zusätzlich die tatsächlich genutzten Channels, Modellrouten, Automationen, Session-Berechtigungen, Cloud Worker und Restore-Fähigkeit des Backups.

Für wen lohnt sich das OpenClaw-Update?

Zielgruppe	Empfehlung
Neue Nutzer	v2026.8.1 ist wegen Browser-Oberfläche und neuem Onboarding der logische Einstieg. Starte trotzdem mit minimalen Toolrechten.
Bestehende Standardinstallation	Backup erstellen, aktualisieren, `doctor –fix`, Health Check und Security Audit durchführen.
Stark angepasste Produktivinstallation	Zuerst in Staging oder auf einem Snapshot testen. Breaking Changes und Plugin-Kompatibilität einzeln prüfen.
Gegenseitig vertrauendes Team	Shared Sessions und Rollen sind sinnvoll, wenn Workspaces und Rechte klein bleiben.
Externe Kunden oder nicht vertrauende Nutzer	Nicht auf einem gemeinsamen Gateway betreiben. Separate Trust Boundaries aufbauen.
Feste, deterministische Automationen	Prüfen, ob n8n, Cron, CI oder ein kleines Skript einfacher und auditierbarer ist.

Die Empfehlung ist damit zweigeteilt: Für neue Installationen ist 2.0 die vernünftige Basis. Bei bestehenden produktiven Systemen ist das Update ebenfalls sinnvoll, aber nur mit getesteter Rückfallmöglichkeit und nicht als spontanes In-place-Experiment.

Wann ist OpenClaw die falsche Werkzeugklasse?

OpenClaw ist stark, wenn ein dauerhaft erreichbarer Agent über Browser, Messenger und Geräte hinweg arbeiten soll. Das bedeutet nicht, dass jede Automatisierung einen probabilistischen Agenten benötigt.

Bedarf	Eher passende Werkzeugklasse	Begründung
Persönlicher Agent über Messenger und Browser	OpenClaw	Fokus auf Präsenz, Channels, Routing und Gateway-Betrieb
Projektarbeit direkt an Dateien und im Terminal	Hermes, Codex oder Claude Code	Näher am Arbeitsverzeichnis, weniger umfassende Kommunikations-Control-Plane
Deterministische Geschäftsabläufe	n8n, CI, Cron oder klassische Workflow-Systeme	Reproduzierbarer und leichter zu auditieren
Nicht vertrauende Nutzer auf einer Plattform	Getrennte Gateways oder dedizierte Multi-Tenant-Infrastruktur	Ein OpenClaw-Gateway ist dafür ausdrücklich nicht ausgelegt

Wenn dein Schwerpunkt auf dateibasierter Agentenarbeit und Orchestrierung liegt, zeigt mein Guide zur Installation und Einrichtung von Hermes eine alternative Werkzeugklasse. Für die Steuerung eines Coding-Agenten über Messenger ordnet der Artikel zu Claude Code Channels über Telegram, Discord und Smartphone einen engeren Kommunikationsansatz ein.

Welche Einschränkungen hat die frühe Evidenz?

Der stabile Release war beim Research-Snapshot vom 31. August 2026 erst wenige Stunden verfügbar. Das reicht für eine Prüfung von Release Notes, getaggtem Quellstand und Dokumentation, aber nicht für belastbare Aussagen über langfristige Stabilität.

Frühe Threads auf Hacker News und Reddit liefern einzelne Praxissignale, jedoch keine repräsentative Stichprobe. Ein Reddit-Nutzer berichtete etwa von einem fehlgeschlagenen Upgrade, ohne reproduzierbare Diagnose. Daraus lässt sich weder eine allgemeine Fehlerquote noch ein Qualitätsurteil über v2026.8.1 ableiten.

Offen bleiben vor allem vier Punkte:

• Wie zuverlässig migrieren stark angepasste Installationen?
• Wie stabil laufen Cloud Sessions über längere Zeit und wechselnde Worker?
• Wie häufig erzeugen Dreaming und Self-Learning falsche oder unerwünschte Erinnerungen?
• Wie gut funktionieren Rollen und Shared Sessions in realen Teams mit komplexen Berechtigungen?

Diese Fragen benötigen unabhängige Hands-on-Tests und längere Betriebsdaten. Bis dahin ist „Stable Release“ ein Distributionsstatus, kein Beweis für störungsfreien Produktivbetrieb.

Quellen

Primärquellen

• OpenClaw 2.0, Accidentally, offizielle Ankündigung, abgerufen am 31.08.2026
• Release-Dokumentation v2026.8.1, abgerufen am 31.08.2026
• GitHub Release v2026.8.1, abgerufen am 31.08.2026
• Getaggter Quellstand v2026.8.1, abgerufen am 31.08.2026
• OpenClaw Security, abgerufen am 31.08.2026
• Cloud Sessions, abgerufen am 31.08.2026
• Team Setup, abgerufen am 31.08.2026
• Memory, abgerufen am 31.08.2026
• Control UI, abgerufen am 31.08.2026
• Updating, abgerufen am 31.08.2026
• Backups, abgerufen am 31.08.2026

Unabhängige Einordnung

• RuntimeWire: OpenClaw 2.0 rebuilds the personal agent for browsers and teams, Desk-Analyse, abgerufen am 31.08.2026
• NVD: CVE-2026-25253, historischer Sicherheitskontext, abgerufen am 31.08.2026
• Oasis Security: Website-to-Local Agent Takeover, frühere Version, abgerufen am 31.08.2026
• GitHub Blog: OpenClaw went viral, Maintainer- und Supply-Chain-Kontext, abgerufen am 31.08.2026

Frühe Community-Signale

• Hacker News zum Launch, nicht repräsentativ und überwiegend nicht 2.0-spezifisch
• Reddit-Launch-Thread, einzelner Upgrade-Bericht ohne reproduzierbare Diagnose

*Recherche- und Quellenstand: 31.08.2026. Dynamische Repository-Werte und frühe Community-Signale können sich nach diesem Snapshot ändern.*

FAQ: Häufig gestellte Fragen zu OpenClaw 2.0

Ist OpenClaw v2026.8.1 wirklich OpenClaw 2.0?

Ja. Die offizielle Release-Dokumentation bezeichnet `v2026.8.1` ausdrücklich als „AKA OpenClaw 2.0“. Der stabile Release erschien am 31. August 2026 um 03:30:51 UTC.

Ist OpenClaw 2.0 kostenlos?

Der getaggte Paketstand steht laut `package.json` unter MIT-Lizenz. Kosten können trotzdem für Modell-APIs, Abonnements, Server, Cloud Worker, Speicher und verbundene Drittanbieter entstehen.

Welche Node.js-Version braucht OpenClaw 2.0?

Der Tag v2026.8.1 verlangt Node.js `>=22.22.3 <23`, `>=24.15.0 <25` oder `>=25.9.0`. Die genaue Engine-Angabe steht im getaggten `package.json`.

Was macht `openclaw doctor –fix` beim Update?

Der Befehl führt dokumentierte Reparaturen und Migrationen aus. Für v2026.8.1 bereinigt er unter anderem veraltete OpenProse-Konfiguration und migriert unterstützte `codex/*`- beziehungsweise `openai-codex/*`-Routen auf `openai/*`. Konflikte können manuellen Eingriff erfordern.

Sind Shared Sessions mandantenfähig?

Nein, nicht für gegenseitig nicht vertrauende Nutzer. Laut Security-Dokumentation bildet ein Gateway eine Vertrauensdomäne; Rollen und Session-Berechtigungen sind Kollaborationskontrollen, keine hostile-tenant isolation.

Speichern Incognito Threads wirklich nichts?

Nein. Laut Release Notes verbleiben Transkript und Kompaktierungszustand bis zum Gateway-Neustart im RAM, während der Memory Flush ausbleibt. Provider-Verarbeitung, Diagnose-Logs und explizite Schreibvorgänge von Tools folgen weiterhin ihren eigenen Regeln.

Hat OpenClaw 2.0 Prompt Injection gelöst?

Nein. Rollen, Secret Binding, Audit und Sandboxing können die Schadenswirkung reduzieren. Webseiten, E-Mails, Dokumente und Tool-Ergebnisse bleiben potenziell manipulierbare Eingaben für das Modell.

Lohnt sich das Update für bestehende Installationen?

Ja, wenn du vorher ein verifiziertes Backup erstellst und die Migration kontrolliert testest. Bei stark angepassten Installationen solltest du v2026.8.1 zuerst in Staging oder auf einem Snapshot prüfen, statt direkt das Produktivsystem zu aktualisieren.

Fazit

OpenClaw 2.0 macht aus dem bisherigen Agenten-Gateway ein deutlich zugänglicheres Produkt für Browser, entfernte Sessions und vertrauensbasierte Teams. Der entscheidende Fortschritt liegt in Bedienung und Infrastruktur, nicht in unabhängig belegter höherer Intelligenz. Aktualisiere bestehende Installationen mit Backup, Migrationstest und Security Audit; trenne nicht vertrauende Nutzer konsequent auf eigene Gateways.

Weiterführend: Hermes KI Agent installieren und einrichten und Claude Code Channels über Telegram, Discord und Smartphone.