Hardcoded Kubernetes role name breaks configurability

The Kubernetes role name is hardcoded to "openclaw", but Vault Kubernetes auth requires matching the role configured in Vault's auth backend. Any deployment that registers its Kubernetes role under a different name (which is common in shared or multi-tenant Vault setups) will fail to authenticate entirely.

The VaultConfig interface has no field for this role, so there is currently no way for users to configure it. A kubernetesRole (or similar) field needs to be added to VaultConfig and passed here:

and correspondingly in VaultConfig:

kubernetesRole?: string;  // Vault Kubernetes auth role (default: "openclaw")

This is a comment left during a code review.
Path: src/config/vault-secret-provider.ts
Line: 193-196

Comment:
**Hardcoded Kubernetes role name breaks configurability**

The Kubernetes role name is hardcoded to `"openclaw"`, but Vault Kubernetes auth requires matching the role configured in Vault's auth backend. Any deployment that registers its Kubernetes role under a different name (which is common in shared or multi-tenant Vault setups) will fail to authenticate entirely.

The `VaultConfig` interface has no field for this role, so there is currently no way for users to configure it. A `kubernetesRole` (or similar) field needs to be added to `VaultConfig` and passed here:

```suggestion
    const resp = await this.rawRequest("POST", "/v1/auth/kubernetes/login", {
      role: this.kubernetesRole ?? "openclaw",
      jwt,
    });
```

and correspondingly in `VaultConfig`:
```ts
kubernetesRole?: string;  // Vault Kubernetes auth role (default: "openclaw")
```

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

Cache TTL sourced exclusively from GCP provider config

The shared fetchWithCache TTL is derived solely from the GCP provider's cacheTtlSeconds. When only the Vault provider is configured (no gcp key in secretsConfig.providers), this expression evaluates to the 5-minute default — completely ignoring any cacheTtlSeconds the user set in their vault provider config.

This means ${vault:my/secret} references will always be cached for 5 minutes regardless of what value is configured in the vault block, making the vault-specific cacheTtlSeconds config option silently ineffective.

Consider picking the TTL from whichever provider is actually in use, or taking the minimum across all configured providers:

const cacheTtlMs = (() => {
  const providerConfigs = Object.values(secretsConfig?.providers ?? {});
  const first = providerConfigs.find((c) => c?.cacheTtlSeconds != null);
  return first?.cacheTtlSeconds != null ? first.cacheTtlSeconds * 1000 : defaultTtlMs;
})();

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

Comment:
**Cache TTL sourced exclusively from GCP provider config**

The shared `fetchWithCache` TTL is derived solely from the GCP provider's `cacheTtlSeconds`. When only the Vault provider is configured (no `gcp` key in `secretsConfig.providers`), this expression evaluates to the 5-minute default — completely ignoring any `cacheTtlSeconds` the user set in their `vault` provider config.

This means `${vault:my/secret}` references will always be cached for 5 minutes regardless of what value is configured in the `vault` block, making the vault-specific `cacheTtlSeconds` config option silently ineffective.

Consider picking the TTL from whichever provider is actually in use, or taking the minimum across all configured providers:

```ts
const cacheTtlMs = (() => {
  const providerConfigs = Object.values(secretsConfig?.providers ?? {});
  const first = providerConfigs.find((c) => c?.cacheTtlSeconds != null);
  return first?.cacheTtlSeconds != null ? first.cacheTtlSeconds * 1000 : defaultTtlMs;
})();
```

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

Supported Providers table not updated

This PR implements the Vault provider, but the table still marks it as Planned. It should be updated to reflect the new status:

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

Comment:
**Supported Providers table not updated**

This PR implements the Vault provider, but the table still marks it as `Planned`. It should be updated to reflect the new status:

```suggestion
| HashiCorp Vault     | ✅ Supported |
```

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

YAML frontmatter accidentally pasted as body content

These lines appear to be YAML frontmatter metadata (a summary: / read_when: / title: block from another document) that was accidentally included as plain Markdown text. They are rendered as literal prose in the docs page, which looks malformed. This block (and the entire large section added here) also documents the GCP provider rather than the Vault provider being introduced by this PR — it appears content from a separate GCP-focused doc was appended here verbatim.

Consider replacing this content with Vault-specific documentation instead.

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

Comment:
**YAML frontmatter accidentally pasted as body content**

These lines appear to be YAML frontmatter metadata (a `summary:` / `read_when:` / `title:` block from another document) that was accidentally included as plain Markdown text. They are rendered as literal prose in the docs page, which looks malformed. This block (and the entire large section added here) also documents the GCP provider rather than the Vault provider being introduced by this PR — it appears content from a separate GCP-focused doc was appended here verbatim.

Consider replacing this content with Vault-specific documentation instead.

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

Wire secret resolution into the config load path

This commit introduces resolveConfigSecrets, but in this revision it is only defined/re-exported and never invoked by the config loading pipeline, so ${vault:...}/${gcp:...} placeholders remain literal strings at runtime. In real configs this causes credentials to stay unresolved and downstream providers to authenticate with placeholder text instead of real secrets. Hook this resolver into config read/normalization before runtime consumers use the config object.

Useful? React with 👍 / 👎.

Use provider-specific cache TTL for secret resolution

The shared cache TTL is derived only from secrets.providers.gcp.cacheTtlSeconds, but fetchWithCache is used for all providers including Vault. That means secrets.providers.vault.cacheTtlSeconds is ignored, so Vault secrets can remain cached for the default 5 minutes even when operators explicitly configure a shorter rotation window. Cache TTL should be selected per provider (or at minimum honor Vault TTL when resolving Vault refs).

Useful? React with 👍 / 👎.

Stop hardcoding the Vault Kubernetes auth role

Kubernetes login always sends role: "openclaw", but Vault Kubernetes auth requires the caller to use a role that matches cluster-specific bindings. Any deployment that uses a different role name will fail authentication even with a valid service account JWT. This should come from configuration instead of being fixed to a single role name.

Useful? React with 👍 / 👎.

Align new secret provider config with validated schema

buildSecretProviders now expects secrets.providers.gcp.project / secrets.providers.vault.*, but config validation still requires each secrets.providers.* entry to match the existing SecretProviderSchema (source: env|file|exec in src/config/zod-schema.core.ts:142-155). In practice, configs using the new GCP/Vault shape are rejected before runtime, so these providers cannot be configured through openclaw.json; update the schema/types (or move these settings to a validated section) so the new fields are actually accepted.

Useful? React with 👍 / 👎.

Parse static-creds fields from Vault response root data

getStaticCreds reads from resp.data?.data, but Vault static-credentials responses return username/password/ttl directly under data, so this path resolves to undefined and the method returns empty credentials ("", 0) even on successful calls. This causes static-rotation consumers to silently treat valid credentials as missing; parse from resp.data (or use the same top-level fallback pattern used in requestDynamic).

Useful? React with 👍 / 👎.

Deduplicate identical secret fetches in one resolution pass

Resolving matches with Promise.all means repeated references like ${vault:db/password} in the same config pass are fetched concurrently, so each call sees an empty cache and hits the provider before any result is stored. This defeats the intended "not fetched twice within a single resolution pass" behavior and can cause avoidable Vault/GCP rate-limit pressure or latency spikes on configs that reuse the same secret many times.

Useful? React with 👍 / 👎.

Avoid replacing newly inserted secret text as later refs

The loop performs sequential working.replace(full, value) mutations on the evolving string, so if one secret resolves to text equal to another reference token (for example, first value is ${gcp:b}), a later iteration can replace that newly inserted text instead of the original token occurrence. This yields partially unresolved or incorrect final config values for valid secret contents that happen to contain reference-like text.

Useful? React with 👍 / 👎.

Restore missing @exodus/bytes lockfile snapshot

This lockfile edit drops the @exodus/bytes@1.15.0(@noble/hashes@2.0.1) snapshot entry that still exists in the parent lockfile graph, and pnpm install --frozen-lockfile now fails immediately with ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY for that package. That blocks CI/clean installs for contributors using frozen lockfile mode, so the lockfile needs to be regenerated or repaired so all referenced snapshots are present.

Useful? React with 👍 / 👎.

Scope secret cache keys by provider configuration

The shared cache key is only provider.name + secret + version, so cached values can bleed across different provider instances that share the same name (for example, two Vault configs with different address/namespace, or two GCP configs with different project/credentials) within the same process. In that scenario a later resolution can return a stale secret from the earlier provider context until TTL expiry, which is incorrect and can expose wrong credentials across contexts.

Useful? React with 👍 / 👎.

Retry Vault listing with GET when LIST is unsupported

listSecrets only issues the non-standard LIST method and rethrows any non-404 error, even though the code comment notes Vault also supports GET ...?list=true. In deployments behind proxies/load balancers that reject unknown methods (commonly returning 405/501), secret listing will fail despite Vault being reachable, so this should fall back to the GET form before surfacing an error.

Useful? React with 👍 / 👎.