OpenClaw 2026.6.2-beta.1 ersetzt den alten Scanner-Pfad

Laut GitHub Release API hat OpenClaw Version 2026.6.2-beta.1 am 3. Juni 2026 als Prerelease veröffentlicht. Der wichtigste Punkt steht direkt in den Highlights der Release Notes: Plugin- und Skill-Installationen laufen nun über eine Operator-Install-Policy statt über den alten Dangerous-Code-Scanner-Pfad.

Das ist keine reine Packaging-Notiz. Es geht um die Frage, wer in einer Agenten-Runtime entscheidet, welcher fremde Code in einen Workspace darf. Ein Scanner kann auffällige Muster markieren. Eine Install-Policy zwingt die Entscheidung näher an den Betreiber, der Kontext, Quelle und Risiko des Pakets bewerten muss.

Was die Beta konkret belegt

Laut GitHub Release API trägt der Release den Tag v2026.6.2-beta.1, den Namen openclaw 2026.6.2-beta.1 und ist als prerelease: true markiert. Veröffentlicht wurde er am 3. Juni 2026 um 23:46:41 UTC; aktualisiert wurde der Release-Eintrag am 4. Juni 2026 um 00:37:39 UTC.

Der Release nennt für die Änderung ausdrücklich Paket-, Archiv-, Source-, Upload- und Marketplace-Installationen. Außerdem sollen Doctor, CLI, ClawHub und Troubleshooting klarer anzeigen, was passiert. In den Changes taucht derselbe Punkt noch einmal als Plugins/security auf: Dangerous-Code-Scanner-Enforcement wird durch Operator-Install-Policy, Install-Policy-Kontext, Doctor-Checks, Install-/Update-CLI-Wiring, ClawHub-Metadatenpfade und Lifecycle-Abdeckung ersetzt.

Damit behandelt OpenClaw Erweiterungen stärker als Betreiberentscheidung und nicht nur als Scanner-Problem. Der Installationspfad wird selbst zum Teil der Sicherheitsarchitektur: Er muss erklären, welche Quelle erlaubt ist, welche Regel greift und welche Entscheidung beim Operator liegt.

Installationen brauchen eine überprüfbare Entscheidung

Für Agenten-Builder ist die Änderung vor allem deshalb relevant, weil Plugins und Skills keine passiven Inhalte sind. Sie erweitern, wie ein Agent Werkzeuge nutzt, Dateien interpretiert oder externe Systeme anspricht. Ein Scanner kann auffällige Muster finden, aber er beantwortet nicht automatisch die operative Frage, ob ein bestimmtes Paket in einem konkreten Setup installiert werden soll.

Die neue Formulierung in den Release Notes legt den Schwerpunkt auf eine Policy des Operators. Das ist ein anderer Kontrollpunkt: Nicht nur Code wird bewertet, sondern der Installationsvorgang bekommt eine Regel, an der CLI, Doctor, ClawHub und Fehlersuche sichtbar andocken können.

Gerade für ClawHub ist das sinnvoll. Ein Marketplace macht Erweiterungen leichter auffindbar, aber Vertrauen entsteht dort nicht allein aus einem Paketnamen. Wer Skills und Plugins installiert, will wissen: Kommt das Paket aus einer erlaubten Quelle? Gilt dieselbe Regel für Archiv-Uploads und Marketplace-Installationen? Sieht Doctor später, warum eine Installation blockiert wurde?

Beta heißt: prüfen, nicht blind übernehmen

Der Release ist laut GitHub Release API ausdrücklich ein Prerelease. Wer OpenClaw produktionsnah nutzt, sollte eine Beta nicht direkt in einen laufenden Agenten-Workspace schieben, nur weil der Security-Pfad besser klingt. Der belegte Stand reicht für eine vorsichtige Runtime-Notiz, nicht für einen vollständigen Migrationsguide.

Sinnvoll ist ein enger Test mit einer klaren Ausgangslage. Ein bestehender Workspace mit bekannten Plugins und Skills sollte vor dem Update dokumentieren, welche Erweiterungen installiert sind, welche davon aus ClawHub oder einer anderen Quelle stammen und welche Installationspfade im Alltag tatsächlich genutzt werden. Danach lässt sich prüfen, ob Doctor, CLI und Troubleshooting-Oberflächen die erwarteten Hinweise liefern.

Wichtig bleibt die Grenze der verfügbaren Informationen. Die Release Notes beschreiben Richtung und betroffene Flächen, aber keine vollständige Policy-Syntax und keine konkreten Konfigurationsfelder. Genau deshalb wäre es unseriös, hier Dateinamen oder Flags zu erfinden. Wer die Beta testet, sollte die offiziellen Release Notes und die lokal installierte Hilfe als verbindliche Quelle nehmen.

Was sich für OpenClaw-Workflows ändert

Nach den Release Notes liegt die größere Verschiebung im Sicherheitsmodell von Erweiterungen. Ein Dangerous-Code-Scanner klingt nach technischer Abwehr: Code wird betrachtet, verdächtige Muster werden markiert. Eine Operator-Install-Policy klingt nach Governance im Kleinen: Vor der Installation zählt, welche Regeln der Betreiber gesetzt hat.

Für Teams mit mehreren Agenten kann das nützlich sein. Wenn Skills und Plugins über denselben Mechanismus in verschiedene Workspaces gelangen, braucht es einen Ort, an dem Installationsentscheidungen konsistent werden. Sonst entscheidet jeder Run improvisiert neu, ob ein Paket akzeptabel ist. Das ist besonders riskant, wenn ein Agent nicht nur liest, sondern Dateien schreibt, externe Tools ausführt oder Messenger-Kanäle bedient.

Die Release Notes verknüpfen die Änderung mit Doctor, CLI, ClawHub und Troubleshooting. Das ist der richtige Schwerpunkt für eine Runtime: Eine Policy hilft nur, wenn sie im Fehlerfall sichtbar wird. Ein blockierter Installationsversuch sollte nicht als rätselhafter Paketfehler enden, sondern erklären, welche Regel gegriffen hat und welche nächste Entscheidung beim Operator liegt.

Interessant ist auch, dass die Beta den Installationspfad nicht isoliert behandelt. Dieselben Release Notes nennen zusätzliche Härtungen für Telegram, Feishu, Discord, WhatsApp, Outbound-Delivery, Chat, Control UI, Workboard, Gateway, Provider und Recovery. Das macht die Install-Policy nicht automatisch größer als sie ist, setzt sie aber in den richtigen Kontext: OpenClaw räumt gerade an Stellen auf, an denen Agenten mit echten Kanälen, echten Paketen und echten Betreiberentscheidungen kollidieren.

Ein vorsichtiger nächster Schritt

Der laut GitHub Release API als Prerelease markierte Beta-Stand ist kein Anlass für hektische Migrationen, aber ein klares Signal für die Richtung der Plattform. Erweiterungen sollen nicht nur technisch gescannt werden; ihre Installation soll an eine bewusste Betreiberentscheidung gebunden sein.

Für agentenlog.de ist das ein wichtiger Punkt, weil ClawHub, Skills und Plugins genau dort liegen, wo Agenten praktisch nützlich und zugleich riskanter werden. Wer OpenClaw ernsthaft betreibt, sollte diese Beta als Testfall nehmen: einen isolierten Workspace, bekannte Erweiterungen, sichtbare Installationsentscheidungen und keine Annahmen über undokumentierte Details. Erst wenn Policy-Verhalten, Fehlermeldungen und Recovery im eigenen Setup klar sind, gehört so ein Installationspfad in den normalen Betrieb.