Secrets: add Exa web-search SecretRef target by KnightNiwrem · Pull Request #65833 · openclaw/openclaw

KnightNiwrem · 2026-04-13T09:16:01Z

Summary

Problem: Exa exposes plugins.entries.exa.config.webSearch.apiKey, but the canonical SecretRef target registry omitted that path.
Why it matters: users cannot target Exa's web-search API key through the SecretRef contract surfaces that drive discovery, auditing, and related tooling.
What changed: added plugins.entries.exa.config.webSearch.apiKey to src/secrets/target-registry-data.ts.
What did NOT change (scope boundary): this PR does not update the secops-owned docs/reference/secretref-credential-surface.md page or its generated matrix artifacts.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Feature]: Add Exa apiKey to secretRef #65791
Related [Feature]: Add Exa apiKey to secretRef #65791
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: the SecretRef registry's bundled web-search entries were maintained manually and Exa's plugin-owned credential path was never added there.
Missing detection / guardrail: there was no contract-level guardrail ensuring every bundled web-search provider credential path is represented in the canonical SecretRef registry.
Contributing context (if known): runtime/provider surfaces already knew about Exa's credential path, so the omission was isolated to the central SecretRef contract surface.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: a contract/seam test that compares bundled web-search provider credential paths against the SecretRef registry.
Scenario the test should lock in: every bundled web-search provider that declares a SecretRef-capable credential path is also present in the canonical SecretRef target registry.
Why this is the smallest reliable guardrail: this bug is a registry/provider contract mismatch rather than logic local to a single helper.
Existing test that already covers this (if any): none that specifically enforce provider-to-registry parity for bundled web-search credentials.
If no new test is added, why not: I intentionally removed the one-off Exa-specific assertion to preserve the current broad-coverage testing pattern instead of adding a provider-specific special case.

User-visible / Behavior Changes

Users can now target Exa's web-search API key through the canonical SecretRef contract surface at plugins.entries.exa.config.webSearch.apiKey.

Diagram (if applicable)

N/A

Security Impact (required)

New permissions/capabilities? (Yes/No) No
Secrets/tokens handling changed? (Yes/No) No
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:

Repro + Verification

Environment

OS: Linux
Runtime/container: local repo checkout
Model/provider: N/A
Integration/channel (if any): N/A
Relevant config (redacted): plugins.entries.exa.config.webSearch.apiKey configured as a SecretRef target path

Steps

Inspect the SecretRef target registry entries for bundled web-search providers.
Compare them with the Exa web-search provider contract, which advertises plugins.entries.exa.config.webSearch.apiKey.
Run pnpm test src/secrets/target-registry.test.ts after the registry change.

Expected

Exa's credential path is part of the canonical SecretRef registry.
The targeted SecretRef registry test passes.

Actual

After the change, Exa's credential path is in the registry and the targeted test passes.

Evidence

Attach at least one:

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

Human Verification (required)

Verified scenarios: confirmed the registry now includes plugins.entries.exa.config.webSearch.apiKey; reran pnpm test src/secrets/target-registry.test.ts successfully.
Edge cases checked: removed the Exa-specific unit assertion to keep test coverage aligned with the repo's current broad-pattern testing style.
What you did not verify: I did not update or regenerate the secops-owned SecretRef reference docs/matrix files in this PR.

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/No) Yes
Config/env changes? (Yes/No) No
Migration needed? (Yes/No) No
If yes, exact upgrade steps:

Risks and Mitigations

Risk: the docs/reference SecretRef surface remains out of sync with the code contract until a secops-approved docs follow-up lands.
- Mitigation: this PR keeps the code fix minimal and explicitly calls out the remaining docs gap for a separate owner-approved follow-up.

greptile-apps · 2026-04-13T09:17:17Z

Greptile Summary

Adds the missing plugins.entries.exa.config.webSearch.apiKey entry to CORE_SECRET_TARGET_REGISTRY in src/secrets/target-registry-data.ts. The new entry is correctly structured, matches the credentialPath declared in extensions/exa/src/exa-web-search-provider.ts, and is consistent with all other webSearch.apiKey entries in the registry.

Confidence Score: 5/5

Safe to merge — minimal, additive registry entry with no behavioral risk.

Single-line registry addition that exactly mirrors established patterns; verified against the Exa plugin's declared credentialPath. All required fields are present and correct. No logic changes, no security surface changes.

No files require special attention.

_{Reviews (1): Last reviewed commit: "Tests: keep SecretRef registry coverage ..." | Re-trigger Greptile}

Copilot

Pull request overview

This PR updates the canonical SecretRef target registry to include Exa’s web-search API key path so that SecretRef discovery/auditing/tooling can target plugins.entries.exa.config.webSearch.apiKey.

Changes:

Add plugins.entries.exa.config.webSearch.apiKey as a SecretTargetRegistryEntry in the core registry list.

Copilot · 2026-04-13T09:21:14Z

+    id: "plugins.entries.exa.config.webSearch.apiKey",
+    targetType: "plugins.entries.exa.config.webSearch.apiKey",
+    configFile: "openclaw.json",
+    pathPattern: "plugins.entries.exa.config.webSearch.apiKey",
+    secretShape: SECRET_INPUT_SHAPE,
+    expectedResolvedValue: "string",
+    includeInPlan: true,
+    includeInConfigure: true,
+    includeInAudit: true,
+  },
  {


Adding this new SecretRef registry entry will change the generated SecretRef credential matrix produced by buildSecretRefCredentialMatrix(), but docs/reference/secretref-user-supplied-credentials-matrix.json (and the supported/unsupported lists in docs/reference/secretref-credential-surface.md) do not include this new path yet. This will cause src/secrets/target-registry.docs.test.ts to fail unless the docs artifacts are regenerated/updated in the same PR (or the sync guardrail is adjusted).

Suggested change

id: "plugins.entries.exa.config.webSearch.apiKey",

targetType: "plugins.entries.exa.config.webSearch.apiKey",

configFile: "openclaw.json",

pathPattern: "plugins.entries.exa.config.webSearch.apiKey",

secretShape: SECRET_INPUT_SHAPE,

expectedResolvedValue: "string",

includeInPlan: true,

includeInConfigure: true,

includeInAudit: true,

},

{

joshavant · 2026-04-14T23:11:40Z

Thanks for the Exa contribution, @KnightNiwrem.

Outcome: this PR is superseded by #66818, which merged this change in the broader SecretRef contract update.

Why #66818 covers this: it adds plugins.entries.exa.config.webSearch.apiKey to the canonical registry and updates the credential-surface docs/matrix.

KnightNiwrem added 2 commits April 13, 2026 08:43

Secrets: add Exa web-search SecretRef target

010703e

Tests: keep SecretRef registry coverage pattern broad

58d5565

KnightNiwrem requested a review from a team as a code owner April 13, 2026 09:16

Copilot AI review requested due to automatic review settings April 13, 2026 09:16

openclaw-barnacle Bot added the size: XS label Apr 13, 2026

Copilot started reviewing on behalf of KnightNiwrem April 13, 2026 09:16 View session

Copilot AI reviewed Apr 13, 2026

View reviewed changes

joshavant mentioned this pull request Apr 14, 2026

fix(secrets): align SecretRef inspect/strict behavior across preload/runtime paths #66818

Merged

25 tasks

joshavant closed this Apr 14, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Secrets: add Exa web-search SecretRef target#65833

Secrets: add Exa web-search SecretRef target#65833
KnightNiwrem wants to merge 2 commits intoopenclaw:mainfrom
KnightNiwrem:fix/exa-secretref-65791

KnightNiwrem commented Apr 13, 2026

Uh oh!

greptile-apps Bot commented Apr 13, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 13, 2026

Uh oh!

joshavant commented Apr 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

KnightNiwrem commented Apr 13, 2026

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

Uh oh!

greptile-apps Bot commented Apr 13, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

joshavant commented Apr 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants