openclaw - 💡(How to fix) Fix [Bug]: Agent-side web_search resolves to "no provider available" while CLI infer web search and plugins inspect confirm Brave is loaded

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After hours of stable gateway uptime, the agent-embedded-run path resolves web_search to "no provider available" while openclaw plugins inspect brave reports the capability registered and openclaw infer web search returns real Brave results; only a full openclaw gateway restart returns the agent path to a working state.

Steps to reproduce

1. Install @openclaw/brave-plugin via npm. Configure plugins.entries.brave.config.webSearch with apiKey and mode: "web". Set tools.web.search.provider: "brave", tools.web.search.enabled: true, tools.profile: "full". Restart the gateway.
2. Confirm a clean baseline within ~10 minutes of the restart:
   • openclaw plugins inspect brave shows Status: loaded, Capabilities: web-search: brave
   • openclaw plugins doctor reports No plugin issues detected
   • openclaw infer web search --query "openclaw release notes" --limit 1 --provider brave returns a real result
   • openclaw infer web search --query "openclaw release notes" --limit 1 (auto-resolver, no explicit provider) also returns a real result
3. Leave the gateway running. After roughly 3 to 6 hours of uptime (no config changes, no plugin reloads, only normal channel watchdog reconnects), send a message through a channel that triggers an embedded agent run requiring web_search (e.g. "what is the latest news about X").
4. Observe the failure in the gateway log:

   error [tools] web_search failed: web_search is disabled or no provider is available.

1. While the gateway is still up (without restart), re-run step 2 from the CLI. The CLI path still works and returns real Brave results in under 1.5 seconds.
2. Run openclaw gateway restart. The agent path works again. Wait several hours. Step 3 reproduces.

Expected behavior

The agent-side capability resolver observes the same registered capabilities as plugins inspect brave and openclaw infer web. When web_search capability is registered globally, it is callable from the agent path with no operator action required and no time-based regression.

Actual behavior

The agent-side path and the CLI / plugins inspect path diverge while the gateway is still up. The agent sees web_search as having no provider available even though the global state still shows the Brave plugin loaded with Capabilities: web-search: brave. A full process restart of the gateway is the only thing that clears the agent-side state.

OpenClaw version

2026.5.2 (8b2a6e5)

Operating system

Ubuntu 22.04

Install method

npm (@openclaw/openclaw and @openclaw/brave-plugin). Gateway runs as a user systemd unit (openclaw-gateway.service).

Model

Bug reproduced under multiple models: primary openai-codex/gpt-5.5 in one occurrence, and an OpenRouter free model in another. The bug is model-independent. This suggests the issue is in the tool dispatcher layer that the agent harness uses, not in model-side tool selection.

Provider / routing chain

• Primary agent model: openai-codex/gpt-5.5 - Fallback chain: openai-codex/gpt-5.5 → ollama/qwen3.5:9b (local Ollama) - Tool provider for web_search: brave via @openclaw/brave-plugin - Embedding provider for memory search: openai/text-embedding-3-small

Additional provider/model setup details

• plugins.allow includes brave, whatsapp, telegram, slack, openrouter, google, openai, memory-core, ollama, memory-wiki.
• plugins.entries.brave.enabled: true.
• plugins.entries.brave.config.webSearch.mode: "web" (the v72-v92 fix is in place).
• plugins.entries.brave.config.webSearch.apiKey is set.
• tools.web.search is enabled: true, provider: "brave".
• agents.defaults.tools is not set (no per-agent override).
• agents.list[].tools is not set for any agent (no per-agent override).
• The coding profile is not in use here; tools.profile is "full".
• No tools.allow / tools.deny filters are configured anywhere.

Logs, screenshots, and evidence

Failing agent run (excerpted, timestamps preserved):


T+0:00:00  info  inbound message from channel
T+0:03:48  error [tools] web_search failed: web_search is disabled or no provider is available.
T+0:05:11  info  auto-reply sent (agent reported the tool was unavailable)


Same gateway uptime, CLI sanity check 5 minutes later:


$ openclaw plugins inspect brave
Status: loaded
Capabilities:
  web-search: brave

$ openclaw plugins doctor
No plugin issues detected.

$ openclaw infer web search --query "openclaw release notes" --limit 1 --provider brave
web.search via local
provider: brave
outputs: 1
{"result":{"provider":"brave","count":1,"tookMs":643,"results":[...]}}


`openclaw infer web providers` shows `brave` under `search` with `configured: true, selected: true`, alongside other unselected providers (perplexity, searxng, tavily, ollama). No conflicting selection.

Impact and severity

• Severity: high.
• Affects any embedded-run agent path that depends on web_search (channel-driven assistants in particular).
• User-visible symptom is the agent claiming the search tool is offline, which is misleading because the global tool registry still has it.
• The workaround (openclaw gateway restart) is disruptive in production: it ends active sessions and resets channel transports.
• Detection is awkward without a dedicated probe: plugins inspect and plugins doctor both report healthy while the agent path is broken.

Additional information

• We have observed the agent path break after both (a) an in-process hot reload triggered by openclaw config set plugins.entries.brave.config.webSearch.mode '"web"' (which the docs say to follow with a restart) and (b) without any apparent config change, after several hours of uptime where the only logged event was a normal WhatsApp watchdog timeout (app-silent) - restarting connection. So full gateway restart is sufficient to fix, but hot-reload is not the only trigger to break.
• Suggested log improvement: when the agent dispatcher fails to resolve a tool, include the size of the agent-visible tool registry at that moment, plus whether the relevant capability id was present. The current message does not distinguish "no plugin registered globally" from "plugin registered globally but agent registry stale."
• A docs note that hot-reload of plugins.entries.brave.config.webSearch.* does NOT re-register the web_search tool handler (full restart required) would also help operators avoid the more obvious half of this failure mode.