Check explicit config fields before overriding preserved baseUrl

newEntry at this point already includes implicit provider defaults from resolveProvidersForModelsJson (it merges implicit + explicit providers), so this configHasBaseUrl check is true even when openclaw.json does not define models.providers.<id>.baseUrl. In merge mode that suppresses preserved.baseUrl, so restarting can overwrite an existing agent models.json endpoint with the implicit default for discovered providers (for example providers injected from env/profile), which regresses the intended "preserve when config omits value" behavior. The override check needs to key off explicit config presence, not just non-empty newEntry.baseUrl.

Useful? React with 👍 / 👎.

Test exercises unreachable baseUrl: "" path

The new test passes baseUrl: "" directly to ensureOpenClawModelsJson, bypassing schema validation. In production, ModelProviderSchema enforces baseUrl: z.string().min(1), so an empty string is rejected before it can reach mergeWithExistingProviderSecrets. The configHasBaseUrl empty-string branch in the implementation is therefore unreachable via the normal config loading path.

The apiKey: "" half of the test is valid (no .min(1) constraint on apiKey). The more realistic scenario to test for baseUrl would be omitting the field entirely, which also results in configHasBaseUrl = false and agent-value preservation.

This is a comment left during a code review.
Path: src/agents/models-config.fills-missing-provider-apikey-from-env-var.test.ts
Line: 223-263

Comment:
**Test exercises unreachable `baseUrl: ""` path**

The new test passes `baseUrl: ""` directly to `ensureOpenClawModelsJson`, bypassing schema validation. In production, `ModelProviderSchema` enforces `baseUrl: z.string().min(1)`, so an empty string is rejected before it can reach `mergeWithExistingProviderSecrets`. The `configHasBaseUrl` empty-string branch in the implementation is therefore unreachable via the normal config loading path.

The `apiKey: ""` half of the test is valid (no `.min(1)` constraint on `apiKey`). The more realistic scenario to test for `baseUrl` would be omitting the field entirely, which also results in `configHasBaseUrl = false` and agent-value preservation.

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

SecretRef-typed apiKey treated as absent

typeof ... === "string" returns false when apiKey is a SecretRef object — the { env: "..." } form that SecretInputSchema permits as a valid value. When that happens, configHasApiKey evaluates to false and the agent's existing string value is preserved, silently ignoring the user's config — which is the exact class of bug this PR is intended to fix.

SecretInputSchema is defined as z.union([z.string(), SecretRefSchema]), so both forms are valid config values. The check should accept any non-nullish, non-empty-string value rather than requiring typeof ... === "string":

const rawVal = (newEntry as { apiKey?: unknown }).apiKey;
const configHasApiKey = rawVal !== undefined && rawVal !== null && rawVal !== "";

baseUrl is fine as-is because ModelProviderSchema constrains it to z.string().min(1), so the string type check is sufficient there.

This is a comment left during a code review.
Path: src/agents/models-config.ts
Line: 164-169

Comment:
**`SecretRef`-typed `apiKey` treated as absent**

`typeof ... === "string"` returns `false` when `apiKey` is a `SecretRef` object — the `{ env: "..." }` form that `SecretInputSchema` permits as a valid value. When that happens, `configHasApiKey` evaluates to `false` and the agent's existing string value is preserved, silently ignoring the user's config — which is the exact class of bug this PR is intended to fix.

`SecretInputSchema` is defined as `z.union([z.string(), SecretRefSchema])`, so both forms are valid config values. The check should accept any non-nullish, non-empty-string value rather than requiring `typeof ... === "string"`:

```typescript
const rawVal = (newEntry as { apiKey?: unknown }).apiKey;
const configHasApiKey = rawVal !== undefined && rawVal !== null && rawVal !== "";
```

`baseUrl` is fine as-is because `ModelProviderSchema` constrains it to `z.string().min(1)`, so the string type check is sufficient there.

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

Treat whitespace-only overrides as missing in merge mode

In merge mode, configHasApiKey/configHasBaseUrl currently use !== "", so values like ' ' are treated as explicit overrides instead of empty. When an existing models.json provider has working credentials/endpoints and config contains whitespace-only apiKey/baseUrl (for example from templating or copy/paste), this branch suppresses preservation and writes unusable values, causing auth/endpoint failures after restart. The emptiness check should normalize/trim before deciding whether config intentionally overrides stored secrets.

Useful? React with 👍 / 👎.