# Connecting VS Code to Open WebUI as a Coding Agent Uses [Cline](https://cline.bot) 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](#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 | Mistake | Result | |---|---| | Omitting the word `Bearer` | `{"detail":"Not authenticated"}` | | Running `curl` in PowerShell | Aliased to `Invoke-WebRequest`; use `curl.exe` | | Including quotes copied around the token | 401 | `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: | Field | Value | |---|---| | API Provider | `OpenAI Compatible` | | Base URL | `http://avogadro.nakaguchi.org:3000/api` | | API Key | your token — **no `Bearer` prefix** | | Model ID | `qwen3-coder:30b` or your workspace variant | 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: ```powershell $PSVersionTable.PSVersion ``` `5.1.x` is the old one. `7.x` is current. **To update:** ```powershell 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](https://github.com/PowerShell/PowerShell/releases). **Without updating**, either call `curl.exe` explicitly: ```powershell 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.