Slack Plugin kann mit SecretRef Tokens nicht geladen werden: PluginLoadFailureError in agents Befehlen

Jeder CLI-Befehl unter dem openclaw agents-Namensraum wird sofort mit einem fatalen Plugin-Ladefehler beendet, wenn Slack-Kanal-Tokens als SecretRef-Objekte konfiguriert sind. Der Fehler tritt auf, bevor die Befehlslogik ausgeführt wird, und macht die gesamte CLI für die Agentenverwaltung unbrauchbar.

Primäre Fehlerausgabe

$ openclaw agents list
[plugins] slack failed during register from .../extensions/slack/index.js:
  Error: channels.slack.accounts.default.botToken: unresolved SecretRef "file:local:/SLACK_BOT_TOKEN".
  Resolve this command against an active gateway runtime snapshot before reading it.

[openclaw] Failed to start CLI: PluginLoadFailureError: plugin load failed: slack: ...
$
$ echo $?
1

Zusätzlich betroffene Befehle

$ openclaw agents add myagent --workspace ~/.openclaw/workspace-myagent
# Same PluginLoadFailureError output, exit code 1

$ openclaw agents remove myagent
# Same PluginLoadFailureError output, exit code 1

$ openclaw agents status myagent
# Same PluginLoadFailureError output, exit code 1

Konfigurationsmuster, das den Fehler auslöst

Das folgende openclaw.json-Konfigurationssegment löst den Fehler aus:

json { “channels”: { “slack”: { “accounts”: { “default”: { “botToken”: { “source”: “file”, “provider”: “local”, “id”: “/SLACK_BOT_TOKEN” }, “appToken”: { “source”: “file”, “provider”: “local”, “id”: “/SLACK_APP_TOKEN” } } } } } }

Unterscheidung vom Gateway-Verhalten

Der laufende Gateway-Prozess ist von diesem Problem nicht betroffen. Der Gateway hält einen In-Memory-Schnappschuss der aufgelösten Geheimnisse und verarbeitet Slack-Events korrekt. Nur die CLI (ein separater Prozess) schlägt fehl, weil sie die Rohkonfiguration aus openclaw.json liest, ohne Zugriff auf den Runtime-Geheimnis-Auflösungs-Kontext.

Ausführungsaufrufkette

Der Absturz resultiert aus einer spezifischen Sequenz eifriger Auflösung während der Plugin-Registrierung:

1. Befehlsausführungspfad: command-execution-startup.js setzt loadPlugins: "always" für alle agents-Unterbefehle und erzwingt eine vollständige Plugin-Initialisierung bei jeder Ausführung.
2. Strenge Fehlerbehandlung: runtime-registry-loader.js führt das CLI-Plugin-Laden mit throwOnLoadError: true aus, was jeden Plugin-Registrierungsfehler in einen fatalen Zustand umwandelt.
3. Routenregistrierung löst Auflösung aus: extensions/slack/index.js ruft registerSlackPluginHttpRoutes() während seines Registrierungs-Hooks auf.
4. Eifriger Token-Zugriff: registerSlackPluginHttpRoutes() ruft resolveSlackAccount({cfg, accountId}) bedingungslos auf, einschließlich für das Standardkonto.
5. SecretRef wirft ungelösten Fehler: accounts.js → resolveSlackBotToken(merged.botToken, …) → normalizeResolvedSecretInputString() erkennt das ungelöste SecretRef-Objekt und wirft den fatalen Fehler.

Architektonische Inkonsistenz

Das Slack-Plugin verletzt das erwartete Prinzip der verzögerten Auflösung für Kanal-Plugins:

• Erwartetes Verhalten: Plugin-Registrierung sollte Routen registrieren und Handler vorbereiten. Die eigentliche Token-Auflösung sollte bei der Verarbeitung eines eingehenden Events auftreten (d.h. innerhalb des HTTP-Request-Handlers), zu welchem Zeitpunkt der Gateway-Runtime-Schnappschuss verfügbar ist.
• Tatsächliches Verhalten: Die Token-Auflösung erfolgt synchron während der Routenregistrierung, bevor irgendeine Anfrage verarbeitet werden kann.

Warum die CLI keine Geheimnisse auflösen kann

Der CLI-Prozess ist eine eigenständige ausführbare Datei, die:

1. openclaw.json direkt von der Festplatte liest.
2. Keine aktive Gateway-Runtime-Verbindung hat.
3. Keinen Zugriff auf den Geheimnis-Auflösungs-Schnappschuss des Gateways hat.
4. Fehlschlägt, wenn sie auf ein SecretRef stößt, das nicht zu einem konkreten String-Wert aufgelöst wurde.

Unzureichende Workarounds

Option A: Temporärer Workaround (Sofortige Entlastung)

Ersetzen Sie SecretRef-Objekte durch Dummy-String-Werte, bevor Sie CLI-Befehle ausführen, und stellen Sie dann die ursprüngliche Konfiguration wieder her.

Vorher (openclaw.json):

"botToken": { "source": "file", "provider": "local", "id": "/SLACK_BOT_TOKEN" },
"appToken": { "source": "file", "provider": "local", "id": "/SLACK_APP_TOKEN" }

Nachher (temporär):

"botToken": "xoxb-placeholder-do-not-use",
"appToken": "xapp-placeholder-do-not-use"

Führen Sie den erforderlichen CLI-Befehl aus:

openclaw agents add myagent --workspace ~/.openclaw/workspace-myagent

Stellen Sie die ursprünglichen SecretRef-Objekte in openclaw.json sofort danach wieder her.

Option B: Konfigurationsbasierter Workaround

Erstellen Sie eine separate openclaw.json für CLI-only-Operationen, die die Slack-Konfiguration vollständig ausschließt.

1. Sichern Sie die aktuelle Konfiguration:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.gateway

2. Erstellen Sie eine CLI-spezifische Konfiguration ohne Kanaldefinitionen:

cat > ~/.openclaw/openclaw-cli.json << 'EOF'
{
  "version": "2",
  "workspace": {
    "default": "~/.openclaw/workspace-default"
  },
  "plugins": {
    "allow": ["core", "agents"]
  }
}
EOF

3. Verwenden Sie die CLI-spezifische Konfiguration über die Umgebungsvariable:

OPENCLAW_CONFIG=~/.openclaw/openclaw-cli.json openclaw agents list

Option C: Code-Fix (Permanente Lösung)

Ändern Sie den Registrierungs-Hook des Slack-Plugins, um die Token-Auflösung zu verzögern.

Datei: extensions/slack/index.js

Vorher (aktueller problematischer Code):

function registerSlackPluginHttpRoutes(cfg) {
  // Eagerly resolve account during registration
  const account = resolveSlackAccount({ cfg, accountId: DEFAULT_ACCOUNT_ID });
  
  router.post('/events', async (req, res) => {
    // Handle Slack events...
  });
}

Nachher (verzögerte Auflösung):

function registerSlackPluginHttpRoutes(cfg) {
  // Register route unconditionally; resolve lazily on each request
  router.post('/events', async (req, res) => {
    // Resolve account only when processing an actual event
    const account = resolveSlackAccount({ cfg, accountId: DEFAULT_ACCOUNT_ID });
    
    // Handle Slack events...
  });
}

Wenden Sie dasselbe Muster auf alle anderen Routen an, die auf Konto-Tokens zugreifen (/interactions, /commands usw.).

Verifizieren des Workarounds (Option A)

1. Bestätigen Sie, dass die ursprüngliche Konfiguration SecretRef-Objekte enthält:

$ grep -A5 '"botToken"' ~/.openclaw/openclaw.json
        "botToken": {
          "source": "file",
          "provider": "local",
          "id": "/SLACK_BOT_TOKEN"
        },

2. Ersetzen Sie vorübergehend Platzhalter-Strings und führen Sie den Befehl aus:

$ sed -i '' 's/"botToken": { "source": "file", "provider": "local", "id": "\/SLACK_BOT_TOKEN" }/"botToken": "xoxb-placeholder"/' ~/.openclaw/openclaw.json
$ sed -i '' 's/"appToken": { "source": "file", "provider": "local", "id": "\/SLACK_APP_TOKEN" }/"appToken": "xapp-placeholder"/' ~/.openclaw/openclaw.json
$ openclaw agents list
[agent list output]
$ echo $?
0

3. Stellen Sie die ursprüngliche Konfiguration wieder her:

$ cp ~/.openclaw/openclaw.json.gateway ~/.openclaw/openclaw.json
# Verify restoration
$ grep -A5 '"botToken"' ~/.openclaw/openclaw.json | head -6
        "botToken": {
          "source": "file",
          "provider": "local",
          "id": "/SLACK_BOT_TOKEN"
        },

Verifizieren des permanenten Fixes (Option C)

Nach Anwendung des Code-Fixes auf extensions/slack/index.js:

1. Rebuilden oder reinstallieren Sie die OpenClaw CLI:

$ npm run build  # or the appropriate build command for your installation
$ openclaw --version
openclaw/2026.4.9 darwin-x64 node-v22.8.0

2. Verifizieren Sie, dass der agents-Befehl jetzt mit intakter SecretRef-Konfiguration erfolgreich ist:

$ openclaw agents list
[agent list output]
$ echo $?
0

3. Bestätigen Sie, dass der Gateway Slack-Events weiterhin korrekt verarbeitet (falls aktiv):

$ curl -X POST http://localhost:3000/slack/events \
  -H "Content-Type: application/json" \
  -d '{"type": "url_verification", "challenge": "test"}'
{"challenge": "test"}

4. Überprüfen Sie auf keine verbleibenden Fehler in den Logs:

$ tail -n 50 ~/.openclaw/logs/gateway.log | grep -i "secret\|token\|resolve"
# No error messages should appear

Fehler 1: Vergessen, die Konfiguration wiederherzustellen

Nach Verwendung des Platzhalter-Workarounds vergessen Benutzer häufig, die ursprüngliche SecretRef-Konfiguration wiederherzustellen. Dies führt dazu, dass der laufende Gateway beim nächsten Neustart ungültige Platzhalter-Tokens neu lädt.

Risikominderung: Erstellen Sie immer ein Backup vor der Änderung und verwenden Sie atomare Operationen:

# Atomic swap with backup
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.backup && \
  sed -i 's/placeholder/dummy/' ~/.openclaw/openclaw.json && \
  openclaw agents list && \
  mv ~/.openclaw/openclaw.json.backup ~/.openclaw/openclaw.json

Fehler 2: Mehrere CLI-Konfigurationen verursachen Verwirrung

Benutzer, die eine separate CLI-Konfiguration erstellen, versehentlich die Gateway-Konfiguration ändern, während sie CLI-Verhalten erwarten, oder umgekehrt.

Risikominderung: Verwenden Sie immer die explizite OPENCLAW_CONFIG-Umgebungsvariable und verifizieren Sie, welche Konfiguration aktiv ist:

$ OPENCLAW_CONFIG=~/.openclaw/openclaw-cli.json openclaw config show | grep workspace

Fehler 3: Annahme, dass enabled: false das Plugin-Laden verhindert

Das Slack-Plugin lädt unabhängig vom enabled-Flag, weil das Plugin sowohl durch die plugins.allow-Liste als auch durch den channels.slack-Konfigurationsblock ausgelöst wird.

Risikominderung: Verlassen Sie sich nicht darauf, dass enabled: false das Plugin-Laden im CLI-Kontext überspringt.

Fehler 4: Umgebungsvariable Workarounds unzureichend

Setzen von SLACK_BOT_TOKEN als Umgebungsvariable umgeht den SecretRef-Fehler nicht, weil das Plugin die SecretRef-Struktur zuerst auswertet, bevor es Umgebungs-Fallbacks prüft.

Risikominderung: Verwenden Sie stattdessen den Platzhalter-Workaround oder den separaten CLI-Konfigurationsansatz.

Fehler 5: Docker/Container-Umgebungen

In containerisierten Bereitstellungen hat der file:local-Geheimnis-Provider möglicherweise keinen Zugriff auf die im SecretRef angegebenen Host-Dateisystempfade.

Risikominderung: Montieren Sie das Geheimnis-Verzeichnis in den Container:

docker run --rm \
  -v $HOME/.openclaw:/root/.openclaw \
  -v /run/secrets:/run/secrets:ro \
  openclaw agents list

Fehler 6: Windows-Pfadtrennzeichen

Unter Windows verwendet der SecretRef-ID Forward-Slashes (/SLACK_BOT_TOKEN), was mit der Windows-Pfad-Parsing in einigen Konfigurationen in Konflikt geraten kann.

Risikominderung: Verwenden Sie Windows-kompatible Geheimnis-IDs oder konfigurieren Sie den file:local-Provider mit entsprechender Pfad-Zuordnung.

• PluginLoadFailureError — Generischer Plugin-Ladefehler. In diesem Kontext spezifisch ausgelöst durch die eifrige Token-Auflösung des Slack-Plugins während der Registrierung. Exit-Code: 1.
• channels.slack.accounts.default.botToken: unresolved SecretRef — Spezifischer Fehler, der von normalizeResolvedSecretInputString() geworfen wird, wenn ein SecretRef-Objekt angetroffen wird, das nicht zu einem String-Wert aufgelöst wurde.
• channels.slack: unknown channel id — Fehler, der angetroffen wird, wenn gebündelte Plugins deaktiviert sind, aber eine channels.slack-Konfiguration existiert. Zeigt eine Fehlkonfiguration der OPENCLAW_DISABLE_BUNDLED_PLUGINS-Umgebungsvariable an.
• SecretRef Auflösungsfehler in anderen Plugins — Ähnliche eifrige-Auflösungs-Probleme können in anderen Kanal-Plugins existieren (z.B. Microsoft Teams, Discord), wenn sie demselben Registrierungsmuster wie Slack folgen.
• OPENCLAW_CONFIG not found — Fehler, wenn der angegebene Konfigurationsdateipfad nicht existiert. Verifizieren Sie, dass der Pfad absolut oder relativ zum korrekten Arbeitsverzeichnis ist.
• throwOnLoadError: true in Nicht-CLI-Kontexten — Jeder Codepfad, der das Plugin-Laden mit throwOnLoadError: true aufruft, wird dieses dieselbe Fehlerursache zeigen, nicht nur die CLI. Überprüfen Sie alle Aufrufstellen von runtime-registry-loader.js.