Ollama tool calls are dropped when streaming delta has no id

[redbean87]

Before submitting your bug report

• I've tried finding an answer on the Continue docs site
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Windows 11
- Continue CLI: @continuedev/cli@1.5.47
- Model: gpt-oss:20b
- Provider: Ollama
- Model context: 65,536
- Agent capabilities: tool_use

Description

Continue CLI 1.5.47 drops Ollama streaming tool calls when the first tool-call delta contains an index but no id.

With gpt-oss:20b, Ollama returns valid structured tool_calls directly through its API. However, Continue's processToolCallDelta() drops the tool call when there is no id and no existing index-to-ID mapping.

The result is that tool arguments appear as plain assistant content:

{"filepath":"convex/schema.ts"}

The tool is never executed and the agent turn ends without a final response. Typing "continue" manually allows the agent to resume.

I verified the issue by patching processToolCallDelta() to generate a stable call_ ID when id is absent. This fixes the tool-call handling.

I verified the issue by patching processToolCallDelta() to generate a stable call_ ID when id is absent. This fixes the tool-call handling.

I found related Ollama/tool-calling issues, including #10711, but none describing this specific missing-ID/index-mapping failure.

To reproduce

1. Configure Continue CLI 1.5.47 to use gpt-oss:20b through Ollama with tool use enabled.
2. Start cn in a repository.
3. Give the agent a task requiring multiple tool calls.
4. After several successful tool calls, an Ollama tool-call delta is received with an index but no id.
5. Continue drops the tool call.
6. The tool arguments appear as plain assistant content, for example: {"filepath":"convex/schema.ts"}
7. The agent stops without executing the tool.
8. Entering "continue" allows the task to resume.

The same model was tested directly against the Ollama API with multiple sequential tool calls, and the API returned correctly structured tool_calls each time.

Log output

The Continue session successfully executed 13 tool calls before the failure.

The final assistant message contained:

{"filepath":"convex/schema.ts"}

but had no toolCalls or toolCallStates entry. Therefore Read(convex/schema.ts) was never dispatched.

The relevant Continue source is processToolCallDelta() in the CLI bundle:

if(e.id?(r=e.id,e.index!==void 0&&r&&n.set(e.index,r)):e.index!==void 0&&(r=n.get(e.index)),!r){
  xe.warn("Tool call delta without ID or valid index mapping",{toolCallDelta:e});
  return;
}

When the first Ollama delta has index but no id, n.get(e.index) returns undefined and the tool call is dropped.

A local patch that generates a stable call_<index> ID and stores it in the index-to-ID map fixes the issue.

[bunnysayzz]

I traced this to processToolCallDelta() in core/llm/stream.ts.

When Ollama returns a streaming tool-call delta with an index but no id, the current code falls through to the else branch which only updates an existing entry by id. Since there is no id and no existing mapping, the delta is silently dropped and the arguments surface as plain assistant text.

The reporter's patch is the right approach: generate a stable synthetic ID (call_<index>) when id is absent, so the index-keyed entry is created on the first delta and subsequent argument fragments accumulate correctly. The fix is a small change to processToolCallDelta() — add a fallback id = \call_${toolCall.index}`before the lookup whentoolCall.id` is undefined.

I'll put together a PR with a regression test that fails on the current code and passes with the fix. Happy to take this if no one else is working on it.