Connecting VS Code to Open WebUI as a Coding Agent

Uses Cline in VS Code with a self-hosted Open WebUI instance backed by Ollama, so agentic coding runs against a lab-hosted model instead of a commercial API.

Setup documented here: Open WebUI at avogadro.nakaguchi.org:3000, serving qwen3-coder:30b via Ollama.

Prerequisites

• VS Code
• An account on the Open WebUI instance
• Network access to the server (it resolves to a private address, 10.44.104.23, so campus network or VPN is required — this will not work from home without VPN)
• WSL recommended (see Known Issues)

Step 1 — Get an authentication token

1. Log into Open WebUI in Chrome or Firefox
2. Press F12 → Application tab
3. Expand Cookies → click your Open WebUI origin
4. Copy the value of the cookie named token

It's a long string starting with eyJ containing two dots.

Note: this token expires — four weeks by default, sooner with SSO. When the agent starts returning 401s, re-copy it. Requesting a real API key from the admin avoids this.

Step 2 — Verify the token

Run in CMD, all on one line:

curl -H "Authorization: Bearer YOUR_TOKEN" http://avogadro.nakaguchi.org:3000/api/models

A JSON list of models means success.

Common mistakes

Bearer is required in curl because you're writing the raw header. It must be omitted in Cline's API Key field, because Cline adds it for you.

Step 3 — Find your model ID

From the JSON above, locate the "id" field. Use that exact string, not the friendly display name.

curl -H "Authorization: Bearer YOUR_TOKEN" http://avogadro.nakaguchi.org:3000/api/models | findstr "\"id\""

Confirm the model reports "capabilities":["completion","tools"]. Without tools, agentic use will not work — the model will chat but never invoke file or terminal operations.

Step 4 — Configure Cline

Install Cline from the VS Code Extensions panel, then open its settings gear:

Note the URL ends in /api, with no /v1.

Step 5 — Verify

Send hi in the Cline chat.

Success: a reply appears with a token-usage line showing input/output counts.

First request is slow. If the model shows "loaded":false, Ollama must load 18.5 GB from disk. Allow two full minutes before assuming failure. Warming it up with a plain curl request first avoids mistaking this for a broken config.

Test the agent loop

Connecting and agentic behavior are different things. Open a real project folder and ask:

read the files in this folder and summarize what the project does

You should see a tool-call box — "Cline wants to read src/main.py" — with approve/reject buttons. That confirms tool calling works. If it only describes what it would do, revisit Step 4.

Known Issues

Works in WSL, not in Windows VS Code

Encountered during this setup: identical config replies in a WSL Remote window but spins indefinitely in native Windows VS Code.

Ruled out: no proxy (ProxyEnable = 0x0, no AutoConfigURL), and Test-NetConnection avogadro.nakaguchi.org -Port 3000 returns TcpTestSucceeded : True.

Most likely cause: extensions in a WSL Remote window use separate storage from the local Windows install. Configuration does not carry over. Verify all four fields are populated in the Windows window specifically.

Diagnostic: Help → Toggle Developer Tools → Network, clear, then send a message. If no request to the host appears, the request is never being constructed — a config or extension-state problem, not a network one.

Recommendation: work in WSL regardless. Cline runs terminal commands, and a real bash shell avoids PowerShell quoting quirks and path translation. Open projects via WSL: Open Folder in WSL and keep files under ~/, not /mnt/c/ — the latter is slow enough that an agent reading many files will crawl.

Cancelling a request

Use the Cancel button, Escape, or Developer: Reload Window. Cancelling client-side doesn't stop Ollama generating — avoid stacking retries on a shared machine.

Here's the section to add under Known Issues, after the WSL entry:

PowerShell version — curl behaves differently

Windows PowerShell 5.1 (the blue icon, preinstalled) aliases curl to Invoke-WebRequest, which does not accept -H the way real curl does. The header is silently mangled, producing {"detail":"Not authenticated"} or a parameter-binding error, even when the token is correct.

PowerShell 7+ removed that alias. curl invokes the genuine curl.exe, so the commands in this README work as written.

Check which you're running:

$PSVersionTable.PSVersion

5.1.x is the old one. 7.x is current.

To update:

winget install --id Microsoft.PowerShell --source winget

This installs alongside Windows PowerShell rather than replacing it — you'll have a separate PowerShell 7 entry (black icon) in the Start menu. If winget isn't available, download the MSI from github.com/PowerShell/PowerShell/releases.

Without updating, either call curl.exe explicitly:

curl.exe -H "Authorization: Bearer YOUR_TOKEN" http://avogadro.nakaguchi.org:3000/api/models

or run the commands in CMD, which ships real curl on Windows 10 and 11.

Why this matters beyond setup: Cline runs terminal commands as part of its agent loop, using VS Code's default shell. On Windows that's usually PowerShell 5.1, whose aliasing and quoting differ from the bash syntax most models are trained to emit. Commands the agent writes may fail for reasons unrelated to the code. Updating to PowerShell 7 helps; working in WSL avoids the problem entirely.

Two other differences worth knowing while you're on 5.1: Test-NetConnection works in both versions, so that diagnostic was unaffected. And 5.1 also aliases wget and ls to PowerShell cmdlets, which trips up pasted shell snippets in the same way.