Agent web_search cannot see configured Brave provider, while CLI web search works

Summary

OpenClaw web search is configured with Brave and works through the CLI capability path, but the in-agent web_search tool fails in both the current session and fresh subagent sessions with:

web_search is disabled or no provider is available.

This also affects cron/agentTurn jobs, e.g. a healthcare scout cron that relies on agent web_search.

Environment

• OpenClaw: 2026.5.2
• Runtime: Gateway systemd service on Linux
• Model/session provider: openai-codex/gpt-5.5
• Configured search provider: Brave
• Brave plugin: enabled, source shown as external plugin path ~/.openclaw/npm/node_modules/@openclaw/brave-plugin/index.ts

Config shape

~/.openclaw/openclaw.json contains:

{
  "tools": {
    "web": {
      "search": {
        "provider": "brave",
        "enabled": true
      }
    }
  },
  "plugins": {
    "entries": {
      "brave": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "<redacted>"
          }
        }
      }
    }
  }
}

Docs indicate this is the recommended/canonical config path:

• tools.web.search.provider = "brave"
• plugins.entries.brave.config.webSearch.apiKey

Evidence

1. OpenClaw config sees Brave

openclaw config get tools.web.search

Output:

{
  "enabled": true,
  "provider": "brave"
}

openclaw config get plugins.entries.brave

Output shows Brave enabled and webSearch.apiKey present/redacted.

2. Direct Brave API works

A direct request to Brave Search API using the configured API key returns HTTP 200 and results.

Example result for query STAT AI medicine physician roles:

status: 200
results: 1
first: In real-world test, an AI model did better than doctors at diagnosing patients
url: https://www.npr.org/2026/04/30/nx-s1-5804474/ai-doctors-openai-patient-care-diagnosis

3. OpenClaw CLI capability path works

openclaw capability web providers

Shows Brave as:

{
  "available": true,
  "configured": true,
  "selected": true,
  "id": "brave",
  "envVars": ["BRAVE_API_KEY"]
}

openclaw capability web search --query "STAT AI medicine physician roles" --limit 2 --provider brave --json

Returns ok: true, provider: brave, and search results.

4. Agent tool path fails

Calling the in-agent web_search tool with:

{
  "query": "STAT AI medicine physician roles",
  "count": 3,
  "freshness": "week",
  "country": "US"
}

returns:

{
  "status": "error",
  "tool": "web_search",
  "error": "web_search is disabled or no provider is available."
}

This reproduces in:

• current Telegram direct agent session
• fresh isolated subagent session before Gateway restart
• fresh isolated subagent session after clean Gateway restart

5. Gateway restart did not fix it

After restart, Gateway service was active/running, but fresh agent web_search still failed with the same error.

Suspicion

There may be a difference between the CLI capability provider registry and the agent tool runtime provider registry.

In the installed bundle, runtime-QVGHfyAm.js appears to resolve agent web-search candidates with origin: "bundled" in the plugin provider path, while Brave is loaded as an external plugin from ~/.openclaw/npm/node_modules/@openclaw/brave-plugin/... even though it is an official plugin. CLI capability discovery sees Brave; agent web_search does not.

Relevant observed grep:

runtime-QVGHfyAm.js:56: origin: "bundled"
runtime-QVGHfyAm.js:95: origin: "bundled"
openclaw-tools-BDF6gNXk.js:9676: origin: "bundled"

I’m not certain this is the root cause, but it matches the split-brain behavior: CLI web capability sees Brave, agent web_search says no provider available.

Expected behavior

If openclaw capability web providers reports Brave as available/configured/selected, the in-agent web_search tool should also be able to use Brave, including inside cron agentTurn jobs.

Actual behavior

CLI capability web search works; in-agent web_search fails with no provider available.

Impact

Recurring agent jobs that need web search, such as news scouts, cannot use configured Brave search even though setup appears correct and CLI search succeeds.