openclaw - ✅(Solved) Fix [Bug]: plugins.entries.tavily.config.webSearch.apiKey accepts SecretRef in config validation but fails at runtime [3 pull requests, 1 participants]

Q: Expected behavior

If this field accepts `SecretRef` at config/schema validation time, it should also resolve successfully at runtime after gateway restart. Expected result: - no unresolved runtime snapshot error - Tavily should use the resolved API key normally

openclaw2026-04-17 07:22:24

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#68028•Fetched 2026-04-18 05:54:21

View on GitHub

Comments

Participants

Timeline

Reactions

Author

tunanet

Participants

tunanet

Timeline (top)

cross-referenced ×3labeled ×2referenced ×1subscribed ×1

Bug description plugins.entries.tavily.config.webSearch.apiKey accepts SecretRef during config validation, but fails at runtime with:

1. plugins.entries.tavily.config.webSearch.apiKey is unresolved in the active runtime snapshot

In the same config, other SecretRef-based fields work correctly, including:

gateway.auth.token
channels.telegram.botToken
plugins.entries.brave.config.webSearch.apiKey

This suggests Tavily has a runtime compatibility issue for this config path, or this path is not fully projected into the active runtime snapshot.

Error Message

[ws] ⇄ res ✗ secrets.resolve errorCode=UNAVAILABLE
Error: reply: plugins.entries.tavily.config.webSearch.apiKey is unresolved in the active runtime snapshot

Root Cause

Bug description plugins.entries.tavily.config.webSearch.apiKey accepts SecretRef during config validation, but fails at runtime with:

1. plugins.entries.tavily.config.webSearch.apiKey is unresolved in the active runtime snapshot

In the same config, other SecretRef-based fields work correctly, including:

gateway.auth.token
channels.telegram.botToken
plugins.entries.brave.config.webSearch.apiKey

This suggests Tavily has a runtime compatibility issue for this config path, or this path is not fully projected into the active runtime snapshot.

Fix Action

Fix / Workaround

As a workaround, changing only Tavily back to env interpolation resolves the issue:

After applying that workaround and restarting the gateway, the unresolved runtime error disappeared.

PR fix notes

PR #68038: fix: Tavily plugin SecretRef for webSearch.apiKey fails at runtime

Repository: openclaw/openclaw
Author: kagura-agent
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/68038

Description (problem / solution / changelog)

Problem

Tavily plugin's webSearch.apiKey accepts SecretRef during config validation but fails at runtime with unresolved in active runtime snapshot. Other plugins like Brave work fine with SecretRef.

Root Cause

Tavily's plugin manifest (openclaw.plugin.json) was missing the configContracts.compatibilityRuntimePaths declaration that registers it as a handler for the tools.web.search.apiKey compatibility runtime path. Brave and MiniMax already had this declaration.

Fix

Added the missing configContracts section to Tavily's plugin manifest and added a test to verify all web-search plugins declare compatible runtime paths.

Fixes #68028

Changed files

extensions/tavily/openclaw.plugin.json (modified, +3/-0)
src/plugins/manifest-registry.test.ts (modified, +18/-1)

PR #68040: fix: Tavily plugin SecretRef for webSearch.apiKey fails at runtime

Repository: openclaw/openclaw
Author: kagura-agent
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/68040

Description (problem / solution / changelog)

Problem

Tavily plugin's webSearch.apiKey accepts SecretRef during config validation but fails at runtime with unresolved in active runtime snapshot. Other plugins like Brave work fine with SecretRef.

Root Cause

Fix

Added the missing configContracts section to Tavily's plugin manifest and added a test to verify all web-search plugins declare compatible runtime paths.

Fixes #68028

Changed files

extensions/tavily/openclaw.plugin.json (modified, +3/-0)
src/plugins/manifest-registry.test.ts (modified, +18/-1)

PR #68424: fix(web-search): restore SecretRef runtime compatibility for bundled providers

Repository: openclaw/openclaw
Author: afurm
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/68424

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

Problem: several bundled web-search plugins accepted SecretRef objects for plugins.entries.<id>.config.webSearch.apiKey, but runtime compatibility lookup only registered Brave and MiniMax.
Why it matters: affected providers could validate config successfully and still fail at runtime with is unresolved in the active runtime snapshot.
What changed: added configContracts.compatibilityRuntimePaths: ["tools.web.search.apiKey"] to Exa, Firecrawl, Google/Gemini, Moonshot/Kimi, Perplexity, Tavily, and xAI/Grok, and added a manifest invariant test.
What did NOT change (scope boundary): no new secret surfaces, no runtime secret collector refactor, and no web-fetch compatibility changes.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #68028
Related #68040
This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

Root cause: affected plugin manifests allowed object-shaped plugin-scoped webSearch.apiKey values but did not declare tools.web.search.apiKey in configContracts.compatibilityRuntimePaths, so runtime compatibility-only resolution could not map the active provider back to those plugin-owned credential paths.
Missing detection / guardrail: there was no invariant test ensuring every bundled web-search provider with an object-shaped webSearch.apiKey config registered the compatibility runtime path.
Contributing context (if known): Brave and MiniMax already had the metadata, which made the manifest drift easy to miss until users configured the other providers with SecretRef.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/plugins/web-provider-public-artifacts.test.ts
Scenario the test should lock in: bundled web-search providers that declare object-shaped webSearch.apiKey config must be returned by resolveManifestContractPluginIdsByCompatibilityRuntimePath(..., "tools.web.search.apiKey").
Why this is the smallest reliable guardrail: the regression is manifest/registry metadata drift, so loading real bundled manifests is enough to catch it without live provider execution.
Existing test that already covers this (if any): none.
If no new test is added, why not: N/A

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

SecretRef values configured at plugins.entries.exa.config.webSearch.apiKey, plugins.entries.firecrawl.config.webSearch.apiKey, plugins.entries.google.config.webSearch.apiKey, plugins.entries.moonshot.config.webSearch.apiKey, plugins.entries.perplexity.config.webSearch.apiKey, plugins.entries.tavily.config.webSearch.apiKey, and plugins.entries.xai.config.webSearch.apiKey now resolve at runtime when the matching provider is active.
Brave and MiniMax behavior is unchanged; they already declared the compatibility path.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

Before:
[plugin manifest accepts SecretRef] -> [runtime asks for compatibility owners of tools.web.search.apiKey] -> [affected plugin missing from registry] -> [unresolved snapshot error]

After:
[plugin manifest accepts SecretRef] -> [runtime asks for compatibility owners of tools.web.search.apiKey] -> [affected plugin is registered] -> [plugin-scoped apiKey resolves]

Security Impact (required)

New permissions/capabilities? (Yes/No): No
Secrets/tokens handling changed? (Yes/No): Yes
New/changed network calls? (Yes/No): No
Command/tool execution surface changed? (Yes/No): No
Data access scope changed? (Yes/No): No
If any Yes, explain risk + mitigation: this only restores runtime compatibility for already-declared bundled webSearch.apiKey secret surfaces. It does not add new secret paths or widen provider access. The added invariant test prevents future manifest drift on this path.

Repro + Verification

Environment

OS: macOS
Runtime/container: local checkout on Node 22.22.0
Model/provider: N/A
Integration/channel (if any): bundled web-search providers
Relevant config (redacted): env secret provider allowlisting the provider key, tools.web.search.provider=<provider>, and plugins.entries.<plugin>.config.webSearch.apiKey=<SecretRef>

Steps

Configure plugins.entries.<plugin>.config.webSearch.apiKey as a SecretRef for an affected bundled web-search provider.
Set tools.web.search.provider to the matching provider and refresh the runtime snapshot (for example via gateway restart).
Trigger a web-search path using that provider.

Expected

The plugin-scoped API key resolves from the active runtime snapshot and web search proceeds.

Actual

Before this fix, affected providers could fail with plugins.entries.<plugin>.config.webSearch.apiKey is unresolved in the active runtime snapshot.

Evidence

Attach at least one:

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

Issue #68028 includes the runtime error logs. Focused regression coverage now passes locally.

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: ran pnpm test src/plugins/web-provider-public-artifacts.test.ts and pnpm test src/config/config.web-search-provider.test.ts; confirmed affected bundled manifests now register tools.web.search.apiKey compatibility ownership.
Edge cases checked: DuckDuckGo, SearXNG, and Ollama stay out of the compatibility set because they do not expose object-shaped webSearch.apiKey; Brave and MiniMax remain included.
What you did not verify: live end-to-end gateway restart and provider calls for each affected provider; full pnpm build completion in this environment.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

Risk: manifest-only compatibility registration could accidentally over-include providers that should not participate in tools.web.search.apiKey fallback.
- Mitigation: the regression test derives the expected set from real bundled manifests that explicitly accept object-shaped webSearch.apiKey values, so providers without that surface remain excluded.
Risk: full build was not completed in this environment.
- Mitigation: focused tests covering the touched manifest/config path passed, and the build blocker is documented as an unrelated environment issue (amazon-bedrock-mantle staging, then sharp postinstall requiring node-gyp).

Changed files

extensions/exa/openclaw.plugin.json (modified, +3/-0)
extensions/firecrawl/openclaw.plugin.json (modified, +3/-0)
extensions/google/openclaw.plugin.json (modified, +3/-0)
extensions/moonshot/openclaw.plugin.json (modified, +3/-0)
extensions/perplexity/openclaw.plugin.json (modified, +3/-0)
extensions/tavily/openclaw.plugin.json (modified, +3/-0)
extensions/xai/openclaw.plugin.json (modified, +3/-0)
src/plugins/web-provider-public-artifacts.test.ts (modified, +47/-0)

Code Example

{
  "secrets": {
    "providers": {
      "env": {
        "source": "env",
        "allowlist": [
          "OPENCLAW_GATEWAY_TOKEN",
          "TAVILY_API_KEY",
          "BRAVE_API_KEY",
          "TELEGRAM_BOT_TOKEN"
        ]
      }
    }
  }
}

---

{
  "plugins": {
    "entries": {
      "tavily": `{`
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": {
              "source": "env",
              "provider": "env",
              "id": "TAVILY_API_KEY"
            }
          }
        }
      }
    }
  }
}

---

{
  "plugins": {
    "entries": {
      "tavily": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "${TAVILY_API_KEY}"
          }
        }
      }
    }
  }
}

---



---

1. [ws] ⇄ res ✗ secrets.resolve errorCode=UNAVAILABLE
2. Error: reply: plugins.entries.tavily.config.webSearch.apiKey is unresolved in the active runtime snapshot

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

Summary

Bug description plugins.entries.tavily.config.webSearch.apiKey accepts SecretRef during config validation, but fails at runtime with:

1. plugins.entries.tavily.config.webSearch.apiKey is unresolved in the active runtime snapshot

In the same config, other SecretRef-based fields work correctly, including:

gateway.auth.token
channels.telegram.botToken
plugins.entries.brave.config.webSearch.apiKey

This suggests Tavily has a runtime compatibility issue for this config path, or this path is not fully projected into the active runtime snapshot.

Steps to reproduce

Add an env secrets provider:

{
  "secrets": {
    "providers": {
      "env": {
        "source": "env",
        "allowlist": [
          "OPENCLAW_GATEWAY_TOKEN",
          "TAVILY_API_KEY",
          "BRAVE_API_KEY",
          "TELEGRAM_BOT_TOKEN"
        ]
      }
    }
  }
}

Configure Tavily API key as SecretRef:

{
  "plugins": {
    "entries": {
      "tavily": `{`
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": {
              "source": "env",
              "provider": "env",
              "id": "TAVILY_API_KEY"
            }
          }
        }
      }
    }
  }
}

Validate config: openclaw config validate --json

Validation succeeds:

{"valid":true}

Restart gateway: openclaw gateway restart
Trigger a runtime path that resolves Tavily credentials.

Expected behavior

If this field accepts SecretRef at config/schema validation time, it should also resolve successfully at runtime after gateway restart.

Expected result:

no unresolved runtime snapshot error
Tavily should use the resolved API key normally

Actual behavior

Config validation succeeds and the gateway starts successfully, but runtime requests fail with:

plugins.entries.tavily.config.webSearch.apiKey is unresolved in the active runtime snapshot

The error repeats during runtime operations.

OpenClaw version

2026.4.15

Operating system

Ubuntu

Install method

npm node v24.14.1

Model

gpt-5.4

Provider / routing chain

openclaw-gpt 5.4

Additional provider/model setup details

In the same configuration, these fields worked correctly with SecretRef:

gateway.auth.token
channels.telegram.botToken
plugins.entries.brave.config.webSearch.apiKey

As a workaround, changing only Tavily back to env interpolation resolves the issue:

{
  "plugins": {
    "entries": {
      "tavily": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "${TAVILY_API_KEY}"
          }
        }
      }
    }
  }
}

After applying that workaround and restarting the gateway, the unresolved runtime error disappeared.

My current suspicion is that this path is accepted by validation, but not fully supported in runtime snapshot resolution.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Example runtime error:

1. [ws] ⇄ res ✗ secrets.resolve errorCode=UNAVAILABLE
2. Error: reply: plugins.entries.tavily.config.webSearch.apiKey is unresolved in the active runtime snapshot

Observed multiple times, for example around: 2026-04-17 06:53 UTC 2026-04-17 06:54 UTC 2026-04-17 06:55 UTC 2026-04-17 06:56 UTC Also observed during reload:

config change requires gateway restart (plugins.entries.tavily.config.webSearch.apiKey, plugins.entries.brave.config.webSearch.apiKey)

extent analysis

TL;DR

The most likely fix is to change the Tavily API key configuration to use env interpolation instead of SecretRef.

Guidance

The issue seems to be related to the runtime compatibility of the plugins.entries.tavily.config.webSearch.apiKey path with SecretRef, which is accepted during config validation but fails at runtime.
To verify the issue, try changing the Tavily API key configuration to use env interpolation, as shown in the provided workaround, and restart the gateway to see if the error resolves.
If the workaround resolves the issue, it may indicate that the plugins.entries.tavily.config.webSearch.apiKey path is not fully supported in runtime snapshot resolution.
Check the OpenClaw documentation to see if there are any known limitations or issues with using SecretRef for this specific configuration path.

Example

{
  "plugins": {
    "entries": {
      "tavily": {
        "enabled": true,
        "config": {
          "webSearch": {
            "apiKey": "${TAVILY_API_KEY}"
          }
        }
      }
    }
  }
}

Notes

The issue may be specific to the OpenClaw version (2026.4.15) or the provider/model setup (openclaw-gpt 5.4), and further investigation may be needed to determine the root cause.

Recommendation

Apply the workaround by changing the Tavily API key configuration to use env interpolation, as it has been shown to resolve the issue. This change allows the gateway to correctly resolve the API key at runtime.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

If this field accepts SecretRef at config/schema validation time, it should also resolve successfully at runtime after gateway restart.

Expected result:

no unresolved runtime snapshot error
Tavily should use the resolved API key normally

#api #runtime error #network issue #logging issue #authentication issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: plugins.entries.tavily.config.webSearch.apiKey accepts SecretRef in config validation but fails at runtime [3 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #68038: fix: Tavily plugin SecretRef for webSearch.apiKey fails at runtime

Description (problem / solution / changelog)

Problem

Root Cause

Fix

Changed files

PR #68040: fix: Tavily plugin SecretRef for webSearch.apiKey fails at runtime

Description (problem / solution / changelog)

Problem

Root Cause

Fix

Changed files

PR #68424: fix(web-search): restore SecretRef runtime compatibility for bundled providers

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Changed files

Code Example

Bug type

Beta release blocker

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING