hotfix(ollama): Show only Ollama models after provider selection

[Luckymingxuan]

[HOTFIX] Fix Ollama Model Picker to Directly Show Available Models

Summary

⚠️ Hotfix / Urgent: Users cannot directly see Ollama models after selecting the provider, impacting onboarding flow.

• Problem: After selecting Ollama as the provider and entering the base URL, the model picker still showed "Filter models by provider" with all providers instead of directly displaying available Ollama models.
• Why it matters: Poor user experience — new users cannot immediately see available Ollama models, which can block onboarding.
• What changed: Added "ollama" to the NON_PI_NATIVE_MODEL_PROVIDERS set in src/agents/model-catalog.ts.
• What did NOT change: All other provider behaviors remain unchanged; only Ollama model discovery logic was fixed.

Change Type

• Bug fix (Hotfix / urgent for Ollama model discovery)

Scope

• Integrations
• UI / DX

Linked Issue/PR

• Closes: N/A (no existing issue, long-standing user-reported behavior)

Root Cause / Regression History

• Root cause: Ollama was not included in the NON_PI_NATIVE_MODEL_PROVIDERS set, so configured Ollama models were not added to the model catalog during discovery.
• Missing detection / guardrail: No explicit check to ensure all bundled providers are properly configured in the model catalog logic.
• Prior context: Long-standing issue in the model selection flow for Ollama provider.
• Why this regressed now: Not a regression — this issue existed since Ollama provider was added.

Regression Test Plan

• Coverage level that should have caught this: Unit test
• Target test or file: src/agents/model-catalog.test.ts
• Scenario the test should lock in: Verify that Ollama models are properly included in the model catalog when configured.
• Why this is the smallest reliable guardrail: Tests the specific logic of model catalog construction for non-PI providers.
• Existing test that already covers this: No existing test specifically for Ollama model catalog inclusion.
• If no new test is added, why not: Environment constraints prevented running test suite, but manual verification confirms the fix.

User-visible / Behavior Changes

• After selecting Ollama provider and entering base URL, the model picker now directly displays available Ollama models instead of showing provider filter options.
• Without this fix, new Ollama users are blocked from seeing models during setup.

Diagram

Before:
[Select Ollama] -> [Enter URL] -> [Show “Filter models by provider” with all providers]

After:
[Select Ollama] -> [Enter URL] -> [Directly show Ollama models only]

Security Impact

• New permissions/capabilities? ❌ No
• Secrets/tokens handling changed? ❌ No
• New/changed network calls? ❌ No
• Command/tool execution surface changed? ❌ No
• Data access scope changed? ❌ No

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node.js
• Model/provider: Ollama
• Relevant config: Ollama base URL

Steps

1. Run OpenClaw onboard
2. Select "Ollama" as provider
3. Enter valid Ollama base URL
4. Observe model selection step

Expected

• Directly see list of available Ollama models

Actual (before fix)

• See "Filter models by provider" with all providers

Human Verification

• Verified scenarios: Ollama model selection flow in interactive setup
• Edge cases checked: Empty model list, multiple models available
• What you did not verify: Non-interactive setup flow (should work similarly)

Compatibility / Migration

• Backward compatible? ✅ Yes
• Config/env changes? ❌ No
• Migration needed? ❌ No

Risks and Mitigations

• Risk: None identified — minimal change limited to model catalog discovery logic
• Mitigation: Hotfix scoped to Ollama model discovery only, no other providers affected

⚠️ Note to reviewers: This is a hotfix impacting onboarding. Please prioritize review and merge to restore proper Ollama model visibility.

[greptile-apps]

Greptile Summary

This hotfix adds "ollama" to the NON_PI_NATIVE_MODEL_PROVIDERS set in src/agents/model-catalog.ts, enabling Ollama-configured models to be included in the model catalog during discovery. Without this entry, readConfiguredOptInProviderModels silently skipped Ollama providers, causing the model picker to fall back to the generic "filter by provider" UI instead of directly listing the user's Ollama models.

Changes:

• src/agents/model-catalog.ts: One-line fix — adds "ollama" to the opt-in set. The lowercase provider key comparison already in place means this is all that was needed.
• src/agents/model-catalog.test.ts: Adds a regression test following the identical pattern used for the kilocode provider (line 248), locking in the Ollama model catalog inclusion path.

Confidence Score: 5/5

Safe to merge — minimal, targeted one-line fix with a matching regression test and no behavioral changes to other providers.

The change is a single set entry addition. The provider lookup already lowercases keys before comparison, so 'ollama' integrates without any further edits. The previously flagged missing test concern has been fully addressed with a well-structured test that mirrors the existing kilocode pattern. No other code paths are affected.

No files require special attention.

Important Files Changed

Filename	Overview
src/agents/model-catalog.ts	One-line fix adding 'ollama' to NON_PI_NATIVE_MODEL_PROVIDERS set; correct and complete given the existing lowercase key comparison logic.
src/agents/model-catalog.test.ts	Adds regression test for Ollama provider model catalog inclusion, mirroring the established kilocode test pattern.

_{Reviews (2): Last reviewed commit: "Merge branch 'main' into fix-ollama-mode..." | Re-trigger Greptile}

[greptile-apps]

Missing test coverage for new Ollama entry

The PR description acknowledges no test was added. The existing model-catalog.test.ts already has an equivalent test at line 248 ("merges configured models for opted-in non-pi-native providers") that covers the same code path for kilocode. Adding a similar test for ollama would lock in the fix and guard against future regressions (e.g., someone renaming the set entry or changing the comparison):

it("merges configured models for opted-in ollama provider", async () => {
  mockSingleOpenAiCatalogModel();

  const result = await loadModelCatalog({
    config: {
      models: {
        providers: {
          ollama: {
            baseUrl: "http://127.0.0.1:11434",
            api: "ollama",
            models: [{ id: "llama3.2", name: "Llama 3.2" }],
          },
        },
      },
    } as OpenClawConfig,
  });

  expect(result).toContainEqual(
    expect.objectContaining({ provider: "ollama", id: "llama3.2", name: "Llama 3.2" }),
  );
});

This mirrors the structure already used for kilocode and would be the "smallest reliable guardrail" mentioned in the PR's own regression test plan.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/agents/model-catalog.ts
Line: 37

Comment:
**Missing test coverage for new Ollama entry**

The PR description acknowledges no test was added. The existing `model-catalog.test.ts` already has an equivalent test at line 248 ("merges configured models for opted-in non-pi-native providers") that covers the same code path for `kilocode`. Adding a similar test for `ollama` would lock in the fix and guard against future regressions (e.g., someone renaming the set entry or changing the comparison):

```ts
it("merges configured models for opted-in ollama provider", async () => {
  mockSingleOpenAiCatalogModel();

  const result = await loadModelCatalog({
    config: {
      models: {
        providers: {
          ollama: {
            baseUrl: "http://127.0.0.1:11434",
            api: "ollama",
            models: [{ id: "llama3.2", name: "Llama 3.2" }],
          },
        },
      },
    } as OpenClawConfig,
  });

  expect(result).toContainEqual(
    expect.objectContaining({ provider: "ollama", id: "llama3.2", name: "Llama 3.2" }),
  );
});
```

This mirrors the structure already used for `kilocode` and would be the "smallest reliable guardrail" mentioned in the PR's own regression test plan.

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

[Luckymingxuan]

I've added the test case as suggested and made additional modifications to fix type errors.

Thank you for pointing out the missing test coverage. I've added a dedicated test case for the Ollama provider following the same pattern as the existing kilocode test. I noticed that the initial test case needed additional model properties to match the ModelDefinitionConfig type requirements, so I included:

• reasoning
• input
• cost
• contextWindow
• maxTokens
  These properties were necessary to resolve TypeScript compilation errors. The test now properly verifies that Ollama models are merged into the catalog when configured, providing the regression guard you recommended.

The changes are committed in the fix branch and should address the coverage gap you identified.

[Luckymingxuan]

Signal tests failing unrelated to Ollama hotfix

Analysis

• Our changes only touch:
  • src/agents/model-catalog.ts → Added "ollama" to NON_PI_NATIVE_MODEL_PROVIDERS
  • src/agents/model-catalog.test.ts → Added test coverage for Ollama
• Failed tests are in Signal extension:
  • skips tool summaries with responsePrefix
  • processes messages when reaction metadata is present
• Root Cause / Isolation:
  • sendMock not called as expected
  • Signal extension code does not reference NON_PI_NATIVE_MODEL_PROVIDERS or Ollama
  • Our changes affect only model catalog loading, fully isolated from Signal processing

Recommendation

• The Ollama hotfix is safe to merge.
• Signal test failures are likely due to test environment, race conditions, or unrelated code changes.
• Address Signal test issues separately if they persist.

@greptile-apps

[BruceMacD]

Merged via squash.

• Prepared head SHA: 110adc0
• Merge commit: 302c047

Thanks @Luckymingxuan!