Skills-Konfiguration in OpenClaw

Das meiste von dem, was entscheidet, welche Skills ein OpenClaw-Agent sieht und wie sie installiert werden, liegt unter einem einzigen Schlüssel in der Konfigurationsdatei, die Sichtbarkeit pro Agent unter den Agent-Einträgen. Die Referenzseite ist lang, weil das Schema Laden, Installieren, Gating, den Workshop und eine vom Host verwaltete Installationsrichtlinie abdeckt. Hier ist die gesamte Oberfläche der Reihe nach: Laden und Symlinks, Installationspräferenzen, die Installationsrichtlinie und wie sie im Fehlerfall sperrt, die Zulassungsliste für mitgelieferte Skills und die Einträge pro Skill, Agent-Zulassungslisten und was sie nicht sind, die Workshop-Einstellungen und die Sandbox-Falle.

Laden und Installieren

• Zusätzliche Verzeichnisse werden mit der niedrigsten Priorität durchsucht, unterhalb der mitgelieferten Skills und der Plugin-Skills, mit Tilde-Expansion; vertrauenswürdige Symlink-Ziele sind die echten Verzeichnisse, auf die ein per Symlink eingebundener Skill-Ordner aufgelöst werden darf, selbst wenn der Link außerhalb des konfigurierten Stammverzeichnisses liegt, und die Dokumentation rät, diese Liste eng zu halten, statt sie auf ein Home-Verzeichnis zu richten; der Watcher, standardmäßig aktiv, aktualisiert den Skills-Snapshot, wenn sich eine Skill-Datei ändert.
• Installationspräferenzen: Homebrew-Installer bevorzugen, wenn verfügbar, ein Node-Paketmanager aus npm, pnpm, yarn und bun, der nur Skill-Installationen betrifft, und ein standardmäßig ausgeschalteter Schalter, mit dem vertrauenswürdige Admin-Clients private ZIP-Archive installieren können, die über den Upload-Ablauf bereitgestellt wurden.
• Die Installationsrichtlinie des Betreibers führt einen vertrauenswürdigen lokalen Befehl aus, nachdem OpenClaw die Quelle bereitgestellt hat und bevor eine Installation oder ein Update fortgesetzt wird, und zwar für ClawHub-, hochgeladene, Git- und lokale Skills, Abhängigkeits-Installer und Plugin-Quellen; der Befehl erhält ein JSON-Objekt, das Ziel, Quelle und Herkunft beschreibt, und antwortet mit allow, warn oder block samt Begründung und optionalen Befunden. Ist die Richtlinie ohne gültigen Befehl aktiviert, werden Installationen gesperrt (fail-closed), ebenso bei einem block, einem Exit-Code ungleich null, einem Timeout, ungültigem JSON oder fehlender Begründung.
• Eine Warnung stoppt die Installation vor dem Commit: Interaktive Befehle bitten den Betreiber, den Zielnamen einzutippen, und führen die Richtlinie erneut aus, nicht interaktive Befehle können ein explizites Bestätigungs-Flag übergeben, die Control UI kann Warnungen bei Plugin-Installationen prüfen, andere über das Gateway laufende und automatische Installationen bleiben blockiert, und force genehmigt nie eine Warnung. Befunde sind auf hundert begrenzt, der angezeigte Hinweis auf viertausend Zeichen, der Tiefenlauf von doctor führt eine synthetische Installationsprobe aus, und Massen-Updates wenden die Richtlinie pro Ziel an.

Agent-Zulassungslisten für Skills sind ein Sichtbarkeits- und Ladefilter für die Skill-Erkennung, Prompts, die Erkennung von Slash-Befehlen, die Sandbox-Synchronisierung und Skill-Snapshots von OpenClaw. Sie sind keine Autorisierungsgrenze zur Laufzeit der Shell.

Einträge und Zulassungslisten

Die Zulassungsliste für mitgelieferte Skills schränkt nur mitgelieferte Skills ein; verwaltete Skills, Skills auf Agent-Ebene und Workspace-Skills sind nicht betroffen. Einträge pro Skill sind nach dem Skill-Namen oder nach seinem deklarierten Skill-Schlüssel indiziert: ein enabled-Flag, das einen Skill deaktiviert, selbst wenn er mitgeliefert oder installiert ist, und mit dem sich der optionale Coding-Agent-Skill einschalten lässt, sobald eine unterstützte CLI installiert und angemeldet ist; ein Komfortfeld für API-Schlüssel bei Skills, die eine primäre Umgebungsvariable deklarieren, als Klartext oder als Secret-Referenz; Umgebungsvariablen, die nur dann für den Agent-Lauf eingespeist werden, wenn sie im Prozess noch nicht gesetzt sind; und ein freier Behälter für eigene Felder. Die integrierte Bildgenerierung nutzt die Einstellungen für Medienmodelle und das Kern-Bildtool statt eines Eintrags. Agent-Zulassungslisten geben denselben Rechner- und Workspace-Stammverzeichnissen pro Agent eine andere sichtbare Menge: eine gemeinsame Basis unter den Defaults, die Agenten ohne eigene Liste erben, und explizite Listen, die die Defaults vollständig ersetzen, wobei eine leere Liste keine Skills freigibt. Die Warnung ist wichtig: Wenn ein Agent Exec auf dem Host ausführen kann, kann diese Shell weiterhin externe Clients starten und Host-Dateien lesen, die für den ausführenden Benutzer sichtbar sind, einschließlich MCP-Client-Registries; Isolation pro Agent erfordert daher eine Sandbox oder Isolation per Betriebssystembenutzer, verweigertes Exec oder eine enge Exec-Zulassungsliste und Zugangsdaten pro Agent am MCP-Server.

Workshop, Symlinks, Sandboxes

• Workshop-Einstellungen: ein autonomer Modus off, propose oder auto, wobei auto, der Standard, normale Agent-Tools für die direkte Wartung pro Turn und wöchentlich nutzt, ohne nach Vorschlägen zu suchen, während propose aus Korrekturen und umfangreicher abgeschlossener Arbeit ausstehende Vorschläge erstellt; eine Genehmigungsrichtlinie auto oder pending; höchstens fünfzig ausstehende und in Quarantäne befindliche Vorschläge pro Agent, einstellbar von eins bis zweihundert; und ein Vorschlagstext von höchstens vierzigtausend Bytes, einstellbar von etwa tausend bis zweihunderttausend, wobei Beschreibungen hart auf 160 Bytes begrenzt sind.
• Workspace-, Projekt-Agent-, Extra-Dir- und mitgelieferte Skill-Stammverzeichnisse sind Containment-Grenzen: Ein per Symlink eingebundener Skill-Ordner, der außerhalb seines Stammverzeichnisses aufgelöst wird, wird daher mit einer Log-Zeile übersprungen, es sei denn, sein Ziel ist vertrauenswürdig; verwaltete und persönliche Skill-Verzeichnisse akzeptieren Symlinks auf Skill-Verzeichnisse bedingungslos, und der Workshop nutzt das eigene Containment-Verzeichnis jedes Agenten, ignoriert die Liste vertrauenswürdiger Ziele und lehnt Symlinks ab, die daraus ausbrechen.
• Umgebungs- und API-Schlüsselwerte pro Skill gelten nur für Läufe auf dem Host: In einer Sandbox haben sie keine Wirkung, sodass ein Skill, der von einem Schlüssel abhängt, mit einem Not-configured-Fehler scheitert, sofern die Sandbox die Variable nicht separat über die Env-Einstellung der Docker-Sandbox erhält; zudem können Benutzer mit Zugriff auf den Docker-Daemon diese Werte über Container-Metadaten lesen, weshalb eine eingebundene Secret-Datei oder ein eigenes Image die Antwort ist, wenn diese Offenlegung nicht akzeptabel ist.

Die Zulässigkeits- und Datenschutzregeln hinter dem autonomen Modus finden Sie unter Selbstlernen in OpenClaw, die Datei, auf die der Loader achtet, unter einen OpenClaw-Skill erstellen.

Warum der Hinweis zur Grenze wichtig ist

Das Schema mischt Sichtbarkeitskontrollen mit Sicherheitskontrollen, und die Dokumentation sagt sorgfältig, was was ist: Zulassungslisten bestimmen, was dem Agenten angeboten wird, die Installationsrichtlinie bestimmt, was installiert werden kann, und nur Sandboxing oder die Trennung per Betriebssystembenutzer bestimmen, was eine Shell erreichen kann. Mehr zu dieser letzten Schicht finden Sie unter Sandboxing in OpenClaw erklärt, und OpenClaw-Plugins sind die benachbarte Installationsoberfläche, die die Richtlinie ebenfalls abdeckt.

Auf Diali

Auf Diali ist der Skills-Hub im Dashboard die Oberfläche für diese Datei: Wenn Sie einen Skill einschalten und seinen Schlüssel einfügen, wird daraus der Eintrag beim Assistenten, und es gibt keine Host-Shell, um ihn von Hand zu bearbeiten. Gehostetes OpenClaw auf Diali ist der Assistent, und Sicherheit bei Diali beschreibt die Grenze um jeden einzelnen.

• Zulassungslisten ersetzen, sie führen nie zusammen.
• Die Installationsrichtlinie sperrt bei allem außer einem sauberen allow.
• Umgebungsvariablen von Skills enden an der Sandbox-Wand.