openclaw - 💡(How to fix) Fix Reduce duplicate SecretRef provider lookups during gateway startup [1 participants]

OpenClaw gateway startup appears to perform repeated SecretRef provider lookups for the same vaults/items during config/runtime secret resolution.

This was noticed while using 1Password Connect/service account token-backed SecretRefs. We hit 1Password’s 1,000 queries/day service account token limit, and then later also tripped a local Traefik rate limit in front of OPC during gateway startup.

Concrete startup observation with 1Password Connect:

• Startup time: 2026-04-24 00:46:33 EDT
• OPC calls in first 60s: 84
• Unique paths: 28
• Duplicate calls: 56
• Statuses: all 200

Breakdown:

• Vault/container name lookups: 28
  • only 2 unique vaults
• Item/secret name lookups: 28
  • 13 unique items
• Item/secret fetch by ID: 28
  • 13 unique items

Top duplicate:

26x /v1/vaults?filter=title+eq+%22TARS+Write%22

This is probably not 1Password-specific. 1Password is just the backend where the duplicate provider calls became visible and painful.

Suggested fix:

Add in-memory memoization during one SecretRef/config resolution pass:

• cache provider-level container lookup, e.g. provider + vault/container name -> id
• cache provider-level item lookup, e.g. provider + container id + item/secret name -> id
• cache fetched secret/item payloads
• optionally cache full SecretRef string resolution

Constraints:

• no disk cache
• no plaintext secret logging
• cache lifetime should be process/startup-resolution scoped
• behavior/output unchanged except fewer provider calls

Useful diagnostic log, values redacted:

SecretRefs resolved: 84 provider calls, 28 unique provider paths, 56 cache hits

Impact:

• reduces startup secret-provider traffic
• avoids burning through provider API quotas
• avoids requiring high external rate limits
• improves reliability for 1Password Connect and future SecretRef backends
• keeps secrets in memory only, matching current security posture