2026 OpenClaw nach Upgrade: Chat ja, Tools nein – tools.profile-Matrix, tools.deny und Agent-Override-Triage-Runbook

Sechs häufige Ursachen für „Chat ok, Tools blockiert“ nach dem Upgrade (erst triagieren, dann Config)

1. tools.profile auf messaging / minimal: Upgrade oder Wizard hat die Tool-Fläche verengt—Symptom: flüssiger Chat, sobald exec aufgerufen wird: not found.
2. tools.deny Kollateralschaden: Compliance hat temporär exec / browser verweigert; Ticket zu, Regel bleibt in der Config (Datenschutz- und Security-Reviews sollten Ablaufdatum erzwingen).
3. agents.list[].tools.profile überschreibt global: Global auf coding gestellt, der produktive Agent erbt noch messaging.
4. Halb-Upgrade, Gateway ohne reload: CLI sieht neue Config, Prozess alte Allowlist—wie split-brain im Rollback-Runbook, ohne zwingend Image-Rollback.
5. Modell ohne zuverlässiges tool-calling: schwaches Modell druckt Tool-Calls als Text; Profiländerung hilft nicht—Modell wechseln oder Aufgabe vereinfachen.
6. „Keine Antwort“ mit „Tool kaputt“ verwechseln: zuerst Keine-Antwort-Triage, nicht in der Allowlist-Schicht hängen bleiben.

Die OpenClaw-Tool-Fläche ist kein „installiert = alles offen“, sondern die Schnittmenge aus globalem profile → deny-Liste → Agent-Override. Die Upstream-Doku 2026 definiert tools.profile als Basis-Allowlist: minimal nur Session-Status; messaging Kanäle und Sessions; coding Dateisystem, Runtime, Web, Sessions, Memory; full ohne zusätzlichen Schnitt. Viele Teams scheitern beim ersten Upgrade nicht am Gateway-Ausfall, sondern am Vertrag von implizit offen zu explizit freigegeben, ohne „restart + Minimal-Sonde“ im Change-Ticket—On-Call wiederholt denselben Prompt und verbrennt ein Release-Fenster.

Läuft das Gateway auf einem schlafenden Laptop, kommt „Config geändert, launchd/Container nicht reload“ dazu. Ein autoritatives Gateway auf einem dauerhaft online, dedizierten Remote-Mac mit SSH-Lokalport-Forward trennt Config-Änderungen von Terminal-Rauschen; die Verifikationsleiter verlangt Abnahme am Gateway, nicht nur CLI-success (relevant für Datenschutz: weniger Ad-hoc-Log-Exports vom Laptop).

tools.profile-Matrix: coding oder full?

Die meisten Automatisierungs- und Dev-Agenten gehören auf coding: Dateien, Shell, Web, Sessions, Memory—leichter security-reviewbar als full. full nur mit Audit und Minimal-Exposure. messaging für reines Routing; minimal nur Status ohne Dateisystem. Zusammen mit Agents / Skills / memory_search Tool-Fläche und Kontextlimit im selben Change—sonst memory_search ja, read durch profile blockiert.

Beim Session-Start baut das Gateway eine effektive Tool-Registry für tool-calling; fehlt exec, lehnt die Runtime ab oder schwache Modelle drucken Absicht als Text. „Nach Upgrade nur noch Chat“ landet meist bei profile/deny—notfalls zuerst Keine-Antwort ausschließen.

tools.deny und Agent-Overrides: Prüfreihenfolge der drei Schichten

Feste Reihenfolge: ① effektives Profil vom laufenden Gateway → ② tools.deny → ③ agents.list[].tools.profile → ④ globale Config. Nach Release-Kanal-Upgrade im Ticket: Default-Profil-Migration? Rollback-Image über Rollback-Runbook, nicht endlos profile raten.

Typischer Multi-Agent-Fall: global coding, Prod-Bot noch messaging im alten Listeneintrag. Ticket: Agent-Name und Kanal; Abnahme CLI und Telegram/Slack je eine Minimal-Sonde. Temporäre deny von Security: Ablauf und Owner dokumentieren (Datenschutz: keine vergessenen Dauer-Denies).

Sechs Schritte: Profil angleichen – Neustart – Sonden

1. Evidence einfrieren: openclaw --version, tools.profile, Agent-Liste, Request-ID des Fehlers.
2. Symptom klassifizieren: Tabelle profile/deny/agent/Modell; bei Keine-Antwort Stopp.
3. Ziel-profil: Dev-Automation → coding; Grund und Rollback-Wert im Ticket.
4. Config anwenden, Gateway restart: openclaw gateway restart oder docker compose restart; ein autoritatives Gateway.
5. Verifikationsleiter: openclaw doctor → openclaw gateway status → nicht-destruktive Sonde (read / exec echo) → channels status --probe.
6. Dokumentation: Default-Profil nach Upgrade in ROLLBACK.md; mit Pin-Matrix koppeln.

openclaw --version
openclaw config get tools.profile 2>/dev/null || true
openclaw config set tools.profile coding
openclaw gateway restart
openclaw doctor
openclaw gateway status
# Minimal-Sonde: read oder harmloses exec in Control UI / CLI

Drei KPIs fürs On-Call-Handbuch (datengetrieben)

• Anteil „chat-only“-Fehlalarme: Tickets „Tools kaputt“ mit Root Cause profile/deny/override; zwei Wochen >40 % → Upgrade-Checkliste ohne Profil-Abnahme.
• Minuten bis Sonde grün: Median ≤10; oft >30 → kein einheitlicher Reload oder Dual-Gateway.
• Rollback-Quote nach Restart: >15 % → parallel Modell/Release-Regression prüfen.

Diese Metriken trennen Chat von Tool-Ausführung messbar. Remote-Gateway: Build- und Agent-Last in Change-Fenstern von Disk/CPU-Spitzen fernhalten, sonst falscher profile-Verdacht.

FinOps: Kurzmiete für OpenClaw-POC, am letzten Tag erst engeres Profil entdeckt—am Tag eins Ziel-profil, leere deny, Override-Policy in die Abnahme, parallel POC-KPI-Matrix „grüner Gateway-Tag eins“.

Fazit: Allowlist ist kein Mystik-Schalter

Prompt-Roulette ohne restart ist nicht auditierbar und nicht auf Maschine zwei reproduzierbar—Security kann Tool-Rechte nicht erklären. Gateway auf dauerhaft online, dediziertem Remote-Mac mit dokumentiertem Default-profil und Leiter drückt MTTR von „Abend Prompts“ auf „unter zehn Minuten nachvollziehbar“.

Laptop-Chasing: Schlaf, Reload nach Zuklappen, mündliche profile-Abweichungen im Team. Für 7×24, auditierbare Prod-Agenten lohnt sich MACCOME Mac mini (M4 / M4 Pro) in sechs Regionen oft gegenüber Laptop-Strompolitik; Multi-Region-Leitfaden und SSH-Runbook für Topologie.