Summary

• Problem: local infer provider-backed commands could instantiate providers against raw config before command SecretRefs were resolved.
• Why it matters: plugin-scoped web search/fetch credential refs could pass secrets audit but fail at runtime with unresolved SecretRef errors.
• What changed: resolve command SecretRefs before local provider execution, scope web credential targets to the selected provider/fallback, and let web search use the explicitly resolved CLI config.
• What did NOT change: no legacy config migration and no successful live Tavily query is claimed without a real key.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Bug: CLI web search does not resolve plugin-scoped webSearch SecretRefs #82621
• This PR fixes a bug or regression

Real behavior proof

Behavior addressed: CLI web search resolves plugin-scoped webSearch.apiKey SecretRefs before invoking the local provider.

Real environment tested: AWS Crabbox Linux, provider aws, lease cbx_b66e354b1546, run run_71a9ceeecc03, isolated OpenClaw config and gateway.

Exact steps or command run after this patch: configured Tavily plugin plugins.entries.tavily.config.webSearch.apiKey as an env SecretRef, started a local gateway, then ran infer web search --provider tavily --query ping --limit 1 --json using a dummy TAVILY_API_KEY.

Evidence after fix: AWS proof output showed ASSERT_UNRESOLVED_SECRETREF=absent and GATEWAY_SECRETS_RESOLVE_SEEN=1; the command reached Tavily and returned 401 Unauthorized: missing or invalid API key, which is expected for the dummy key.

Observed result after fix: the command crossed the SecretRef resolution boundary and failed only at provider auth with the intentionally fake key.

What was not tested: a successful live Tavily result with a real Tavily API key.

Before evidence: current-main AWS repro on bea4f0d2f4b48ddd62db45970e513441e9af8f98 failed with unresolved SecretRef "env:default:TAVILY_API_KEY" while secrets audit reported unresolved=0.

Root Cause

• Root cause: local provider-backed infer paths read raw getRuntimeConfig() and constructed providers directly, bypassing the command SecretRef resolver used by other command surfaces.
• Missing detection / guardrail: command-secret resolution coverage did not include src/cli/capability-cli.ts, and web search runtime could prefer a stale runtime snapshot over the resolved CLI config.
• Contributing context: web search/fetch need provider-specific credential target scoping so unrelated configured refs do not block a selected provider.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
• Target test or file: src/cli/capability-cli.test.ts, src/cli/command-secret-targets.test.ts, src/web-search/runtime.test.ts, src/cli/command-secret-resolution.coverage.test.ts.
• Scenario the test should lock in: local infer commands resolve command SecretRefs before provider construction and web search/fetch target only selected-provider credential paths.
• Why this is the smallest reliable guardrail: it exercises the CLI boundary, command target selection, and web-search runtime snapshot behavior without requiring a live provider key.
• Existing test that already covers this (if any): none covered this exact local infer SecretRef bypass.

User-visible / Behavior Changes

Local infer provider-backed commands can now use command SecretRefs before provider execution. Web search/fetch plugin-scoped credentials work through the selected provider path.

Diagram

Before:
infer web search -> raw config -> provider reads unresolved SecretRef -> failure

After:
infer web search -> command SecretRef resolver -> resolved config -> provider auth/network

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? Yes
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: command-scoped SecretRefs are resolved earlier for local provider execution using the existing command resolver and selected-provider allowedPaths, limiting resolution to the relevant credential paths.

Repro + Verification

Environment

• OS: macOS local targeted tests; Linux AWS Crabbox and Blacksmith Testbox remote proof
• Runtime/container: Node 22, pnpm 11.1.0
• Model/provider: Tavily web search with dummy key for auth-boundary proof
• Integration/channel (if any): Web search
• Relevant config (redacted): Tavily plugin webSearch.apiKey as env SecretRef TAVILY_API_KEY

Steps

1. Configure plugin-scoped Tavily webSearch.apiKey as an env SecretRef.
2. Start the gateway from that config.
3. Run infer web search --provider tavily --query ping --limit 1 --json.

Expected

• No unresolved SecretRef error; with a dummy key, provider auth should fail after resolution.

Actual

• AWS proof returned Tavily 401 for the dummy key, with unresolved SecretRef absent and secrets.resolve observed in gateway logs.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: focused local tests, Testbox pnpm check:changed, AWS E2E reproduction of the CLI/gateway/provider path.
• Edge cases checked: selected provider credential scoping, Gemini model-provider fallback, Firecrawl webFetch/webSearch fallback, external provider owner mapping, stale web-search runtime snapshot handling.
• What you did not verify: successful Tavily live search with a real key.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: resolving too many unrelated credential refs for web commands could block selected-provider usage.
  • Mitigation: web search/fetch target selection now scopes allowedPaths to selected provider credentials and known same-provider fallbacks.