Roo Code won't connect to external Ollama server (Reopening #6589)

[VincentJGeisler]

Reopening Issue #6589

This issue was closed as stale in #6589, however the problem still exists and is being actively reported by multiple users in the most recent comments on that thread (after closure).

Problem Summary

Roo Code cannot connect to Ollama servers on non-localhost addresses (e.g., http://10.3.4.5:11434 or LAN IPs). This works fine with localhost addresses and works with other AI tools connecting to the same Ollama servers, indicating this is specific to Roo Code.

Evidence from Original Thread

From the comments AFTER the issue was closed:

• john970: "I also have this issue. I'd bet this happens to anyone who is trying to use ollama on their LAN and not localhost on either macOS or Linux."
• oliver124810: Mentioned it as a UI issue that requires trial and error to work
• kneczaj: Posted a screenshot showing Ollama is accessible but Roo Code can't connect (2 days ago)

The original reporter confirmed the issue still exists on macOS even after the refactor to use the official Ollama SDK.

Reproduction Steps

1. Set up Ollama server on a non-localhost address (e.g., LAN IP like http://192.168.1.100:11434)
2. Verify Ollama is accessible via curl or other AI tools
3. In Roo Code, select Ollama provider
4. Enter the external URL
5. Attempt to select a model

Expected: Should connect and list available models
Actual: Error stating model is not available

Workarounds Found

Users have found these workarounds (which shouldn't be necessary):

• SSH tunnel: ssh -L 11434:localhost:11434 user@remote_server_ip
• Using a VPN/tunnel from a different network
• Using ngrok
• Switching to OpenAI Compatible provider with /v1 appended to URL

Request

This issue will be persistently reopened until either:

1. The bug is properly fixed, or
2. A logical technical reason is provided for why external Ollama servers cannot/will not be supported

Closing as "stale" when users are actively reporting the issue is not acceptable. If this is a won't-fix, please document it clearly in the docs as a known limitation.

Environment

• Affects: macOS (confirmed), Linux (likely)
• Ollama: Latest versions
• Other tools: Can connect to same Ollama servers without issue

Reference: #6589

[roomote]

I've analyzed this issue and identified several interconnected problems in the Ollama connection flow. Here's my analysis and proposed implementation plan:

Root Cause Analysis

After tracing through the code, I found multiple issues that combine to make external Ollama servers effectively broken:

1. Stale cache masking connection failures (src/api/providers/fetchers/modelCache.ts)

The model cache is keyed by provider name ("ollama"), not by URL. When refreshModels() fetches from a new external URL and gets an empty result (due to connection failure), it falls back to returning the old cached models from the previous URL (e.g., localhost). This means the user sees models that appear to be from their external server but are actually stale localhost models. When they try to use one, the actual API call goes to the external server where that model may not exist.

2. Silent error swallowing (src/api/providers/fetchers/ollama.ts)

getOllamaModels() catches all errors and silently returns {}. It never throws, so callers have no way to distinguish "no models available" from "connection failed." The requestOllamaModels handler in webviewMessageHandler.ts compounds this by catching any remaining errors with console.debug and providing zero feedback to the user.

3. No timeout on HTTP requests (src/api/providers/fetchers/ollama.ts)

The axios calls to /api/tags and /api/show have no timeout configured. For unreachable external servers, requests can hang for 30+ seconds (TCP timeout) with no feedback, while the webview-side timeout is only 10 seconds.

4. No model re-fetch when URL changes (webview-ui/src/components/settings/providers/Ollama.tsx)

Models are only fetched once on component mount via useEffect([], []). After the user changes the base URL, models are NOT re-fetched. The user must navigate away and come back, and even then the fetch uses the persisted state, not the current unsaved input.

5. Empty response silently dropped (src/core/webview/webviewMessageHandler.ts)

When the model list is empty, the handler simply does nothing -- no message is posted to the webview. The webview just times out after 10 seconds.

Proposed Implementation Plan

Fix 1: Add timeouts to getOllamaModels (src/api/providers/fetchers/ollama.ts)

• Add a 10-second timeout to both the GET /api/tags and POST /api/show axios calls
• This prevents indefinite hangs when external servers are unreachable

Fix 2: Propagate connection errors from getOllamaModels

• Instead of catching all errors and returning {}, re-throw connection errors so callers can handle them (add a typed error or use a Result pattern)
• Keep the catch for parse errors (which are non-fatal)

Fix 3: Fix requestOllamaModels error reporting (src/core/webview/webviewMessageHandler.ts)

• Send an error message back to the webview when the model fetch fails
• Post an ollamaModels message with empty models AND an error string so the UI can display feedback like "Could not connect to Ollama at http://10.3.4.5:11434"

Fix 4: Prevent stale cross-URL cache returns (src/api/providers/fetchers/modelCache.ts)

• In refreshModels, when the fresh fetch returns empty, do NOT fall back to old cached data for providers like Ollama where the URL can change. Instead return {} so the error is visible.
• Alternative: clear the memory cache before refresh for URL-dependent providers.

Fix 5: Re-fetch models on URL change (webview-ui/src/components/settings/providers/Ollama.tsx)

• Add ollamaBaseUrl as a dependency to the useEffect that fetches models, OR add a "Refresh Models" button
• Pass the current URL from the webview in the requestOllamaModels message so the backend uses the unsaved URL, not the persisted one

Fix 6: Always send response to webview

• In the requestOllamaModels handler, always post a message back (even if empty), so the webview doesn't just timeout silently

This plan addresses both the root causes (stale cache, silent errors) and the UX issues (no feedback, no re-fetch on URL change).

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[VincentJGeisler]

@roomote i dont agree. the fact we can reach it by tunneling localhost to the remote server tells us its a network block somewhere, a firewall perhaps

[roomote]

@VincentJGeisler Fair point -- tunneling proving connectivity does suggest a network-level factor in some cases. But consider this: the issue also lists "switching to OpenAI Compatible provider with /v1 appended to the URL" as a working workaround. Both providers make HTTP requests from the same VSCode extension host process, so a firewall would block both equally. That tells us there are also code-level issues in the Ollama provider path.

Looking at the code, I found several things that would make a firewall issue indistinguishable from code bugs:

1. Silent error swallowing: getOllamaModels() catches all errors and returns {}. The webview handler then catches again with console.debug. Users get zero feedback -- no "connection refused", no "timeout", nothing. If it IS a firewall, the user has no way to know that from the UI.

2. No timeout: The axios calls have no timeout set. For unreachable servers, the request hangs for 30+ seconds (TCP default) while the webview times out silently at 10 seconds.

3. Stale cache: The model cache is keyed by provider name ("ollama"), not by URL. If someone previously connected to localhost and then switches to a remote URL that fails, the cache returns the old localhost models -- making it look like the remote connection worked when it didn't.

4. Empty response = silence: When the model list comes back empty (from a failed connection), the handler just... doesn't respond. The webview times out with no feedback.

So even if the root cause for some users IS a firewall, the code currently makes it impossible to diagnose. I'll proceed with a PR that adds proper error propagation, timeouts, and user-facing error messages. That way if it IS a firewall, users will see something like "Connection refused to http://10.3.4.5:11434" instead of just silence.

[roomote]

Opened a draft PR with my attempt at addressing the error reporting side of this: #11470

The PR adds timeouts, error propagation, and user-facing error messages to the Ollama provider. Whether the root cause is a firewall, a misconfigured URL, or something else, users will now see a clear error message (e.g., "Connection refused", "timed out -- check firewall settings") instead of silence.

Feedback welcome!