Tool calling not executed with Ollama models (outputs raw tool JSON instead of performing actions)

[nascimentoraphael]

Steps to Reproduce
Install and run Ollama locally

Pull a model that supports tool calling:

ollama pull qwen2.5-coder:14b

Configure OpenClaude to use Ollama:

export CLAUDE_CODE_USE_OPENAI=1
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_MODEL=qwen2.5-coder:14b

Start OpenClaude:

bun run dev

Run a prompt that requires tool usage:

Summarize this repository structure.
Expected Behavior

OpenClaude should:

Detect the repository context
Invoke the appropriate internal tool (e.g., file system or repository inspection)
Return a structured summary of the local project
Actual Behavior

Instead of executing the tool, the model returns a raw tool call:

{
"name": "WebSearch",
"arguments": {
"query": "repository structure"
}
}

or previously:

{
"name": "repository_structure",
"arguments": {...}
}

or even natural language describing how to call the tool:

"The correct request would look like this..."

No actual tool execution occurs.

Environment
OpenClaude version: v0.1.8
OS: Linux (Ubuntu-based)
Terminal: Bash
Provider: Ollama (OpenAI-compatible endpoint)
Model: qwen2.5-coder:14b (also tested with llama3.1:8b and gemma3:latest)
Logs / Screenshots

Example output:

❯ Summarize this repository structure.

● {
"name": "WebSearch",
"arguments": {
"query": "repository structure"
}
}

For gemma3:

API Error: 400 ... "does not support tools"
Additional Context
The provider connection is successful:
/v1/models endpoint reachable (status 200)
OpenClaude shows "Ready"
Multiple models tested:
gemma3:latest → explicit error (no tool support)
llama3.1:8b → describes tool usage instead of executing
qwen2.5-coder:14b → outputs raw JSON tool calls
This suggests a potential issue in:
tool execution loop
or OpenAI-compatible tool mapping layer for Ollama

[FyreNight]

Same, I verified I have same outputs in 0.1.7 and 0.1.8
I have had better luck with other models, but each ollama model seems to have some sort of issue.
qwen2.5-coder:7b - outputs json rather than running tools
gemma4:e4b - seems to "work" but doesn't appear to actually execute tool commands. Example won't read files
qwen2.5:7b-instruct - works with tools (atleast the few I've tried,) but uses wrong directory for creating files

[foyzul09]

same issue for me as well

[auriti]

I did a code-path review against current main.

What I can separate cleanly:

1. Models that return plain text / raw JSON instead of tool_calls

   • If the Ollama OpenAI-compatible endpoint returns normal assistant text like { \"name\": ... } or an explanation of how to call a tool, OpenClaude currently treats that as plain model output, not executable tool intent.
   • That is expected with the current client-side contract: the tool loop depends on standard OpenAI tool_calls, not arbitrary text that merely looks like a tool invocation.
   • A previous attempt to add broad text-parsing fallback for Gemma-style tool text (fix(openaiShim): parse Gemma 4 pythonic tool calls from content text #380) ran into correctness/safety regressions and was not considered safe to merge in that form.

2. Models that explicitly say they do not support tools

   • Errors like does not support tools are provider/model capability limits, not a working tool call that OpenClaude is failing to execute.

3. Adjacent local-provider issues that may still matter

   • There is still a separate local-provider compatibility area around things like max_tokens vs max_completion_tokens and tool-result/image handling. That work is closer to PR fix: forward reasoning content, Ollama max_tokens fallback, tool result images #237 than to a generic “execute raw JSON tool text” fix.

So my current read is:

• gemma3:latest reporting no tool support is a model/provider capability issue
• qwen2.5-coder returning raw JSON or descriptive text is most likely the model/provider not emitting standard OpenAI tool_calls
• I do not think the safe next move is to add a generic text-to-tool parser without a much tighter, provider-specific repro

Most useful next debugging artifact if someone can provide it:

• the raw HTTP response body from the Ollama OpenAI-compatible endpoint for one failing request
• specifically whether the model is returning message.tool_calls versus plain message.content

That would tell us whether this is:

• a client/tool-loop bug
• a schema/provider-compat issue
• or simply a model that does not follow the expected tool-calling contract.

[jhonatan2760]

I have the same problem here using qwen2.5-coder:32b

[foyzul09]

so are there no solution yet

[Dev-Adrianoo]

Here's the raw HTTP response from the Ollama endpoint for a failing request with qwen3.5:9b:

{
  "id": "chatcmpl-324",
  "object": "chat.completion",
  "model": "qwen3.5:9b",
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": "Olá! Tudo bem..."
    }
  }]
}

The model is returning the response inside message.content as plain text, no message.tool_calls field at all. This confirms the issue is on the Ollama/model side: qwen3.5:9b is not emitting standard OpenAI tool_calls format even when tools are provided in the request.
Tested on:

OS: Windows 11
Ollama: v0.20.4
Model: qwen3.5:9b

[0xdiass]

Same problem with qwen2.5-coder:7b and qwen2.5-coder:32b

For me takes more than 3,4 minutes, sometimes shows the JSON, other times API Error: Please wait a moment and try again

[Vasanthdev2004]

This is a known pain point with Ollama models outputting raw tool JSON instead of executing actions. It's related to how the tool call format is parsed. Tracking for a fix — this affects many users.

[adrianotriat-hub]

Any solution?