Azure cacheTtlSeconds is silently ignored

The cacheTtlMs variable is derived exclusively from the GCP provider's configuration. If a user configures only the Azure provider with a custom cacheTtlSeconds, that value is never read and the default 5-minute TTL is used instead.

// Current — only GCP's TTL is respected
const cacheTtlMs =
  secretsConfig?.providers?.gcp?.cacheTtlSeconds != null
    ? secretsConfig.providers.gcp.cacheTtlSeconds * 1000
    : defaultTtlMs;

AzureSecretProvider exposes a cacheTtlMillis getter precisely so callers can read the per-provider TTL. The simplest fix is to resolve each secret using its own provider's TTL inside resolveAny / fetchWithCache, or at minimum also check the azure config here:

const gcpTtl = secretsConfig?.providers?.gcp?.cacheTtlSeconds;
const azureTtl = secretsConfig?.providers?.azure?.cacheTtlSeconds;
const cacheTtlMs =
  (gcpTtl ?? azureTtl ?? null) != null
    ? (gcpTtl ?? azureTtl)! * 1000
    : defaultTtlMs;

Ideally, fetchWithCache should accept the provider's own TTL so each provider's configured value is used independently.

This is a comment left during a code review.
Path: src/config/secret-resolution.ts
Line: 490-494

Comment:
**Azure `cacheTtlSeconds` is silently ignored**

The `cacheTtlMs` variable is derived exclusively from the GCP provider's configuration. If a user configures only the Azure provider with a custom `cacheTtlSeconds`, that value is never read and the default 5-minute TTL is used instead.

```ts
// Current — only GCP's TTL is respected
const cacheTtlMs =
  secretsConfig?.providers?.gcp?.cacheTtlSeconds != null
    ? secretsConfig.providers.gcp.cacheTtlSeconds * 1000
    : defaultTtlMs;
```

`AzureSecretProvider` exposes a `cacheTtlMillis` getter precisely so callers can read the per-provider TTL. The simplest fix is to resolve each secret using its own provider's TTL inside `resolveAny` / `fetchWithCache`, or at minimum also check the azure config here:

```ts
const gcpTtl = secretsConfig?.providers?.gcp?.cacheTtlSeconds;
const azureTtl = secretsConfig?.providers?.azure?.cacheTtlSeconds;
const cacheTtlMs =
  (gcpTtl ?? azureTtl ?? null) != null
    ? (gcpTtl ?? azureTtl)! * 1000
    : defaultTtlMs;
```

Ideally, `fetchWithCache` should accept the provider's own TTL so each provider's configured value is used independently.

How can I resolve this? If you propose a fix, please make it concise.

Azure provider registered with empty vaultUrl, masking misconfiguration

When vaultUrl is absent from the config, the AzureSecretProvider is constructed with an empty string (""). The provider is silently registered and will only fail later at runtime — when a secret is actually fetched — with a potentially cryptic Azure SDK networking error rather than a clear configuration error.

Consider validating the presence of vaultUrl before registering the provider:

if (name === "azure") {
  if (!config?.vaultUrl) {
    throw new Error(
      'Azure secret provider config is missing required field "vaultUrl". ' +
      'Set secrets.providers.azure.vaultUrl in openclaw.json.',
    );
  }
  providers.set("azure", new AzureSecretProvider({ ... }));
}

This is a comment left during a code review.
Path: src/config/secret-resolution.ts
Line: 333

Comment:
**Azure provider registered with empty `vaultUrl`, masking misconfiguration**

When `vaultUrl` is absent from the config, the `AzureSecretProvider` is constructed with an empty string (`""`). The provider is silently registered and will only fail later at runtime — when a secret is actually fetched — with a potentially cryptic Azure SDK networking error rather than a clear configuration error.

Consider validating the presence of `vaultUrl` before registering the provider:

```ts
if (name === "azure") {
  if (!config?.vaultUrl) {
    throw new Error(
      'Azure secret provider config is missing required field "vaultUrl". ' +
      'Set secrets.providers.azure.vaultUrl in openclaw.json.',
    );
  }
  providers.set("azure", new AzureSecretProvider({ ... }));
}
```

How can I resolve this? If you propose a fix, please make it concise.

Documentation marks Azure Key Vault as "Planned" — but this PR ships it

The newly-added supported providers table shows:

| Azure Key Vault     | Planned      |

Since this PR is implementing and shipping AzureSecretProvider, the status should be updated to ✅ Supported to match the GCP row and accurately reflect what this release provides.

This is a comment left during a code review.
Path: docs/gateway/secrets.md
Line: 492

Comment:
**Documentation marks Azure Key Vault as "Planned" — but this PR ships it**

The newly-added supported providers table shows:

```
| Azure Key Vault     | Planned      |
```

Since this PR is implementing and shipping `AzureSecretProvider`, the status should be updated to `✅ Supported` to match the GCP row and accurately reflect what this release provides.

```suggestion
| Azure Key Vault     | ✅ Supported |
```

How can I resolve this? If you propose a fix, please make it concise.

Frontmatter-style metadata rendered as body text in the new section

The block starting immediately after the ## Additional Secrets Providers heading:

summary: "External secrets management: store credentials in GCP Secret Manager..."
read_when:
- You want to stop storing API keys...
  title: "Secrets"

looks like it was intended as frontmatter or an internal document header but was accidentally placed in the body. Readers will see this raw key-value syntax rendered as plain text, which is confusing. Either move it to proper frontmatter at the top of the file (if the docs platform supports per-section frontmatter) or remove it entirely.

This is a comment left during a code review.
Path: docs/gateway/secrets.md
Line: 453-465

Comment:
**Frontmatter-style metadata rendered as body text in the new section**

The block starting immediately after the `## Additional Secrets Providers` heading:

```
summary: "External secrets management: store credentials in GCP Secret Manager..."
read_when:
- You want to stop storing API keys...
  title: "Secrets"
```

looks like it was intended as frontmatter or an internal document header but was accidentally placed in the body. Readers will see this raw key-value syntax rendered as plain text, which is confusing. Either move it to proper frontmatter at the top of the file (if the docs platform supports per-section frontmatter) or remove it entirely.

How can I resolve this? If you propose a fix, please make it concise.

@google-cloud/secret-manager added as a hard dependency, inconsistent with Azure's optional approach

The PR description states that Azure SDK packages are lazy-loaded as optional peer dependencies. The GcpSecretProvider uses the same lazy import() pattern (await import("@google-cloud/secret-manager")), yet @google-cloud/secret-manager is being added to dependencies in package.json, making it always installed.

This means every consumer of this package pays the install cost for GCP's SDK even if they only use Azure Key Vault (or no secrets provider at all). For consistency with the stated design, consider moving @google-cloud/secret-manager to peerDependenciesMeta as optional, mirroring how @azure/keyvault-secrets and @azure/identity are handled.

This is a comment left during a code review.
Path: package.json
Line: 346

Comment:
**`@google-cloud/secret-manager` added as a hard dependency, inconsistent with Azure's optional approach**

The PR description states that Azure SDK packages are *lazy-loaded as optional peer dependencies*. The `GcpSecretProvider` uses the same lazy `import()` pattern (`await import("@google-cloud/secret-manager")`), yet `@google-cloud/secret-manager` is being added to `dependencies` in `package.json`, making it always installed.

This means every consumer of this package pays the install cost for GCP's SDK even if they only use Azure Key Vault (or no secrets provider at all). For consistency with the stated design, consider moving `@google-cloud/secret-manager` to `peerDependenciesMeta` as optional, mirroring how `@azure/keyvault-secrets` and `@azure/identity` are handled.

How can I resolve this? If you propose a fix, please make it concise.

Scope secret cache keys to provider configuration

fetchWithCache uses provider.name plus secret/version as the entire cache key, so two different provider instances of the same type (for example, different Azure vault URLs or GCP projects across config reloads/multi-agent runs) will share cache entries. In that scenario, the second resolution can return a secret from the previous provider context without calling getSecret, which can serve incorrect credentials or leak values across contexts; include provider identity (project/vault/provider alias) in the key or clear cache per config.

Useful? React with 👍 / 👎.

Honor Azure cacheTtlSeconds during secret resolution

resolveConfigSecrets computes the shared cache TTL only from secrets.providers.gcp.cacheTtlSeconds, so Azure's cacheTtlSeconds setting is ignored. In an Azure-only configuration, users cannot lower or raise cache duration as documented, which means secret rotations may not take effect until the hardcoded 5-minute default expires; TTL needs to be selected per referenced provider instead of hardcoding the GCP field.

Useful? React with 👍 / 👎.

Wire resolveConfigSecrets into loadConfig

This resolver is introduced but never executed in the config read path: in this commit, loadConfig in src/config/io.ts goes from include/env resolution to validation/return without calling resolveConfigSecrets, so ${gcp:...} and ${azure:...} placeholders remain literal strings at runtime. In practice, users following the new secrets docs will pass unresolved placeholders as credentials and hit downstream auth failures instead of secret lookup.

Useful? React with 👍 / 👎.

Scope GCP provider cache keys by project

GcpSecretProvider.getSecret caches using only gcp:${secretName}#${ver} in the shared secretCache, so project/credential context is not part of the key. If config is reloaded to a different GCP project (or multiple provider instances are used in one process), the method can return a stale secret from the previous project without calling Secret Manager; even fixing fetchWithCache would not address this provider-level collision.

Useful? React with 👍 / 👎.

Align provider config shape with existing secrets schema

buildSecretProviders assumes entries like secrets.providers.gcp.project/azure.vaultUrl, but config validation still enforces secrets.providers.* as the existing discriminated source union in src/config/zod-schema.core.ts (env|file|exec). In practice, a config that follows this new provider shape is rejected during validation before any resolution can run, so users cannot enable the new provider configuration path at all.

Useful? React with 👍 / 👎.

Declare Azure SDK packages required by dynamic imports

The provider hard-imports @azure/identity (and later @azure/keyvault-secrets) at runtime, but this commit does not add either package to dependencies or peerDependencies in package.json (only @google-cloud/secret-manager is added). On a clean install, ${azure:...} resolution will fail immediately with the install error unless users manually add extra packages, so the Azure provider is not usable out of the box.

Useful? React with 👍 / 👎.

Replace refs by position to avoid mutating resolved secret text

The replacement loop uses working = working.replace(full, sv) for each matched placeholder, which always replaces the first matching substring in the current string. If an earlier secret value contains text that looks like another placeholder (for example ${gcp:a} resolves to a string containing ${gcp:b} while ${gcp:b} is also present in the original config), later iterations can rewrite the injected secret value instead of the original placeholder and leave the real placeholder unresolved. This can corrupt resolved credentials/config values in real deployments where secret payloads include template-like text.

Useful? React with 👍 / 👎.

Deduplicate in-flight secret fetches during parallel resolution

resolveAny resolves object/array fields in parallel, but fetchWithCache only caches completed values. When the same reference appears multiple times in one config load, concurrent calls all miss the cache and each executes provider.getSecret(...), causing redundant backend reads (and potential throttling/slow startup) even though a shared cache exists. Add in-flight promise deduplication (or pre-deduplicate references) so identical refs are fetched once per resolution pass.

Useful? React with 👍 / 👎.

Avoid mutating resolved secrets during escape restoration

The escape restoration step uses a fixed sentinel (___OPENCLAW_ESC___) and then blindly runs replaceAll on the fully resolved string, so any resolved secret value containing that substring is rewritten (for example, abc___OPENCLAW_ESC___def becomes abc${def). This can silently corrupt credentials/config values in deployments where secret payloads include that token-like text; use a per-call unique marker or positional reconstruction so only original $${...} escapes are restored.

Useful? React with 👍 / 👎.