Summary

The command SecretRef fix from #82621 appears to have regressed in OpenClaw 2026.6.11 after the web provider was split into its installed plugin package. The CLI discovers the concrete Exa credential target, but the gateway rejects that target id as unknown, so local fallback reaches the provider with an unresolved SecretRef.

Live reproduction on macOS 26.5.0, with CLI and gateway both 2026.6.11:

• tools.web.search.provider is exa.
• plugins.entries.exa.config.webSearch.apiKey is an exec SecretRef.
• openclaw plugins list --json reports @openclaw/exa-plugin 2026.6.11 loaded, enabled, and advertising webSearchProviderIds: ["exa"].
• Gateway startup succeeds and openclaw secrets audit --allow-exec --json reports unresolvedRefCount: 0, skippedExecRefs: 0, and resolvabilityComplete: true.
• openclaw infer web search --provider exa --query 'site:openclaw.ai OpenClaw' --limit 1 --json fails before provider I/O with UnresolvedSecretInputError for plugins.entries.exa.config.webSearch.apiKey.

The gateway-side failure is more specific. This redacted probe:

openclaw gateway call secrets.resolve --json --params '{
  "commandName":"infer web search",
  "targetIds":["plugins.entries.exa.config.webSearch.apiKey"],
  "allowedPaths":["plugins.entries.exa.config.webSearch.apiKey"],
  "forcedActivePaths":["plugins.entries.exa.config.webSearch.apiKey"],
  "providerOverrides":{"webSearch":"exa"}
}'

returns:

{
  "ok": false,
  "error": {
    "code": "INVALID_REQUEST",
    "message": "invalid secrets.resolve params: unknown target id \"plugins.entries.exa.config.webSearch.apiKey\""
  }
}

No credential value was printed or included in this report. The same Keychain-backed credential succeeds in a direct, no-output Exa API probe, so this is command target registration/resolution rather than provider authentication.

Expected

infer web search should resolve the selected installed plugin's credential from the active gateway snapshot and reach Exa provider I/O, as #82798 intended.

Actual

The gateway rejects the installed plugin target id as unknown; the command then fails with an unresolved SecretRef before provider I/O.

Likely seam

The CLI discovers the concrete Exa plugin credential target, while the gateway's isKnownSecretTargetId registry does not know the installed plugin-provided target id.

Related

• Regression of Bug: CLI web search does not resolve plugin-scoped webSearch SecretRefs #82621 / Fix infer SecretRef resolution for provider-backed commands #82798.