Fix Roo Code Ollama Connection Errors in 5 Steps

Why Roo Code Refuses to Talk to Your Local Ollama Server

Related: Fixing Painfully Slow Whisper Transcription →

When you attempt to connect the Roo Code extension in VS Code to a local Ollama instance, encountering a generic connection error is remarkably common. You click the model dropdown or send a coding prompt, only to be met with FetchError: connect ECONNREFUSED 127.0.0.1:11434, an infinite loading spinner, or a blank provider menu.

This breakdown happens because Roo Code (and its parent project, Cline) runs inside VS Code's extension host. The extension relies on a sandboxed Webview UI that executes API requests similar to a web browser. When you point Roo Code at http://localhost:11434 or http://127.0.0.1:11434, your requests cross an execution boundary. If Ollama is listening only on a strict loopback interface, blocking cross-origin requests, or running out of VRAM when processing long file contexts, the link drops instantly.

A standard roo code ollama connection error usually traces back to three underlying causes:

1. Network interface mismatch (binding to 127.0.0.1 vs localhost vs 0.0.0.0).
2. Missing or misconfigured Cross-Origin Resource Sharing (CORS) headers in Ollama.
3. Out-of-memory (OOM) crashes triggered when Roo Code sends context histories that exceed your GPU's available VRAM.

Fixing these issues requires configuring your operating system environment variables, adjusting Roo Code's provider settings, and tuning model context limits.

Step 1: Resolving Host, Port, and Network Binding Mismatches

Related: Fix Open WebUI Showing No Models in the Dropdown →

The most frequent error, cline ollama connection refused or ECONNREFUSED, means Roo Code sent a request to a network port where no service responded. To connect Roo Code to Ollama on port 11434, the server must be actively listening on an IP address accessible by the VS Code process.

Verifying Ollama Engine Status

Before changing extension settings, confirm that Ollama is actually running on your machine:

curl http://127.0.0.1:11434/api/tags

If this returns a JSON payload listing your installed local models (such as qwen2.5-coder:14b or deepseek-r1:8b), the server is active. If the terminal prints Connection refused, launch the Ollama application or start the daemon via your command line using ollama serve.

Address Resolution: localhost vs 127.0.0.1

Node.js v17+ changed how IP hostnames resolve, prioritizing IPv6 addresses (::1) over IPv4 (127.0.0.1). If Ollama binds strictly to IPv4 127.0.0.1:11434 but Roo Code attempts to reach http://localhost:11434, Node may try ::1:11434 and fail immediately.

In Roo Code's settings tab:

• Set API Provider to Ollama.
• Change the Base URL from http://localhost:11434 to http://127.0.0.1:11434.

Using the explicit IPv4 address bypasses local DNS lookup latency and prevents IPv6 binding errors entirely.

Fixing WSL2 and Remote Development Bindings

If you run VS Code on Windows while Ollama runs inside Windows Subsystem for Linux (WSL2), or if you use VS Code Remote SSH, 127.0.0.1 will not route correctly. WSL2 operates inside a lightweight hypervisor with its own virtual network adapter.

To allow external connections to your Ollama engine, bind the service to 0.0.0.0 (all network interfaces).

On Linux or WSL, launch Ollama with the host variable:

OLLAMA_HOST=0.0.0.0:11434 ollama serve

When connecting from a host OS into WSL2, set the Base URL in Roo Code to your WSL instance's IP address (for example, http://172.28.128.1:11434) or set up port forwarding using netsh on Windows.

Step 2: Fixing Cross-Origin (CORS) Blocks for VS Code Extensions

Related: Secure Ollama with Nginx, HTTPS, and a Password →

Even when the port is reachable, web request security can block the connection. Roo Code's user interface runs inside a VS Code Webview context. Requests originating from this environment carry headers like Origin: vscode-webview://....

By default, Ollama blocks requests from unknown origin headers to prevent malicious websites from manipulating your local LLM engine. When CORS blocks the connection, VS Code's internal logs will show an HTTP 403 Forbidden status or an empty response payload without a standard network error code.

To fix this, you must configure the OLLAMA_ORIGINS environment variable to accept requests from VS Code.

Setting CORS Permissions on macOS

If you run Ollama as a macOS background service, terminal environment variables in ~/.zshrc are ignored by the background launch agent. You must register the environment variable using launchctl.

Open your terminal and run:

launchctl setenv OLLAMA_ORIGINS "*"

Then restart the Ollama application from your Mac menu bar (Quit Ollama, then reopen it from Applications).

Setting CORS Permissions on Windows

1. Press Win + R, type sysdm.cpl, and press Enter to open System Properties.
2. Navigate to the Advanced tab and click Environment Variables.
3. Under User variables, click New.
4. Set Variable name to OLLAMA_ORIGINS.
5. Set Variable value to *.
6. Click OK, then restart Ollama from the Windows System Tray (right-click the Ollama icon in the taskbar and click Exit, then launch it from the Start Menu).

Setting CORS Permissions on Linux (Systemd)

If Ollama runs as a Linux service managed by systemd, configure the unit environment:

sudo systemctl edit ollama.service

Add the following block under the [Service] section:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=*"

Save and exit the editor, then reload systemd configurations and restart the engine:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Step 3: Resolving Model Context Overflow and VRAM Out-of-Memory Crashes

Related: How to Stop Ollama From Unloading Models (keep_alive) →

A subtle issue during local LLM setup occurs when the connection succeeds initially, but drops midway through a task. Roo Code reads file structures, code contents, and terminal outputs, packaging them into large context windows.

If Roo Code sends a 32,000-token prompt context to a local model configured with a standard 2,048-token context window, Ollama will attempt to allocate additional KV-cache memory in your GPU VRAM. If your graphics card runs out of VRAM, the Ollama process crashes silently, causing Roo Code to display a connection error.

Matching Model Modelfiles with Hardware Realities

Local coding models like qwen2.5-coder:14b or llama3.1:8b require significant VRAM when handling large context limits.

To fix context crashes:

1. Open Roo Code settings.
2. Locate the Model Context Window field.
3. Manually restrict the context window size to match your hardware limits instead of leaving it unconstrained.

For a 12GB or 16GB GPU running a 14B parameter model, setting the context limit to 8,192 tokens or 16,384 tokens provides stability without exhausting VRAM.

Updating Model Context Limits in Ollama

You can explicitly instruct Ollama to handle larger context windows by creating a custom Modelfile.

Create a file named Modelfile on your system:

FROM qwen2.5-coder:14b
PARAMETER num_ctx 16384

Build the custom context-aware model:

ollama create qwen2.5-coder-16k -f ./Modelfile

In Roo Code, select qwen2.5-coder-16k as your active model name. This guarantees that Ollama pre-allocates the appropriate memory buffers at startup rather than crashing dynamically when a long context arrives.

Step 4: Testing Connections with Curl and VS Code Developer Tools

Related: Fix Continue in VS Code Not Connecting to Ollama →

When troubleshooting, isolate whether the failure lives inside Ollama or within VS Code's environment.

Testing API Handshakes via Command Line

Run a direct generation test using curl from your command line:

curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5-coder:14b",
  "prompt": "Write a python print statement",
  "stream": false
}'

If this command completes and returns a JSON object containing the model response, Ollama is functioning properly.

Next, test your CORS configuration by simulating a Webview origin header:

curl -i -H "Origin: vscode-webview://1234" http://127.0.0.1:11434/api/tags

Inspect the returned HTTP headers. Look for:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

If Access-Control-Allow-Origin is missing from the output, your CORS environment variable (OLLAMA_ORIGINS) was not applied properly by the server process.

Using VS Code Developer Tools

If CLI tests pass but Roo Code still displays a connection error, inspect the underlying extension logs inside VS Code:

1. Press Ctrl + Shift + P (or Cmd + Shift + P on macOS).
2. Type and select Developer: Toggle Developer Tools.
3. Switch to the Console tab and clear existing logs.
4. Attempt a request using Roo Code.

Look for red error traces in the console.

• ERR_CLEARTEXT_NOT_PERMITTED indicates web security policies are blocking non-HTTPS network traffic.
• net::ERR_CONNECTION_REFUSED means the target IP/port setting in Roo Code is pointing to the wrong network interface.
• HTTP 500 Internal Server Error indicates that Ollama received the request but crashed, typically due to an out-of-memory error on the host GPU.

Ollama Environment Variables and Roo Code Configurations

Related: A One-File Docker Compose Stack for Ollama and Open WebUI →

The table below outlines the necessary configuration settings required to maintain a stable local link between Ollama and Roo Code.

Step 5: Configuring Roo Code Settings for Local Execution

With environment variables set and hardware constraints established, verify your configuration settings within the VS Code UI.

1. Click the Roo Code gear icon in the extension panel to open its settings pane.
2. Set API Provider to Ollama.
3. Set Base URL to http://127.0.0.1:11434.
4. Select your pulled model from the dropdown list. If the list is empty, type the model name manually (such as qwen2.5-coder:14b).
5. Set Context Window manually to 8192 or 16384 depending on your available VRAM.

If you prefer using the OpenAI Compatible provider option instead of the native Ollama preset:

• Set Base URL to http://127.0.0.1:11434/v1.
• Input ollama as the API Key (Ollama does not check API keys, but the client interface requires a non-empty string).

Restart VS Code completely after changing environment variables. Once reloaded, Roo Code will maintain a reliable, persistent connection to your local Ollama models.

Frequently Asked Questions

Why does Roo Code say "Failed to fetch models" even when ollama list works in terminal?

This occurs because terminal commands execute directly against local interfaces, whereas VS Code webviews issue requests through sandboxed extension runtimes subject to CORS. If OLLAMA_ORIGINS is not explicitly set to *, the server drops webview fetch calls while continuing to respond to standard terminal requests.

Should I select "Ollama" or "OpenAI Compatible" in Roo Code settings?

Selecting "Ollama" uses native endpoints (/api/generate and /api/chat) tailored specifically for local Ollama deployments. Selecting "OpenAI Compatible" uses the /v1/chat/completions translation layer. The native "Ollama" provider setting offers lower latency, while "OpenAI Compatible" can be useful if you need custom middle layer proxies like LiteLLM.

How do I fix context window crashes when working on large codebases in Roo Code?

To prevent crashes, limit the context size sent by Roo Code. Reduce the Context Window setting in Roo Code to 8192 tokens and build a custom model using a Modelfile containing PARAMETER num_ctx 8192. This ensures Ollama does not attempt to allocate dynamic KV-cache memory beyond your GPU's physical VRAM capacity.

Why does Ollama disconnect when running inside WSL2 while VS Code runs on Windows?

WSL2 operates on a separate virtual network adapter. When Ollama runs in WSL2 using default settings, it binds exclusively to 127.0.0.1 inside the Linux virtual environment, rendering it unreachable from the Windows host. Setting OLLAMA_HOST=0.0.0.0:11434 inside WSL2 allows Windows applications to connect directly via your WSL instance's network IP address.