Harden SDK against empty tool_calls arrays from OpenAI-compatible providers

[Halcyonhal9]

Summary

When using the Copilot SDK with OpenAI-compatible backends (vLLM, Ollama, LM Studio), the model may return tool_calls: [] (empty array) instead of null/omitting the field. The SDK interprets the presence of the tool_calls key as an indication that tool execution is pending, enters its tool-call handling path, finds no tools to execute, and loops indefinitely — burning tokens and never producing a response.

This is the same class of bug that was fixed in the Codex CLI (openai/codex#1234) and in the OpenAI Python SDK itself (openai/openai-python#2061, fixed in v1.62.0 via PR #2106).

Root cause

Per the OpenAI Chat Completions API spec, tool_calls should be null (or absent) when the model does not invoke any tools. However, several widely-used OpenAI-compatible inference engines return tool_calls: [] instead:

• vLLM: Multiple open issues — #13978, #12937, #17161, #18006, #34792
• Ollama / LM Studio: Consistently include tool_calls: [] in all responses

While this is technically an upstream spec-compliance issue, the impact on the SDK is severe (infinite loop, unbounded token burn), and the fix is trivial. The Codex CLI already ships this hardening.

Reproduction steps

1. Start a vLLM or Ollama server serving any model (e.g., Qwen3-235B-A22B, DeepSeek-R1, Gemma-3):

   # vLLM example
   vllm serve Qwen/Qwen3-235B-A22B-FP8 --enable-auto-tool-choice --tool-call-parser hermes

2. Configure the Copilot SDK to use the local endpoint as the provider.
3. Register at least one tool with the SDK.
4. Send a chat message where the model responds with text only (no tool invocation needed).
5. Observed: The model returns a response with tool_calls: []. The SDK enters tool-call handling, finds nothing to dispatch, but does not exit cleanly — it loops or hangs indefinitely, never surfacing the text response.
6. Expected: The SDK should treat tool_calls: [] the same as tool_calls: null — skip tool handling and emit the text response.

Suggested fix

The same one-line fix applied in the Codex CLI (commit):

# Pseudocode — wherever the SDK checks for tool_calls presence:
- if hasattr(message, 'tool_calls') and message.tool_calls:
+ if hasattr(message, 'tool_calls') and message.tool_calls and len(message.tool_calls) > 0:

Or equivalently, normalize tool_calls: [] → None early in the response processing pipeline.

This is a defensive hardening measure — it costs nothing in the happy path and prevents a severe failure mode (infinite loop + token burn) when the SDK is used with non-OpenAI backends, which is a common and growing use case.

References

Issue	Status
openai/codex#1234 — Codex CLI fix for empty tool_calls	Closed/Fixed
openai/openai-python#2061 — Python SDK tool_calls: [] bug	Closed/Fixed (v1.62.0)
vllm-project/vllm#13978 — Llama template fails on tool_calls=[]	Open
vllm-project/vllm#34792 — Iterable consumption empties tool_calls	Open
anomalyco/opencode#4255 — OpenCode hangs on tool_calls: []	Open

[github-actions]

Thanks for the detailed bug report, @Halcyonhal9!

This is an excellent catch with solid references to upstream fixes. I've labeled this as:

• bug — infinite loop causing token burn
• sdk/dotnet, sdk/go, sdk/nodejs, sdk/python — affects all SDK implementations
• priority/high — severe impact (infinite loops + unbounded costs)

The issue is well-documented with reproduction steps and a suggested fix. The defensive hardening approach makes sense given the prevalence of OpenAI-compatible backends returning tool_calls: [] instead of null.

AI generated by Issue Triage Agent

[SergioChan]

Thanks for the detailed report — I started digging into this and I want to make sure the fix lands in the correct layer.

I checked the current tree and most tool-call execution appears to be brokered through session/RPC flows rather than direct parsing in the language SDK folders. Before I open a PR, could a maintainer confirm the intended patch point(s):

• Node SDK response normalization path
• Python SDK response normalization path
• Go SDK response normalization path
• Dotnet SDK response normalization path

If there is a shared response parser where should be normalized to null/absent once, I can target that directly with regression tests.

[SergioChan]

Small correction to my previous comment (shell ate code spans): I meant the main branch and the tool_calls field specifically.

Happy to open a focused PR as soon as maintainers confirm the intended normalization point.

[SergioChan]

Correction to my previous comment (shell formatting ate inline code spans).

I started tracing this in the current main branch and couldn’t find a direct Chat Completions parsing path in the SDK layers (the Node/Go/.NET clients appear to consume protocol session events rather than raw message.tool_calls payload checks).

Could you point to the specific package/runtime path where the empty-array loop is happening today (or share a minimal log snippet from one affected run)?

Once I have that exact code path, I can put up a narrowly scoped fix + regression test quickly.

[Halcyonhal9]

Correction to my previous comment (shell formatting ate inline code spans).

I started tracing this in the current main branch and couldn’t find a direct Chat Completions parsing path in the SDK layers (the Node/Go/.NET clients appear to consume protocol session events rather than raw message.tool_calls payload checks).

Could you point to the specific package/runtime path where the empty-array loop is happening today (or share a minimal log snippet from one affected run)?

Once I have that exact code path, I can put up a narrowly scoped fix + regression test quickly.

The CLI binary appears to handle the Chat Completions parsing, tool execution loops, and event emission. So the bug is in the cli layer, not the sdk itself.