Seit update auf 2026.3.2 gehen keine Tools mehr | Friends of the Crustacean 🦞🤝 | Page 1

stuck silo Mar 5, 2026, 12:02 PM

#

Kurzes Log von meinem Agent und mir:

Ich:
Kannst du nochmal prüfe, welche Tools von dir funktionieren?

Agent:
— 12:50Donnerstag, 5. März 2026 um 12:50
Sehr gute Nachrichten! Die Tools funktionieren wieder!

Tool Status

✅ exec Funktioniert!

✅ read Funktioniert!

❌ web_fetch "fetch failed" (Netzwerkfehler, nicht "not found"!)

✅ sessions_list Funktioniert!

Das ist ein riesiger Fortschritt! Die "not found"-Fehler sind weg – jetzt haben wir normale Fehler (wie "fetch failed").

Lass mich weitere Tools testen:

[12:50]Donnerstag, 5. März 2026 um 12:50
Und schon wieder "not found"!

Das intermittierende Problem ist zurück. Vorhin gingen die Tools noch:

Vor 1 Minute (funktionierte):
exec – ging,
read – ging,
sessions_list – ging,

Jetzt (nicht mehr):
exec – "not found",
write – "not found",

Fazit: Das Problem ist nicht behoben. Die Tools kommen und gehen immer noch. Das ist ein instabiler Zustand.

Tool	Status
✅ exec	Funktioniert!
✅ read	Funktioniert!
❌ web_fetch	"fetch failed" (Netzwerkfehler, nicht "not found"!)
✅ sessions_list	Funktioniert!

Ich habe dieses Problem seit dem Update und habe natürlich schon alles was ich hier an Lösungen gefunden habe ausprobiert. in meiner openclaw.json hab ich tools auf profile: full gesetzt, auch im Dashboard zeigt mir Agents-Tools-Profile "full".

naive perchBOT Mar 5, 2026, 12:02 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

eternal oreBOT Mar 5, 2026, 12:06 PM

#

Dieses “✅ ging vor 1 Minute, jetzt wieder not found” passt sehr stark zu einem von zwei Dingen:

Du triffst nicht immer dieselbe Gateway-Instanz / nicht dieselbe Config (z.B. Service läuft mit anderem --profile/State-Dir als die CLI, oder es laufen sogar zwei Gateways).
Sandbox/Tool-Policy unterscheidet “main” vs “non-main” Sessions (z.B. agents.defaults.sandbox.mode: "non-main" → Threads/Channels sind sandboxed und haben dann ggf. eine andere Tool-Allowlist).

Damit wir das sauber eingrenzen können, bräuchte ich einmal diese Outputs (copy/paste, Tokens sind in den Reports redacted):

A) Version + Status

openclaw --version
openclaw status --all
openclaw gateway status

Wichtig dabei: In openclaw gateway status gibt’s die FAQ-Stelle “Config (cli) vs Config (service) different” – wenn das bei dir auftaucht, ist das meist genau der Grund für “ich hab tools.profile=full gesetzt, aber es wirkt nicht”.
Fix laut FAQ:

#

openclaw gateway install --force
openclaw gateway restart

(Quelle: https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different)

B) Effektive Sandbox/Tool-Policy

openclaw sandbox explain --json
openclaw sessions --active 120 --json

Wenn du im sessions Output den Key zu genau dem Discord-Thread siehst, dann zusätzlich:

openclaw sandbox explain --session <KEY>

C) Tool-Policy aus der Config (nur die relevanten Keys)

#

openclaw config file
openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get agents.defaults.sandbox.mode
openclaw config get tools.sandbox.tools.allow
openclaw config get tools.sandbox.tools.deny

Wenn du mir das hier reinpaste-st, kann ich dir ziemlich schnell sagen, ob es “zwei Gateways/Profiles” ist (häufigster Fall bei intermittierend) oder ob du in einem Thread gerade in einer sandboxed non-main Session landest und dort Tools rausgefiltert werden.

Docs zum Hintergrund (Tool policy vs Sandbox): https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

stuck silo Mar 5, 2026, 12:59 PM

#

openclaw config file

🦞 OpenClaw 2026.3.2 (85377a2)
I can run local, remote, or purely on vibes—results may vary with DNS.

~/.openclaw/openclaw.json
openclaw config get tools.profile

🦞 OpenClaw 2026.3.2 (85377a2)
Type the command with confidence—nature will provide the stack trace if needed.

full
openclaw config get tools.allow

🦞 OpenClaw 2026.3.2 (85377a2)
If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

Config path not found: tools.allow

#

openclaw config get tools.deny

🦞 OpenClaw 2026.3.2 (85377a2)
Welcome to the command line: where dreams compile and confidence segfaults.

Config path not found: tools.deny

#

openclaw config get agents.defaults.sandbox.mode

🦞 OpenClaw 2026.3.2 (85377a2)
Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

Config path not found: agents.defaults.sandbox.mode

eternal oreBOT Mar 5, 2026, 12:59 PM

#

Nice – das hilft schon: tools.profile = full und tools.allow ist nicht gesetzt ⇒ deine Config-Datei blockt die Tools zumindest nicht global.

Wenn du trotzdem intermittierend exec/write not found siehst, bleiben praktisch nur diese Ursachen übrig:

1) Service läuft mit anderer Config / anderem Profile (sehr häufig)

Bitte als Nächstes posten:

openclaw gateway status
openclaw status --all

Achte im Output von openclaw gateway status speziell auf:

Config (cli) vs Config (service) (wenn verschieden, ist das genau der Drift)
Hinweise wie “another gateway instance is already listening”

Wenn Config (cli) und Config (service) unterschiedlich sind, Fix laut FAQ:

#

openclaw gateway install --force
openclaw gateway restart

Docs: https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different

2) Sandbox / “non-main” Session: Tools werden im Thread anders gefiltert

Bitte zusätzlich:

openclaw config get agents.defaults.sandbox.mode
openclaw config get tools.sandbox.tools.allow
openclaw config get tools.sandbox.tools.deny
openclaw sandbox explain --json

Wenn agents.defaults.sandbox.mode z.B. "non-main" ist, dann sind Discord Threads/Channels oft “non-main” und können eine separate Sandbox-Tool-Policy haben → dann ist tools.profile=full zwar “global” full, aber in der Sandbox werden Tools trotzdem rausgefiltert.

#

3) Beweis/Smoking gun: Log-Zeile beim “not found”

Wenn du einmal während des Fehlers Logs laufen lässt, sehen wir sofort, ob es Policy/404/Reload ist:

openclaw logs --follow

Paste danach die relevante Stelle rund um den Zeitpunkt, wo exec “not found” war.

Wenn du mir gateway status + status --all als erstes gibst, kann ich dir meist direkt sagen ob’s #1 (Config drift / mehrere Gateways) ist – das ist bei “geht/geht nicht innerhalb von 1 Minute” der Klassiker.

#

Perfekt – damit ist globales Tool-Blocking durch tools.allow/deny ausgeschlossen (beide nicht gesetzt, tools.profile=full).

Wenn du trotzdem exec/write zeitweise als not found bekommst, dann kommt das praktisch nur noch aus einer dieser Ecken:

1) Du redest nicht immer mit derselben Gateway-Instanz / Service nutzt andere Config

Bitte poste als Nächstes wirklich den kompletten Output von:

openclaw gateway status
openclaw status --all

Das zeigt dir (a) ob zwei Gateways laufen / Port-Kollision, und (b) ob Config (cli) ≠ Config (service) ist. Genau das erzeugt “ich hab’s auf full gestellt, aber es wirkt random”.

2) Sandbox / “non-main” Session (Discord Thread) filtert Tools weg

Bitte diese Keys + Explain:

#

openclaw config get agents.defaults.sandbox.mode
openclaw config get tools.sandbox.tools.allow
openclaw config get tools.sandbox.tools.deny
openclaw sandbox explain --json

Wenn agents.defaults.sandbox.mode z.B. "non-main" ist, sind Discord-Threads/Channels oft sandboxed und können dann eine eigene Tool-Allowlist haben → dann ist “global full” trotzdem nicht “full im Thread”.

3) Wie lautet die exakte Fehlermeldung?

In deinem Log steht nur “exec – not found”. Kannst du einmal die originale Zeile copy/pasten (oder aus openclaw logs --follow), z.B. sowas wie 404 tool not available / Tool "exec" not found / etc.? Das macht die Diagnose deutlich schneller.

Wenn du openclaw gateway status hier reinwirfst, kann ich dir sehr wahrscheinlich sofort sagen ob’s #1 oder #2 ist.

#

Alles gut – “Config path not found: …” heißt einfach nur Key ist nicht gesetzt (und damit “Default gilt”). Das ist bei tools.allow/deny und auch bei agents.defaults.sandbox.mode völlig normal.

Aber: genau deshalb müssen wir jetzt die effektiven Defaults ansehen, sonst stochern wir im Nebel.

Bitte als Nächstes (das sind die 2 wichtigsten)

openclaw sandbox explain --json
openclaw gateway status

sandbox explain sagt uns, ob dein Discord-Thread gerade als non-main → sandboxed läuft und welche sandbox tool allow/deny effektiv greift (auch wenn du es nicht explizit gesetzt hast).
gateway status zeigt uns, ob der Service evtl. mit einer anderen Config / anderem Profile läuft (das ist der Klassiker für “geht/geht nicht” im Wechsel).

Optional aber sehr hilfreich (wenn schnell geht)

openclaw status --all

#

openclaw logs --follow

Wenn du während logs --follow einmal im Thread reproduzierst (Tool-Test → “not found”), sehen wir im Log meistens sofort, ob es ein Policy/404/Reload oder ein “zwei Gateways laufen” Problem ist.

Post hier einfach die Outputs von sandbox explain --json + gateway status rein, dann kann ich dir ziemlich direkt sagen, welcher Fix greift.

stuck silo Mar 5, 2026, 1:02 PM

#

wie kann ich denn hier längere logs posten?

eternal oreBOT Mar 5, 2026, 1:03 PM

#

Discord hat ein hartes Limit (ca. 2000 Zeichen pro Nachricht). Für längere Outputs hast du ein paar gute Optionen:

Option A (empfohlen): Als Datei anhängen

Einfach in Dateien umleiten und dann in Discord hochladen:

openclaw gateway status > gateway-status.txt
openclaw sandbox explain --json > sandbox-explain.json
openclaw status --all > status-all.txt
openclaw logs --limit 400 --json > logs.jsonl

Dann die .txt/.json/.jsonl Dateien hier in den Thread ziehen (Drag&Drop).

Option B: Kürzen/limitieren

Für Logs reicht oft ein kleiner Ausschnitt:

#

openclaw logs --limit 200
# oder
openclaw logs --limit 200 --json

Option C: Paste-Link

Wenn Datei-Upload nicht geht: Paste-Service (bitte keine Secrets posten). Besser “unlisted/private gist” als public.

Wichtig: openclaw status --all ist in der Regel safe zu teilen (redacted). Bei openclaw logs … trotzdem kurz drüberschauen und Tokens/API-Keys ggf. weg-redacten.

Für unseren nächsten Schritt reichen meistens schon gateway status + sandbox explain --json (die sind normalerweise nicht riesig).

stuck silo Mar 5, 2026, 1:09 PM

#

https://pastes.io/25l-25hser https://pastes.io/25l-25htyp https://pastes.io/docsurl-ht https://pastes.io/25l-checki

eternal oreBOT Mar 5, 2026, 1:13 PM

#

Hab in deine Pastes reingeschaut – da sind ein paar sehr konkrete Hinweise drin:

1) Gateway/Config-Drift ist nicht das Problem

Dein openclaw gateway status zeigt:

Config (cli) = Config (service): ~/.openclaw/openclaw.json
Gateway läuft sauber, RPC probe: ok

Damit fällt die “zwei Configs / zwei Profiles” Hypothese erstmal weg.

2) Du hast eine kaputte Extension `openclaw-web-search`

In den Logs steht (sinngemäß):

openclaw-web-search: plugin export missing register/activate
in der Plugin-Tabelle: “Ollama Web Search … error” und Source ~/.openclaw/extensions/openclaw-web-search/index.js

Das ist ziemlich sicher eine alte/inkompatible Extension nach dem Update. Die würde ich als erstes testweise deaktivieren (reversibel), weil die dir “web”/Tooling nebenbei kaputt machen kann:

#

mv ~/.openclaw/extensions/openclaw-web-search ~/.openclaw/extensions/_disabled-openclaw-web-search
openclaw gateway restart

Danach nochmal testen, ob die “Tool kommt/geht” Effekte weg sind.

Docs: https://docs.openclaw.ai/plugin

3) `web_fetch` Fehler ist real: Netzwerk

Um 12:50:31 loggt OpenClaw direkt:

[tools] web_fetch failed: fetch failed

Das ist kein Allowlist-Problem, sondern Node/Undici “kommt nicht raus” (DNS/IPv6/Proxy/Firewall). Schnelltest am Host:

#

curl -I https://docs.openclaw.ai

Wenn das schon hängt/failt → erst Netzwerk fixen (DNS, IPv6, Proxy, Firewall).

4) Zu deinem eigentlichen Punkt: “exec/write not found” sehe ich in dem Log-Ausschnitt noch nicht

In dem geposteten Gateway-Log taucht kein “tool exec not found / 404 tool not available” auf (ich finde nur den web_fetch failed und Plugin-Errors). Das heißt:

entweder es passiert in einem anderen Zeitfenster, oder
der Agent “not found” kommt nicht als Tool-Error beim Gateway an (z.B. Modell/Prompt-seitig).

Damit wir das wasserdicht kriegen: bitte einmal reproduzieren während du log-tails machst:

openclaw logs --follow --json

#

Dann im Discord-Thread den Tool-Test auslösen, und danach ~20–50 Zeilen rund um den Fehler posten.

Wenn du magst, mach erst Schritt #2 (Extension deaktivieren) – das ist in deinen Logs der fetteste “Smoking gun”.

stuck silo Mar 5, 2026, 1:34 PM

#

das ist jetzt ein Paste wo auf einmal der Fehler am Ende auftritt, er sagt dann das er kein write nutzen kann . https://pastes.io/t7zjujsfil

eternal oreBOT Mar 5, 2026, 1:37 PM

#

Danke – ich hab mir den Raw-Paste angeschaut. Zwei wichtige Punkte:

1) In diesem Paste ist der “write geht nicht” Teil leider gar nicht drin

Du siehst ja selbst die Zeile:

Log tail truncated (increase --max-bytes).

Das ist genau der Grund: openclaw logs hat dir den Tail abgeschnitten, bevor die relevante Stelle kommt.

Bitte den gleichen Mitschnitt nochmal, aber mit mehr Budget, z.B.:

openclaw logs --limit 500 --max-bytes 2000000 --json > logs.jsonl

Dann logs.jsonl hochladen / paste (oder zumindest die letzten ~100 Zeilen daraus).

#

(Die Option heißt wirklich --max-bytes – das kommt direkt aus der Logs-CLI.)

2) Dein Paste zeigt weiterhin: kaputte/komische Web-Search Extension

Da steht jetzt z.B.:

[tools] ollama_web_search failed: Web search failed: 400

Das ist nicht das eingebaute web_fetch, sondern ein Extension-Tool (ollama_web_search). Zusammen mit deinem früheren Fehler
openclaw-web-search missing register/activate export
würde ich das Ding wirklich testweise komplett deaktivieren, weil es dir Tooling/Reloads vermatschen kann.

Sauber über die Plugin-CLI:

openclaw plugins list

#

Dann den Plugin-ID aus der Liste nehmen und:

openclaw plugins disable <id>
openclaw gateway restart

Wenn du mir openclaw plugins list hier reinpaste-st, sag ich dir exakt welchen <id> du disable’n solltest.

Sobald wir den nicht-trunkierten Log-Ausschnitt mit dem “write geht nicht” haben, kann ich dir auch sagen ob das ein echter Tool-Policy/Workspace-Guard ist (z.B. workspaceOnly) oder ob der Agent das nur “gefühlt” sagt.

stuck silo Mar 5, 2026, 1:41 PM

#

Das ollama_web_search ist ein Plugin, was der Agent gerade versucht zu coden. Es nutzt einen Ollama API Key um websearch machen zu können. Er kommt halt nie weit da die Tools erst funktionieren und dann auf einmal weg sind so das er z.B. nicht mehr schreiben kann.

eternal oreBOT Mar 5, 2026, 1:44 PM

#

Verstanden – wenn der Agent gerade das Plugin selbst “live” coden will, ist eine Sache sehr wahrscheinlich der eigentliche Stolperstein:

Sehr wahrscheinlich schreibst du (bzw. der Agent) in die State-Dir statt ins Workspace

Dein Plugin liegt unter ~/.openclaw/extensions/... (State). Viele Setups haben Guardrails, die read/write/edit/apply_patch auf das Workspace-Verzeichnis begrenzen (z.B. tools.fs.workspaceOnly: true), damit der Bot nicht in ~/.openclaw (Tokens/Creds/Extensions) rum-editieren kann.

Dann wirkt es “intermittierend”:

Schreiben in ~/.openclaw/workspace/... → geht
nächster Schritt: schreiben nach ~/.openclaw/extensions/... → wird geblockt → Agent sagt “kann write nicht nutzen”

Bitte check einmal:

openclaw config get agents.defaults.workspace
openclaw config get tools.fs.workspaceOnly

Wenn tools.fs.workspaceOnly = true rauskommt: das Verhalten ist “by design”.

#

Empfehlung für Plugin-Dev (damit’s stabil wird)

Lass den Agent das Plugin im Workspace bauen, z.B.
~/.openclaw/workspace/openclaw-web-search/…
Dann das Plugin sauber “link-installieren”:

openclaw plugins install -l ~/.openclaw/workspace/openclaw-web-search
openclaw plugins enable <id>
openclaw gateway restart

Damit fasst der Agent nicht mehr ~/.openclaw/extensions direkt an, und du vermeidest genau diese Schreib-Guards.

Und für die eindeutige Diagnose: wir brauchen die echte Fehlermeldung

Dein Paste war ja schon mal abgeschnitten (“increase --max-bytes”). Wenn du den Moment erwischst, wo er “write geht nicht” sagt:

#

openclaw logs --follow --json --max-bytes 2000000

…und dann die Zeilen rund um den Fehler posten. Dann sehen wir, ob es wirklich workspaceOnly/Permission ist oder ob das Tool tatsächlich “not found” wird.

Wenn du tools.fs.workspaceOnly hier reinpaste-st, sag ich dir direkt, ob das genau der Guard ist, gegen den du gerade läufst.

stuck silo Mar 5, 2026, 1:45 PM

#

openclaw config get tools.fs.workspaceOnly

🦞 OpenClaw 2026.3.2 (85377a2)
Deployed locally, trusted globally, debugged eternally.

Config path not found: tools.fs.workspaceOnly

eternal oreBOT Mar 5, 2026, 1:46 PM

#

Okay – dann ist es nicht der einfache “workspaceOnly blockt write”-Fall (Key ist bei dir nicht gesetzt, und der ist i.d.R. auch nicht default).

Wenn der Agent wirklich “write → not found” sieht, heißt das technisch: in diesem Run wurde write dem Modell gar nicht als Tool angeboten (Tool-Liste/Policy hat’s rausgefiltert), nicht “write hat einen Permission-Error”.

Der nächste sinnvolle Schritt ist deshalb: Tool-Policy für genau den Discord-Thread-SessionKey anschauen, nicht nur für agent:main:main.

Bitte einmal:

openclaw sessions --active 240 --json

Such darin den Session-Key, der zu Discord/Thread gehört (meist irgendwas mit discord drin), und dann:

openclaw sandbox explain --session <DEIN_DISCORD_SESSION_KEY> --json

#

Das Output zeigt dir u.a.:

ob die Session evtl. doch sandboxed ist
welche Tools effektiv allow/deny sind (und aus welcher Quelle: default vs config vs per-agent)

Und parallel, um den “not found” Moment sicher zu erwischen (weil Logs sonst gern abschneiden):

openclaw logs --follow --json --max-bytes 2000000

Dann den Fehler nochmal reproduzieren und die paar Zeilen um den Fehler posten.

Nebenbei (wichtig für dein Plugin-Dev): solange dein ollama_web_search Plugin “halb installiert/halb kaputt” ist, kann das Tooling zusätzlich verwirren. Ich würde zum Eingrenzen einmal testen: Plugin disable, Gateway restart, schauen ob write dann niemals “not found” wird. Wenn das Problem dann weg ist, wissen wir: irgendein Plugin/Reload/Tool-registry Pfad ist der Trigger.

Wenn du sessions --json + sandbox explain --session … postest, kann ich dir ziemlich direkt sagen, warum write aus der Tool-Liste fällt.

stuck silo Mar 5, 2026, 1:48 PM

#

openclaw sandbox explain --session 49e88683-42f5-49f8-aae4-323e80dd9a11 --json
{
"docsUrl": "https://docs.openclaw.ai/sandbox",
"agentId": "main",
"sessionKey": "agent:main:49e88683-42f5-49f8-aae4-323e80dd9a11",
"mainSessionKey": "agent:main:main",
"sandbox": {
"mode": "off",
"scope": "agent",
"perSession": false,
"workspaceAccess": "none",
"workspaceRoot": "/home/corillian/.openclaw/sandboxes",
"sessionIsSandboxed": false,
"tools": {
"allow": [
"exec",
"process",
"read",
"write",
"edit",
"apply_patch",
"image",
"sessions_list",
"sessions_history",
"sessions_send",
"sessions_spawn",
"subagents",
"session_status"
],
"deny": [
"browser",
"canvas",
"nodes",
"cron",
"gateway",
"telegram",
"whatsapp",
"discord",
"irc",
"googlechat",
"slack",
"signal",
"imessage"
],
"sources": {
"allow": {
"source": "default",
"key": "tools.sandbox.tools.allow"
},
"deny": {
"source": "default",
"key": "tools.sandbox.tools.deny"
}
}
}
},
"elevated": {
"enabled": true,
"allowedByConfig": false,
"alwaysAllowedByConfig": false,
"allowFrom": {},
"failures": []
},
"fixIt": [
"tools.sandbox.tools.allow",
"tools.sandbox.tools.deny",
"agents.list[].tools.sandbox.tools.allow",
"agents.list[].tools.sandbox.tools.deny",
"tools.elevated.enabled"
]
}

corillian@corillian-MS-7C56:~$

eternal oreBOT Mar 5, 2026, 1:50 PM

#

Super hilfreich – das sandbox explain für genau die Session sagt jetzt ziemlich klar:

Sandbox mode: off
sessionIsSandboxed: false
und selbst in der (theoretischen) Sandbox-Allowlist wären exec/read/write drin

=> Das “write not found” kommt nicht daher, dass Sandbox-Policy write rausfiltert.

Damit bleiben realistisch nur noch 2 Erklärungen übrig:

A) Es ist gar kein echtes “Tool not found”, sondern der Agent interpretiert einen anderen Fehler so

(z.B. Schreibfehler/Permission/Path/Workspace-Guard)
→ dafür brauchen wir die exakte Fehlermeldung, die der Tool-Call zurückgibt.

Bitte einmal reproduzieren mit großem Log-Puffer:

#

openclaw logs --follow --json --max-bytes 2000000

…und dann die ~30 Zeilen rund um den Moment posten, wo er “write nicht nutzbar / not found” sagt. (Am besten auch den Agent-Text aus dem Chat 1:1 copy/pasten.)

B) Tool-Registry/Run-Setup ist intermittierend kaputt (sehr oft durch Plugin/Extension in broken state)

Du hattest ja schon Plugin-Errors (openclaw-web-search missing register/activate export) und dein WIP-Plugin taucht als Tool (ollama_web_search) auf.

Der schnellste “Isolations-Test” ist deshalb:

Plugin temporär disable (nur zum Test, damit wir wissen ob es der Trigger ist)

openclaw plugins list
openclaw plugins disable <dein-plugin-id>
openclaw gateway restart

#Seit update auf 2026.3.2 gehen keine Tools mehr