Summary

openclaw infer web search does not resolve plugin-scoped web search SecretRefs before reading config, even when the active gateway runtime has a healthy secrets snapshot and secrets audit reports no unresolved refs.

This breaks CLI web search with SecretRef-managed provider keys.

Version

• OpenClaw: 2026.5.12 (f066dd2)
• OS: macOS 26.3.1 arm64
• Node: 25.8.1

Config shape

Relevant config is using the documented structured SecretRef shape:

{
  "secrets": {
    "providers": {
      "default": { "source": "env" }
    },
    "defaults": { "env": "default" }
  },
  "tools": {
    "web": {
      "search": {
        "enabled": true,
        "provider": "tavily"
      }
    }
  },
  "plugins": {
    "entries": {
      "tavily": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": { "source": "env", "provider": "default", "id": "TAVILY_API_KEY" }
          }
        }
      },
      "google": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": { "source": "env", "provider": "default", "id": "GEMINI_API_KEY" },
            "model": "gemini-2.5-flash"
          }
        }
      },
      "brave": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": { "source": "env", "provider": "default", "id": "BRAVE_API_KEY" }
          }
        }
      }
    }
  }
}

The relevant env vars exist in the gateway service env.

Expected behavior

With tools.web.search.provider = "tavily", openclaw infer web search --provider tavily ... should resolve plugins.entries.tavily.config.webSearch.apiKey from the active gateway runtime snapshot and run the search.

Non-selected provider refs such as plugins.entries.google.config.webSearch.apiKey should remain inactive/non-fatal, per docs.

Actual behavior

Repro command:

openclaw infer web search --provider tavily --query 'ping' --limit 1 --json

Output:

Error: plugins.entries.tavily.config.webSearch.apiKey unresolved SecretRef "env:default:TAVILY_API_KEY=*** Resolve this command against an active gateway runtime snapshot before reading it.

Exit code: 1

For comparison:

openclaw secrets audit --check --json

Reports:

{
  "status": "findings",
  "summary": {
    "plaintextCount": 13,
    "unresolvedRefCount": 0,
    "shadowedRefCount": 0,
    "legacyResidueCount": 1
  },
  "resolution": {
    "refsChecked": 8,
    "skippedExecRefs": 0,
    "resolvabilityComplete": true
  }
}

So the configured SecretRefs are resolvable at audit/runtime level; the failure is specific to this CLI web-search path.

Log evidence

For an exact repro, I marked the gateway log offset, ran the command once, then captured the gateway log window. The window contained only the local exec lines and no matching secrets.resolve RPC for this command.

That suggests infer web search is reading config before successfully resolving command secrets against the active gateway snapshot, or otherwise not attempting the expected gateway secret resolution path.

Separate related noise observed earlier:

[secrets] plugins.entries.google.config.webSearch.apiKey: tools.web.search.provider is "tavily".
[secrets] agent: gateway secrets.resolve unavailable (secrets.resolve failed); attempted local command-secret resolution.

The Google/Gemini ref is inactive because Tavily is explicitly selected, which matches docs, but it still appears in diagnostics/noise around command SecretRef resolution.

Notes

• openclaw config validate passes.
• openclaw status --all shows channels OK and no secret diagnostics.
• openclaw secrets audit reports unresolvedRefCount: 0.
• The Tavily SecretRef is on the documented canonical surface: plugins.entries.tavily.config.webSearch.apiKey.