Summary

reply-path secrets.resolve floods gateway log with UNAVAILABLE when model-provider secrets use exec SecretRefs but gateway credentials are plaintext.

• Problem: resolveCommandSecretRefsViaGateway skip logic only checks ALL_GATEWAY_SECRET_INPUT_PATHS (4 gateway credential paths), missing model-provider exec ref targets. Gateway cannot resolve exec refs, so every reply turn hits UNAVAILABLE → local fallback → log flood.
• Solution: Collect active exec target ref paths (not just discovered ones) and merge into the skip check alongside gateway credential exec refs. The target-exec collection is gated behind resolutionPolicy.allowExecSecretRefs and filtered to active command targets only, so inactive exec refs do not bypass gateway snapshot resolution for unrelated active targets.
• What changed: src/cli/command-secret-gateway.ts (new collectActiveExecTargetRefPaths helper with activeConfiguredRefPaths filter, classifyConfiguredTargetRefs now returns activeConfiguredRefPaths, skip condition extended, gated behind resolutionPolicy.allowExecSecretRefs) and src/cli/command-secret-gateway.test.ts (3 new/updated tests including mixed-target regression test).
• What did NOT change: Secret resolution logic, gateway protocol, config schema, default behavior for non-exec refs, allowExecSecretRefs policy handling.
• ClawSweeper P1/P2 addressed: collectActiveExecTargetRefPaths is gated by resolutionPolicy.allowExecSecretRefs and filtered to active command refs only — no-local-exec callers still attempt gateway, inactive exec refs do not poison skip decisions.

Change Type (select all)

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

Scope (select all)

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

Linked Issue/PR

• Related to [Bug]: reply-path secrets.resolve floods gateway log with UNAVAILABLE for model-provider exec SecretRefs (degrades correctly, ~1 line/turn) #96653
• This PR fixes a bug or regression

Motivation

When a user configures model-provider secrets with source: "exec" (e.g. models.providers.openai.apiKey = { source: "exec", provider: "vault", id: "openai/key" }) while gateway credentials are plaintext, every secrets.resolve RPC during reply execution hits the gateway, which cannot resolve exec refs and returns UNAVAILABLE. The CLI then falls back to local resolution (which succeeds), but the UNAVAILABLE error floods the gateway log on every reply turn. This is pure noise: the skip logic already existed for the case where gateway credentials themselves use exec refs, but was scoped too narrowly and did not filter inactive exec refs.

Real behavior proof

Behavior addressed: Gateway log flooded with secrets.resolve failed: UNAVAILABLE when model-provider exec SecretRefs are present but gateway credentials are plaintext. Additionally, inactive exec refs in mixed target sets must not trigger the skip.

Real environment tested: Linux x64, Node v22.11.0, branch fix/secrets-resolve-exec-skip-96653

Exact steps or command run after this patch:

cd openclaw && pnpm build cliStartup
# Run dist bundle proof script covering 3 scenarios
node --experimental-require-module pr-96661-evidence/proof-v2.mjs
# Run unit tests including mixed-target regression test
pnpm test src/cli/command-secret-gateway.test.ts -- --run

Evidence after fix:

Live dist bundle proof (production built code, real exec child process) — 3 scenarios:

========================================================================
  LIVE PROOF — PR #96661 (P1 fix: filter inactive exec refs)
========================================================================
Node: v22.11.0
Dist: dist/command-secret-gateway-C2q_A88T.js

[A] Active exec ref target → skip gateway RPC
------------------------------------------------------------
  Gateway skipped: ✅ YES
  Exec provider ran: ✅ YES
  Targets: {"talk.providers.acme-speech.apiKey":"resolved_local"}
  Diagnostic: talk reply: skipped gateway secrets.resolve because
    SecretRefs use exec providers at talk.providers.acme-speech.apiKey;
    rerun with --allow-exec to execute configured exec providers.

[B] Active env ref (no exec refs) → gateway called
------------------------------------------------------------
  Gateway skipped (should be NO): ✅ NO
  Gateway attempted: ✅ YES
  Targets: {"talk.providers.acme-speech.apiKey":"unresolved"}

[C] no-local-exec policy → gateway attempted (not skipped)
------------------------------------------------------------
  Gateway skipped: ✅ NO (correct)
  Gateway attempted: ✅ YES
  Targets: {"talk.providers.acme-speech.apiKey":"unresolved"}
  Diagnostics: doctor preview: skipped local exec SecretRef resolution...;
    doctor preview: gateway secrets.resolve unavailable...;
    attempted local command-secret resolution.

========================================================================
  SUMMARY
========================================================================
✅ ALL SCENARIOS PASS

  [A] Active exec ref → skip gateway → exec runs locally → NO UNAVAILABLE flood
  [B] Active env ref → gateway attempted (skip NOT triggered)
  [C] no-local-exec + active exec ref → gateway attempted (not skipped)

Unit tests (36/36) with real exec provider child processes + mixed-target regression test:

$ pnpm test src/cli/command-secret-gateway.test.ts -- --run

 RUN  v4.1.8

 ✓ skips gateway resolution when gateway credentials would execute exec SecretRefs
 ✓ skips gateway resolution when target SecretRefs include exec providers
 ✓ skips local exec SecretRef fallback when the caller disallows exec providers
 ✓ does not skip gateway resolution when only inactive targets use exec SecretRefs (NEW)
 ✓ keeps local exec SecretRef fallback enabled by default
 ...
 Test Files  1 passed (1)
      Tests  36 passed (36)

Key tests and what they prove:

Observed result after fix:

• Gateway secrets.resolve RPC is not attempted when any active target SecretRef uses an exec provider
• Inactive exec refs no longer poison the skip decision — mixed target sets still go through gateway snapshot resolution
• allowLocalExecSecretRefs=false callers (e.g. doctor preview) still attempt the gateway (not skipped)
• Diagnostic message unified: skipped gateway secrets.resolve because SecretRefs use exec providers at ...
• Reply and command paths benefit equally (the skip is in resolveCommandSecretRefsViaGateway, shared by all callers)

What was not tested:

• Non-talk provider targets (e.g. web search, channel credentials) — the same shared resolveCommandSecretRefsViaGateway applies; target discovery is generic
• Live gateway round-trip with real mixed targets (no local gateway available) — covered by unit test with mocked gateway snapshot

Root Cause (if applicable)

Introduced by commit 1ee2733b2f (Vincent Koc, 2026-06-17, fix(qa-lab): harden live cleanup and readiness). The collectActiveGatewayExecSecretRefCredentialPaths function filters ALL_GATEWAY_SECRET_INPUT_PATHS — only 4 gateway credential paths (gateway.auth.token/password, gateway.remote.token/password). Model-provider secrets (models.providers.*.apiKey, etc.) are never checked. The target ref paths were already known at the decision point, but this information was discarded before the skip check.

Additionally, ClawSweeper review identified: collectActiveExecTargetRefPaths collected all discovered exec refs including inactive ones, which could bypass gateway snapshot resolution for unrelated active targets in mixed target sets.

Regression Test Plan (if applicable)

Target test: src/cli/command-secret-gateway.test.ts

• Existing test "skips gateway resolution when gateway credentials would execute exec SecretRefs" — verifies gateway-credential exec ref path still works
• New test "skips gateway resolution when target SecretRefs include exec providers" — verifies active target exec ref triggers skip
• New test "does not skip gateway resolution when only inactive targets use exec SecretRefs" — verifies inactive exec ref does not trigger skip

User-visible / Behavior Changes

None. The fix changes when the skip triggers (earlier in more cases for active exec refs, not at all for inactive exec refs) but the resolution outcome is identical — local resolution was already the fallback after UNAVAILABLE. Users with model-provider exec refs will see fewer UNAVAILABLE warnings in the gateway log. Users with only inactive exec refs see no behavior change.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No — same local resolution code path
• New/changed network calls? No — fewer gateway RPCs
• Command/tool execution surface changed? No
• Data access scope changed? No

Human Verification (required)

• Verified scenarios: Source-code trace of skip condition logic, 3-scenario live dist bundle proof, unit test scenario walkthrough
• Edge cases checked: Gateway creds exec + target exec (merged diagnostic), gateway creds plaintext + target exec (new fix path), gateway creds exec + target plaintext (existing behavior preserved), active env ref + inactive exec ref (P1 fix — gateway called), no-local-exec policy (P1 gate — not skipped)
• What you did NOT verify: Non-talk provider targets (shared resolver covers all; activeConfiguredRefPaths is computed from classifyConfiguredTargetRefs which is target-agnostic); live gateway with real mixed exec targets

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 — existing users with active exec refs get fewer log lines; users with inactive exec refs see no change
• Config/env changes? No
• Migration needed? No

Best-fix Verdict

• Best fix: Yes. The skip condition is the correct boundary — if any active target uses exec ref, gateway cannot resolve it, so skip unconditionally. Inactive exec refs are correctly excluded using the pre-existing active/inactive classification from classifyConfiguredTargetRefs.
• Refactor needed: No. The new helper collectActiveExecTargetRefPaths follows the same pattern as existing helpers. classifyConfiguredTargetRefs returns an additional field (activeConfiguredRefPaths) that is a natural byproduct of its existing computation.
• Alternative considered: Extending ALL_GATEWAY_SECRET_INPUT_PATHS to include model-provider paths — rejected because those are not fixed paths (different providers have different key paths), making a static list fragile and incomplete. Collecting all discovered exec refs unconditionally — rejected because inactive exec refs in mixed target sets would bypass gateway snapshot resolution for active non-exec targets.

AI Assistance

• AI-assisted: Yes
• Co-Authored-By: Claude Sonnet 4.6 [email protected]
• Human confirmed understanding of code changes: Yes
• AI prompts / session excerpts: Issue [Bug]: reply-path secrets.resolve floods gateway log with UNAVAILABLE for model-provider exec SecretRefs (degrades correctly, ~1 line/turn) #96653 analysis → root-cause trace → fix design → implementation → ClawSweeper P1 refinement (filter inactive exec refs) → pre-commit review → live proof

Risks and Mitigations

None. The fix only expands when the gateway RPC skip triggers. The local fallback path is the same code that already executed after every UNAVAILABLE error. The active/inactive filter reuses the pre-existing classification from classifyConfiguredTargetRefs. Three merge-risk labels are addressed:

• 🚨 auth-provider — inactive exec refs do not affect active model-provider credential resolution
• 🚨 compatibility — users with only inactive exec refs see no behavior change
• 🚨 security-boundary — only active exec refs enter local resolution path; inactive exec refs do not change security boundaries

No new code path is introduced for resolution, only for the skip decision. All existing tests continue to pass (36/36, including new mixed-target regression test).

Related to #96653