Normalize explicit provider IDs before implicit-provider filter

The new implicit-provider stripping uses raw Object.keys(explicitProviders) for membership checks, but mergeProviders() normalizes keys with trim(). If a config key has leading/trailing whitespace (allowed by the current z.record(z.string(), ...) schema), the merged provider is stored under the trimmed ID and then deleted here as “implicit-only,” which can leave providers empty and skip writing models.json even though the user configured a provider. Align this filter with the same key normalization used during merge.

Useful? React with 👍 / 👎.

Ollama (and other) network probes still fire when explicit providers are set.

resolveImplicitProviders is called unconditionally at line 122, before the hasExplicitProviders guard at line 128. Inside that function, buildOllamaProvider always issues a real HTTP request to http://127.0.0.1:11434/api/tags (with a 5 s timeout) unless process.env.VITEST or NODE_ENV=test is set.

In a production environment where Ollama is not running, every startup with explicit providers configured will silently wait up to 5 seconds for the probe to time out, and then the discovered result is immediately discarded by the filter loop (lines 134–139). The same applies to other providers discovered via resolveImplicitProviders (Venice, vLLM, HuggingFace, etc.) — the discovery work is done but thrown away.

The stated goal of the PR is to skip implicit auto-detection when explicit providers are configured. Achieving that fully would require either:

• Skipping the resolveImplicitProviders call entirely when hasExplicitProviders, or
• Passing a hint to resolveImplicitProviders to skip network-bound discovery steps when explicit providers exist

Consider moving the resolveImplicitProviders call inside the if (!hasExplicitProviders) block to avoid unnecessary network probes in production.

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

Comment:
Ollama (and other) network probes still fire when explicit providers are set.

`resolveImplicitProviders` is called unconditionally at line 122, before the `hasExplicitProviders` guard at line 128. Inside that function, `buildOllamaProvider` always issues a real HTTP request to `http://127.0.0.1:11434/api/tags` (with a 5 s timeout) unless `process.env.VITEST` or `NODE_ENV=test` is set.

In a production environment where Ollama is not running, every startup with explicit providers configured will silently wait up to 5 seconds for the probe to time out, and then the discovered result is immediately discarded by the filter loop (lines 134–139). The same applies to other providers discovered via `resolveImplicitProviders` (Venice, vLLM, HuggingFace, etc.) — the discovery work is done but thrown away.

The stated goal of the PR is to *skip* implicit auto-detection when explicit providers are configured. Achieving that fully would require either:
- Skipping the `resolveImplicitProviders` call entirely when `hasExplicitProviders`, or
- Passing a hint to `resolveImplicitProviders` to skip network-bound discovery steps when explicit providers exist

Consider moving the `resolveImplicitProviders` call inside the `if (!hasExplicitProviders)` block to avoid unnecessary network probes in production.

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

Keep Bedrock discovery for explicit Bedrock configs

When models.providers is non-empty, this early return skips the resolveImplicitBedrockProvider path below, so explicit amazon-bedrock configs no longer get discovery-based model refresh/merge. In setups that enable models.bedrockDiscovery (or rely on AWS credential auto-enable), newly discovered Bedrock models and capability updates stop propagating into models.json, even though the same explicit Bedrock config previously went through mergeProviderModels(implicitBedrock, existing) and stayed current.

Useful? React with 👍 / 👎.

Good catch — fixed in 0f82cd0.

When amazon-bedrock or github-copilot is present in the explicit providers list, we now still run their respective discovery so mergeProviderModels can apply capability updates. The early return is moved to after those targeted discovery calls.

For providers like custom-proxy that aren't Bedrock/Copilot, the behavior is unchanged — no unnecessary discovery runs.

Drop stale implicit providers when explicit config is present

In the explicit-provider path, this deletion only affects the in-memory providers map before resolveProvidersForMode() runs, but default mode is merge, and mergeWithExistingProviderSecrets() copies all existing models.json providers back in. That means users who already have an implicitly discovered provider (for example from earlier zero-config runs) will keep it even after switching to explicit models.providers, so the new guard against unintended provider routing does not actually take effect for existing installs.

Useful? React with 👍 / 👎.

Good catch — fixed in f479b90.

Added a post-merge filter in the main ensureOpenClawModelsJson path: after resolveProvidersForMode() merges with existing models.json, we now re-apply the explicit-provider filter to strip any stale implicit providers that were re-introduced from previous zero-config runs.

Also added trim() normalization on explicit provider keys to match the merge step's normalization, addressing the P2 whitespace concern.

Updated the "merges providers by default" test to expect the corrected behavior: non-explicit providers in models.json are now properly stripped. 74/74 tests passing.

Trim explicit provider keys before filtering merged providers

Use normalized provider IDs for this membership check. mergeProviders() trims config keys, so an explicit entry like " amazon-bedrock " is stored under "amazon-bedrock", but explicitKeys here keeps the untrimmed key and deletes the provider as “implicit-only.” In that case resolveProvidersForModelsJson() can return an empty map and ensureOpenClawModelsJson() exits early without writing models.json, effectively dropping a user-configured provider.

Useful? React with 👍 / 👎.