Ollama Tool Calling Broken in GitHub Copilot? Roll Back 0.32.5

If GitHub Copilot in VS Code started printing raw tool-call markup or stopped running tools after Ollama updated to 0.32.4 or 0.32.5, test the local API first. If Ollama still returns a structured message.tool_calls array but the VS Code agent does not execute it, quit Ollama, install the official 0.32.1 release, restart VS Code, and repeat the same prompt. That rollback restored tool execution in the current public report, but the upstream issue remains open, so treat 0.32.1 as a temporary known-good version rather than a confirmed permanent fix.

This guide targets one narrow failure pattern:

• Ollama reports version 0.32.4 or 0.32.5;

• a local model appears in the VS Code model picker;

• ordinary chat still responds;

• an agent task that should call a tool instead prints tool syntax, produces garbled text, or stops without running the tool; and

• the same model and prompt worked before the Ollama update.

Do not roll back for every local-model failure. A model without tool-calling support, a context window that is too small, malformed tool arguments, or a broken proxy can produce similar symptoms for different reasons.

Prerequisites

Before changing versions:

1. Save your work and finish any active local model request.

2. Record your Ollama, VS Code, and GitHub Copilot Chat versions.

3. Confirm that the selected model supports tool calling.

4. Use one harmless prompt and one harmless tool for every comparison.

5. Download old installers only from the official Ollama GitHub release.

On Windows, capture the versions in PowerShell:

ollama --version
code --version
code --list-extensions --show-versions | Select-String 'github.copilot'

Expected result: a short version record you can attach to the upstream issue without exposing source code, prompts, or credentials.

Step 1: Separate the Ollama API from the VS Code Harness

VS Code's agent harness has to recognize a model's tool request, execute the tool, and return the result to the model. Test Ollama's native chat API before blaming either side of that boundary.

The following PowerShell request defines a read-only fake temperature tool. It asks the model to select the tool but does not execute anything:

$body = @{
  model = 'qwen3'
  messages = @(
    @{
      role = 'user'
      content = 'What is the temperature in Paris? Use the available tool.'
    }
  )
  stream = $false
  tools = @(
    @{
      type = 'function'
      function = @{
        name = 'get_temperature'
        description = 'Get the temperature for a city'
        parameters = @{
          type = 'object'
          required = @('city')
          properties = @{
            city = @{ type = 'string' }
          }
        }
      }
    }
  )
} | ConvertTo-Json -Depth 10

$response = Invoke-RestMethod `
  -Uri 'http://localhost:11434/api/chat' `
  -Method Post `
  -ContentType 'application/json' `
  -Body $body

$response.message.tool_calls | ConvertTo-Json -Depth 10

Expected result: a structured tool call whose function name is get_temperature and whose arguments contain Paris. If qwen3 is not installed, substitute the exact local model that failed in VS Code and that you already know supports tools.

Interpret the result before changing anything:

The upstream issue includes an important caveat: an Ollama collaborator compared 0.32.1 with 0.32.5 and found the structured response shape unchanged in a direct test, while tool calling worked through OpenCode. That is evidence for a compatibility problem somewhere in the server-parser-client path, not proof of a specific parser bug.

Step 2: Roll Back Windows to the Known-Good 0.32.1 Release

First quit Ollama from the Windows tray menu. Confirm that no active model request is running. Then download the official release asset and verify its SHA-256 hash before launching it:

$installer = Join-Path $env:TEMP 'OllamaSetup-0.32.1.exe'
$url = 'https://github.com/ollama/ollama/releases/download/v0.32.1/OllamaSetup.exe'
$expectedSha256 = '2f53afab45547896e66b2879174ee78bb1f079f4a20b0858e0e377da0c3631f0'

Invoke-WebRequest -Uri $url -OutFile $installer
$actualSha256 = (Get-FileHash -Path $installer -Algorithm SHA256).Hash.ToLowerInvariant()

if ($actualSha256 -ne $expectedSha256) {
  throw "Checksum mismatch for $installer"
}

Start-Process -FilePath $installer -Wait

The four checksums in this guide matched the sha256sum.txt asset attached to Ollama's official v0.32.1 release when rechecked on August 3, 2026. If Ollama replaces or withdraws that release, stop and re-check the release page instead of bypassing the mismatch.

Open a new PowerShell window and verify the installed version:

ollama --version

Expected result: the output identifies Ollama 0.32.1. If it still shows 0.32.5, locate every executable on PATH before repeating the install:

Get-Command ollama -All

Do not delete the model directory as part of this test. The version is the variable being changed; deleting models or configuration at the same time would make the comparison inconclusive.

Step 3: Restart the Entire VS Code Tool Loop

After the rollback:

1. Quit every VS Code window.

2. Start Ollama normally.

3. Open the same repository in VS Code.

4. Select the same local model.

5. Start a new agent chat.

6. Ask for one harmless, observable tool action, such as listing the current folder without modifying it.

Expected result: VS Code shows a tool invocation, requests approval if your settings require it, runs the tool, and incorporates the result into the next model response. It should not print raw tool-call tags as ordinary assistant text.

Repeat the native API test from Step 1. A useful comparison has four recorded facts: Ollama version, API result, VS Code result, and the exact model tag. If 0.32.1 restores the VS Code tool loop while every other variable remains fixed, keep that evidence with the issue report.

Step 4: Use the Correct Release Asset on macOS or Linux

The public reproduction was reported on Windows, so do not assume the same regression exists on every platform. If you reproduce the identical A/B result elsewhere, use the matching official v0.32.1 asset:

• macOS: Ollama.dmg, SHA-256 31a0ad28a8c86c1f5e998015a299f7f77b1e6bfb471f79e472f32539eb0cd1e7;

• Linux x86-64: ollama-linux-amd64.tar.zst, SHA-256 83b1f22841eb7f6c4900c6797f960ebaa09466874442ea5b8ae3da6980d3914c; or

• Linux ARM64: ollama-linux-arm64.tar.zst, SHA-256 20fb8d14694f73b97dc41519e27ef06166236207e7efe793f1698a43722215f2.

Quit Ollama, verify the downloaded asset against the official checksum file, and follow Ollama's platform installation instructions. Do not paste an architecture-specific archive over an unknown package-manager installation. Record the owning install method first so a future update can replace the same files cleanly.

Step 5: Capture Useful Logs If the Rollback Does Not Help

If both versions fail, the version regression is not established. Ollama's troubleshooting guide recommends checking server logs and supports trace-level output with OLLAMA_DEBUG=2. Trace logs can include prompts and local details, so use a harmless reproduction and redact before sharing.

On Windows, quit the tray app, then launch it from PowerShell with trace logging enabled:

$env:OLLAMA_DEBUG = '2'
& 'ollama app.exe'

Reproduce one tool request, then collect these facts:

• Ollama, VS Code, and Copilot Chat versions;

• operating system and accelerator;

• exact model tag;

• native /api/chat response shape;

• whether streaming is enabled;

• whether the problem appears in another client; and

• the smallest redacted log excerpt around the failed request.

Expected result: the report distinguishes a missing tool call from a tool call that arrived but was rendered as content. Do not publish raw traces that contain proprietary prompts, file paths, tokens, or source code.

Common Failure Modes

Why the Rollback Test Works

Ollama 0.32.1 is a useful control because the current reporter tested the same VS Code workflow on 0.32.5, downgraded to 0.32.1, and restored tool execution twice. The direct API test adds a second boundary: it shows whether the model server produced a structured tool request before the VS Code harness tried to interpret it.

That does not establish the final root cause. It does produce a reproducible report that maintainers can act on: one model, one harmless tool, two Ollama versions, and results from both the server API and the editor harness.

This follows the same structure that made Aident's Ollama networking guide useful: match the exact symptom, test one boundary, change one variable, and state the expected result. If the local server itself is unreachable, start with the Ollama network exposure guide instead of changing tool-call versions.

Verify a Read-Only Action Through Aident Loadout

After the local tool loop works, verify one external integration without copying a provider credential into the prompt. Install or update Aident Loadout by pasting:

Follow https://aident.ai/SETUP.md

Then use the public CLI to discover a read-only GitHub issue-search Action and inspect its schema before execution:

aident account auth status
aident capabilities search --query 'search GitHub issues and pull requests' --type action

Expected result: authentication is valid and discovery returns at least one read-only Action that can be inspected, preflighted, and executed through Aident Loadout. The measurable goal is one verified issue result with no GitHub write and no provider token copied into the chat.

Sources

• Ollama issue 17444: 0.32.4 and 0.32.5 appear to break tool calling in VS Code GitHub Harness, opened July 28, 2026

• Ollama v0.32.1 release, published July 16, 2026

• Ollama v0.32.1 SHA-256 checksums, rechecked August 3, 2026

• Ollama v0.32.5 release, published July 27, 2026

• Ollama: Tool calling, accessed August 2, 2026

• Ollama: Chat API, accessed August 2, 2026

• Ollama: Troubleshooting, accessed August 2, 2026

• Visual Studio Code: AI language models, accessed August 2, 2026

• Visual Studio Code: The coding harness behind GitHub Copilot, published May 15, 2026

Refresh this guide when Ollama closes issue 17444, publishes a stable release that the affected VS Code workflow verifies, changes its tool-call response format, or changes the official release assets and checksums.