PR #1: Secrets: add Exa web-search SecretRef target

• Repository: KnightNiwrem/openclaw
• Author: KnightNiwrem
• State: open | merged: False
• Link: https://github.com/KnightNiwrem/openclaw/pull/1

Description (problem / solution / changelog)

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)

• 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 #
• Related openclaw/openclaw#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

1. Inspect the SecretRef target registry entries for bundled web-search providers.
2. Compare them with the Exa web-search provider contract, which advertises plugins.entries.exa.config.webSearch.apiKey.
3. 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.

<!-- This is an auto-generated description by cubic. -->

---

Summary by cubic

Add the missing SecretRef target for Exa web search so teams can plan/configure/audit the API key via the canonical registry. Related to openclaw/openclaw#65791.

• Bug Fixes
  • Registered plugins.entries.exa.config.webSearch.apiKey in src/secrets/target-registry-data.ts with plan/configure/audit enabled.

^{Written for commit 58d5565e006d8e2c528e48ba265904b866bdbf09. Summary will update on new commits.}

<!-- End of auto-generated description by cubic. --> <!-- This is an auto-generated comment: release notes by coderabbit.ai -->

Summary by CodeRabbit

• New Features
  • Added support for managing Exa web search API key configuration in the system settings.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Changed files

• src/secrets/target-registry-data.ts (modified, +11/-0)

---

PR #65833: Secrets: add Exa web-search SecretRef target

• Repository: openclaw/openclaw
• Author: KnightNiwrem
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/65833

Description (problem / solution / changelog)

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)

• 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 #65791
• Related #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

1. Inspect the SecretRef target registry entries for bundled web-search providers.
2. Compare them with the Exa web-search provider contract, which advertises plugins.entries.exa.config.webSearch.apiKey.
3. 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.

Changed files

• src/secrets/target-registry-data.ts (modified, +11/-0)

---

PR #66007: feat(exa): add secretRef support for web search API key

• Repository: openclaw/openclaw
• Author: Rohan5commit
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/66007

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: Exa already supports plugins.entries.exa.config.webSearch.apiKey at runtime, but the secret target registry and bundled public contract did not expose that path.
• Why it matters: users could not supply the Exa web search API key through secretRef-aware flows the way they can for other bundled web search providers.
• What changed: added the Exa web-search contract artifact, registered the Exa API-key secret target for planning/configure/audit flows, and regenerated the secretRef credential matrix/docs.
• What did NOT change (scope boundary): Exa request execution, provider selection behavior, and network calls are unchanged.
• AI-assisted: Yes, built with Codex. Testing: lightly tested locally with focused contract/registry coverage.

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 #65791
• Related #65791
• 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: the Exa provider declared its runtime credentialPath, but the bundled public contract surface and the core secret target registry did not publish that path.
• Missing detection / guardrail: generic registry/docs checks existed, but Exa had never been wired into those secretRef surfaces.
• Contributing context (if known): parity drift versus other bundled web search providers.

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:
  • extensions/exa/src/exa-web-search-provider.test.ts
  • src/plugins/contracts/web-search-provider.exa.contract.test.ts
  • src/plugins/contracts/plugin-registration.exa.contract.test.ts
  • src/secrets/target-registry.docs.test.ts
  • src/secrets/exec-secret-ref-id-parity.test.ts
  • src/cli/command-secret-targets.test.ts
• Scenario the test should lock in: Exa publishes a bundled web-search contract surface and its API-key path appears in secretRef discovery/docs and agent-runtime target selection.
• Why this is the smallest reliable guardrail: these suites already exercise the shared registry, docs generation, and bundled plugin contract loading paths used by every provider.
• Existing test that already covers this (if any): the files above once the Exa secret target is registered.
• If no new test is added, why not: existing generic coverage already fails when this surface is missing and passes once it is wired correctly.

User-visible / Behavior Changes

• plugins.entries.exa.config.webSearch.apiKey now participates in secretRef-aware config flows and appears in the generated secretRef credential documentation.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? (Yes/No) Yes
• 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 adds Exa's existing API-key path to the same secretRef plumbing already used by other bundled web-search providers. Resolution still goes through the existing secret-input validation, registry, and audit/configure paths.

Repro + Verification

Environment

• OS: macOS arm64
• Runtime/container: Node v25.7.0, pnpm 10.32.1
• Model/provider: N/A
• Integration/channel (if any): Exa bundled web search provider
• Relevant config (redacted): plugins.entries.exa.config.webSearch.apiKey

Steps

1. Generate the secretRef credential matrix from the current registry.
2. Inspect the bundled Exa web-search contract + agent-runtime secret target list.
3. Run the focused Exa contract/registry Vitest suite.

Expected

• Exa's API-key path is present in the generated matrix and agent-runtime target set.
• Bundled Exa contract loading succeeds.
• Focused tests pass.

Actual

• Verified all three locally.

Evidence

Attach at least one:

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

Human Verification (required)

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

• Verified scenarios: regenerated docs/reference/secretref-user-supplied-credentials-matrix.json; confirmed plugins.entries.exa.config.webSearch.apiKey is present in both buildSecretRefCredentialMatrix() and getAgentRuntimeCommandSecretTargetIds(); ran the focused Vitest suite listed above.
• Edge cases checked: ensured the docs generator output is stable and the Exa surface loads through the bundled contract path instead of runtime-only registration.
• What you did not verify: full pnpm build && pnpm check && pnpm test across the entire monorepo.

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:

Risks and Mitigations

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

• Risk: secretRef/documentation parity could drift again if Exa's credential path changes in only one layer.
  • Mitigation: this wires Exa into the shared bundled contract surface and shared secret registry, and the existing registry/docs test suite now exercises that path.

Changed files

• docs/reference/secretref-credential-surface.md (modified, +1/-0)
• docs/reference/secretref-user-supplied-credentials-matrix.json (modified, +7/-0)
• extensions/exa/web-search-contract-api.ts (added, +29/-0)
• src/cli/command-secret-targets.ts (modified, +1/-0)
• src/secrets/target-registry-data.ts (modified, +11/-0)