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

Mit OpenClaw 2026.6.2-beta.1 kündigte das Projekt im Juni 2026 einen Wechsel beim Installieren von Plugins und Skills an: Der bisherige Pfad rund um den Dangerous-Code-Scanner sollte einer Operator-Install-Policy weichen. Das war mehr als eine Packaging-Änderung. Sobald ein Agent fremde Erweiterungen installieren darf, entscheidet dieser Moment darüber, ob aus einem nützlichen Skill ein kontrollierbares Betriebsrisiko wird.

Die Beta nannte Paket-, Archiv-, Source-, Upload- und Marketplace-Installationen als betroffene Wege. Doctor, CLI, ClawHub und die Fehlersuche sollten den Policy-Kontext besser sichtbar machen. Der praktische Effekt: Vertrauen soll nicht allein am Paketnamen hängen, sondern an einer nachvollziehbaren Regel darüber, welche Quelle in welchen Workspace darf.

Der Sicherheitsgewinn liegt im Installationsmoment

Ein Scanner kann auffälligen Code markieren. Er beantwortet jedoch nicht die Frage, ob ein Paket aus einer bestimmten Quelle in diesem Workspace akzeptabel ist. Diese Entscheidung hängt von der Umgebung ab. Ein isolierter Test-Agent mit wenigen Rechten ist etwas anderes als ein Agent, der Dateien ändern, externe Dienste ansprechen oder Nachrichten in produktive Kanäle senden kann.

Die Beta verlagerte den Kontrollpunkt näher an den Betreiber. Plugins und Skills sind kein passiver Inhalt: Sie erweitern Werkzeuge, Zugriffswege und damit den Handlungsspielraum eines Agents. Bei ClawHub oder bei hochgeladenen Archiven reicht ein plausibler Paketname nicht. Entscheidend ist, ob Herkunft und Installationsweg zur eigenen Sicherheitsgrenze passen.

Was ein Beta-Test zeigen musste

Ein sinnvoller Test brauchte keinen großen Migrationsplan, sondern einen kleinen, kontrollierten Versuch. Ein Test-Workspace enthält bekannte Erweiterungen und keine produktiven Zugangsdaten. Vor dem Update wird festgehalten, welche Plugins installiert sind und über welchen Weg sie kamen. Danach wird eine erlaubte sowie eine bewusst nicht freigegebene Installation über die im eigenen Setup verfügbare Oberfläche geprüft.

Das erwartete Ergebnis ist klar: Eine erlaubte Erweiterung lässt sich nachvollziehbar installieren. Ein blockierter Versuch sollte erkennen lassen, dass eine Installationsregel gegriffen hat und wo die nächste Entscheidung beim Betreiber liegt. Bleibt stattdessen nur ein vager Paketfehler, gehört die Beta nicht in den normalen Betrieb.

Auch die Rückkehrgrenze sollte vor dem Test feststehen. Wer nach dem Update nicht mehr unterscheiden kann, ob eine Erweiterung, ihre Quelle oder eine Regel die Ursache ist, sollte nicht an undokumentierten Einstellungen drehen. Der sichere Weg führt zurück in den isolierten Test und zur lokal verfügbaren Hilfe. Die Beta beschrieb die Richtung der Änderung, nicht jede Konfigurationsoption.

Mehrere Workspaces verschärfen die Frage

In einem einzelnen Workspace lässt sich eine Installationsentscheidung oft noch von Hand nachvollziehen. Mit mehreren Agents wird sie schnell uneinheitlich: Ein Team erlaubt eine Marketplace-Erweiterung, ein anderes lädt ein Archiv hoch, ein drittes übernimmt einen Skill aus einem Repository. Ohne gemeinsamen Kontrollpunkt entstehen Ausnahmen, die später niemand mehr erklären kann.

Die Install-Policy war deshalb vor allem ein Governance-Werkzeug im Kleinen. Sie sollte sichtbar machen, welche Regel greift, statt Sicherheit in einem unsichtbaren Scanner-Ergebnis zu verstecken. Installationen werden prüfbar, und ein Fehlerbild lässt sich besser einem Ursprung zuordnen.

Die Beta verband den Umbau zudem mit weiteren Härtungen rund um Messenger, Gateway, Control UI und Recovery. Daraus folgt nicht, dass eine Install-Policy alle Risiken abdeckt. Sie gehört aber an eine Stelle, an der Agenten besonders schnell über ihre ursprüngliche Aufgabe hinauswachsen: beim Einbinden neuer Fähigkeiten und Zugriffswege.

Die Mindestregel für Erweiterungen

Der Prerelease war kein Freifahrtschein für eine direkte Migration. Sein bleibender Wert liegt in einer einfachen Betriebsfrage: Kann das Team nachvollziehbar begründen, warum genau diese Erweiterung in genau diesem Workspace installiert werden darf?

Ich würde diese Frage vor jedem Plugin- oder Skill-Rollout stellen. Wenn Herkunft, erwartetes Verhalten und der Umgang mit einer Blockierung nicht klar sind, fehlt nicht bloß ein Flag. Dann fehlt die Betriebsentscheidung, die ein Agentensystem von einer Sammlung zufälliger Erweiterungen trennt.