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
- 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.
- 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
- 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").
- Observe the failure in the gateway log:
error [tools] web_search failed: web_search is disabled or no provider is available.
- 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.
- 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.
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_searchto "no provider available" whileopenclaw plugins inspect bravereports the capability registered andopenclaw infer web searchreturns real Brave results; only a fullopenclaw gateway restartreturns the agent path to a working state.Steps to reproduce
@openclaw/brave-pluginvia npm. Configureplugins.entries.brave.config.webSearchwithapiKeyandmode: "web". Settools.web.search.provider: "brave",tools.web.search.enabled: true,tools.profile: "full". Restart the gateway.openclaw plugins inspect braveshowsStatus: loaded,Capabilities: web-search: braveopenclaw plugins doctorreportsNo plugin issues detectedopenclaw infer web search --query "openclaw release notes" --limit 1 --provider bravereturns a real resultopenclaw infer web search --query "openclaw release notes" --limit 1(auto-resolver, no explicit provider) also returns a real resultweb_search(e.g. "what is the latest news about X").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 braveandopenclaw infer web. Whenweb_searchcapability 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 inspectpath diverge while the gateway is still up. The agent seesweb_searchas having no provider available even though the global state still shows the Brave plugin loaded withCapabilities: 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/openclawand@openclaw/brave-plugin). Gateway runs as a user systemd unit (openclaw-gateway.service).Model
Bug reproduced under multiple models: primary
openai-codex/gpt-5.5in 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
openai-codex/gpt-5.5- Fallback chain:openai-codex/gpt-5.5→ollama/qwen3.5:9b(local Ollama) - Tool provider forweb_search:bravevia@openclaw/brave-plugin- Embedding provider for memory search:openai/text-embedding-3-smallAdditional provider/model setup details
plugins.allowincludesbrave,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.apiKeyis set.tools.web.searchisenabled: true,provider: "brave".agents.defaults.toolsis not set (no per-agent override).agents.list[].toolsis not set for any agent (no per-agent override).codingprofile is not in use here;tools.profileis"full".tools.allow/tools.denyfilters are configured anywhere.Logs, screenshots, and evidence
Impact and severity
web_search(channel-driven assistants in particular).openclaw gateway restart) is disruptive in production: it ends active sessions and resets channel transports.plugins inspectandplugins doctorboth report healthy while the agent path is broken.Additional information
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 normalWhatsApp watchdog timeout (app-silent) - restarting connection. So full gateway restart is sufficient to fix, but hot-reload is not the only trigger to break.plugins.entries.brave.config.webSearch.*does NOT re-register theweb_searchtool handler (full restart required) would also help operators avoid the more obvious half of this failure mode.