Skip to content

fix(secrets): register secret targets for installed-origin plugins#104383

Closed
zw-xysk wants to merge 2 commits into
openclaw:mainfrom
zw-xysk:fix/secrets-installed-plugin-targets-104320
Closed

fix(secrets): register secret targets for installed-origin plugins#104383
zw-xysk wants to merge 2 commits into
openclaw:mainfrom
zw-xysk:fix/secrets-installed-plugin-targets-104320

Conversation

@zw-xysk

@zw-xysk zw-xysk commented Jul 11, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Fixes #104320

What Problem This Solves

After Exa moved from bundled origin to an installed plugin package, plugins.entries.exa.config.webSearch.apiKey disappeared from the gateway known-target registry. secrets.resolve rejects the CLI-discovered target with unknown target id, and infer web search fails before provider I/O.

Changes

  • Register web-provider and config secret targets from all active plugin manifest records, not only origin === "bundled".
  • Keep manifest-scoped entry creation (web-provider contract + sensitive hint, or declared secretInput paths).

Evidence

Head: 5071b3e0

Layer Case Result
L1 installed-origin (global) Exa record registers target id pass
L2 whole-path createSecretsHandlers + issue secrets.resolve params resolveSecrets reached, respond ok
L3 real extensions/exa/openclaw.plugin.json + issue gateway probe params (redacted) pass

L3 — issue probe with real Exa manifest (redacted)

Issue params (from #104320):

{
  "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"}
}

Capture (pnpm exec vitest run src/gateway/server-methods/secrets.installed-origin.test.ts -t "L3 live capture" --reporter=verbose):

[L3 proof #104320] manifest: extensions/exa/openclaw.plugin.json
[L3 proof #104320] installed-origin record: id=exa origin=global
[L3 proof #104320] main bundled-only filter would register: false
[L3 proof #104320] isKnownSecretTargetId(plugins.entries.exa.config.webSearch.apiKey): true
[L3 proof #104320] main (simulated): {"ok":false,"error":{"code":"INVALID_REQUEST","message":"invalid secrets.resolve params: unknown target id \"plugins.entries.exa.config.webSearch.apiKey\""}}
[L3 proof #104320] fix branch (this run, redacted): {"ok":true,"assignments":[{"path":"plugins.entries.exa.config.webSearch.apiKey","pathSegments":["plugins","entries","exa","config","webSearch","apiKey"],"value":"[REDACTED]"}],"diagnostics":[],"inactiveRefPaths":[]}

Tests

pnpm exec vitest run src/secrets/target-registry-data.current-snapshot.test.ts src/gateway/server-methods/secrets.installed-origin.test.ts
→ 4 passed (2 files; L3 test runs in gateway vitest projects)

@clawsweeper re-review

sm and others added 2 commits July 11, 2026 17:43
sm @cursoragent sm
fix(secrets): register secret targets for installed-origin plugins
d92f8a0 
Fixes openclaw#104320

Include installed/global plugin manifest records in the web-provider and
config secret target registry so gateway secrets.resolve accepts Exa
SecretRef targets after the web provider split out of bundled origin.

Proof: whole-path secrets.resolve handler test with issue params + L3
vitest capture (installed-origin global Exa metadata).

Co-authored-by: Cursor <[email protected]>
sm @cursoragent sm
test(secrets): add L3 proof for installed-origin Exa secrets.resolve
5071b3e 
Capture redacted gateway probe output using the real Exa manifest and
the issue's exact secrets.resolve params, including main-vs-fix contrast.

Co-authored-by: Cursor <[email protected]>
@zw-xysk
zw-xysk requested a review from a team as a code owner July 11, 2026 10:02
@openclaw-barnacle openclaw-barnacle Bot added gateway Gateway runtime size: M labels Jul 11, 2026
@clawsweeper clawsweeper Bot mentioned this pull request Jul 11, 2026
Merged
@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P1 High-priority user-facing bug, regression, or broken workflow. labels Jul 11, 2026
@clawsweeper

clawsweeper Bot commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

A smaller open PR is now a viable, proof-positive landing path for the same fix. This branch’s unique remainder is a mock-based capture harness that does not preserve distinct production behavior or real integration coverage, so maintaining two candidates would add review and maintenance churn.

Root-cause cluster
Relationship: superseded
Canonical: #104347
Summary: The smaller open PR is a viable, proof-positive canonical landing path for the same regression and production change.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Canonical path: Land #104347 as the focused manifest-scoped fix, retain its real installed-plugin proof, and avoid carrying this branch’s simulated capture harness unless a later narrow test demonstrates a distinct regression boundary.

So I’m closing this here and keeping the remaining discussion on #104347.

Review details

Best possible solution:

Land #104347 as the focused manifest-scoped fix, retain its real installed-plugin proof, and avoid carrying this branch’s simulated capture harness unless a later narrow test demonstrates a distinct regression boundary.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main’s bundled-origin filter excludes the installed Exa target, and the canonical report plus the replacement PR’s real installed-package proof establish the failure path with high confidence.

Is this the best way to solve the issue?

No for this branch as the landing candidate. The same production repair is available in a smaller open PR with stronger real behavior proof, while this branch’s unique test is simulated and redundant.

Security review:

Security review cleared: The shared production fix keeps target IDs constrained to each plugin’s manifest-declared config namespace and adds no dependency, permission, or executable supply-chain surface.

AGENTS.md: found and applied where relevant.

What I checked:

Likely related people:

  • vincentkoc: Authored the current plugin-derived secret target registry and bundled-origin filtering behavior modified by both candidate PRs. (role: introduced behavior; confidence: high; commits: 50429157e38d; files: src/secrets/target-registry-data.ts, src/secrets/target-registry-query.ts, src/plugins/plugin-metadata-snapshot.ts)
  • joshavant: Introduced earlier broad SecretRef credential coverage that established the gateway known-target validation path affected by this regression. (role: adjacent feature owner; confidence: medium; commits: 806803b7efe2; files: src/secrets/target-registry-query.ts, src/gateway/server-methods/secrets.ts)

Codex review notes: model internal, reasoning high; reviewed against cbc84767bd7e.

@zw-xysk zw-xysk closed this Jul 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

gateway Gateway runtime P1 High-priority user-facing bug, regression, or broken workflow. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. size: M status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[Bug]: infer web search rejects installed Exa plugin SecretRef target as unknown

1 participant

@zw-xysk