[ENHANCEMENT] v3.37+ forces native tool calling (XML selector removed) → SGLang openai/gpt-oss-120b (HarmonyParser) returns 500 structure_info not used with HarmonyParser; v3.36.16 works with XML

[terr4n]

Problem (one or two sentences)

Summary
When using Roo Code with an OpenAI-Compatible endpoint backed by SGLang serving openai/gpt-oss-120b (HarmonyParser), Roo Code v3.36.16 works perfectly if Tool Call Protocol = XML.
Starting from v3.37+, the Tool Call Protocol selector is removed and new tasks are forced to use native tool calling, which makes SGLang crash with a 500 error (structure_info not used with HarmonyParser). This blocks agent/tool workflows entirely for this stack.

Roo release notes mention that new tasks default to native tool calling.
Roo Code Docs

Context (who is affected and when)

The PR that removed the XML selection/forces native for new tasks:

Environment

• Roo Code: 3.36.16 (works with XML); 3.37.x (breaks due to forced native)
• Provider: OpenAI-Compatible (self-hosted endpoint)
• Model: openai/gpt-oss-120b
• Backend: SGLang OpenAI-compatible server (NVIDIA container (nvcr.io/nvidia/sglang:25.12-py3) / local network)
• Asus Asccent GX 10 (DGX Spark)

Steps to reproduce

1. Run SGLang OpenAI-compatible server serving openai/gpt-oss-120b (HarmonyParser).
2. Configure Roo Code to use OpenAI-Compatible provider pointing to this endpoint, model openai/gpt-oss-120b.
3. In Roo Code v3.36.16, set Tool Call Protocol = XML in provider settings. Run any task that triggers tools (e.g., DevOps mode instructions that run a command). ✅ Works.
4. Update Roo Code to v3.37+ (or create a new task where protocol is forced to native). Run the same task. ❌ Fails with HTTP 500 from SGLang.

Expected behavior

• Keep the ability to force XML tool protocol (at least for OpenAI-Compatible endpoints / per model / per task), OR
• Add a fallback: if native tool calling fails (500/unsupported), automatically retry with XML, OR
• Allow an advanced switch to disable native tool calling for OpenAI-Compatible endpoints.

Actual behavior

• Roo Code shows: OpenAI completion error: 500 status code (no body)
• SGLang server logs show NotImplementedError: structure_info not used with HarmonyParser (see below)

SGLang error log (server)
Error in request: structure_info not used with HarmonyParser Traceback (most recent call last): ... File ".../function_call_parser.py", line 139, in get_structure_tag get_structure_info = self.detector.structure_info() File ".../gpt_oss_detector.py", line 241, in structure_info raise NotImplementedError("structure_info not used with HarmonyParser") NotImplementedError: structure_info not used with HarmonyParser

Why XML works
With XML protocol, Roo does not send native tools/tool_choice constraints in the OpenAI payload, so SGLang doesn’t enter the HarmonyParser structure-constraint path that throws NotImplementedError.

Related references
`Roo Code 3.36.13 notes: native default, XML still available in provider settings
https://docs.roocode.com/update-notes/v3.36.13

Roo Code 3.37 notes: new tasks default to native tool calling
https://docs.roocode.com/update-notes/v3.37

PR removing XML selector / forcing native for new tasks (#10281)
#10281

SGLang issue hinting HarmonyParser/grammar/tool_choice limitations for gpt-oss
sgl-project/sglang#9980
`

Desired behavior (conceptual, not technical)

Compatibility request: please keep (or restore) an option to force XML tool calling (legacy) — or at least provide an automatic fallback to XML — for OpenAI-Compatible / local-model setups. On my stack (SGLang serving openai/gpt-oss-120b), everything works reliably on Roo Code v3.36.16 when I can choose XML, but v3.37+ defaults new tasks to native tool calling and my endpoint returns API errors. I know this has already been discussed (Issue #10312, closed as “not planned”), but I’m adding this preference in hopes of a compromise so users can keep updating while still using the older working mechanism when needed.
Link: https://github.com/RooCodeInc/Roo-Code/issues/10312

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

In PR #10281 (v3.37), XML tool protocol was deprecated and forced to native for all new tasks. The resolveToolProtocol() function now always returns TOOL_PROTOCOL.NATIVE regardless of user preferences. This breaks users with OpenAI-Compatible endpoints backed by servers like SGLang that do not support native tool calling (the HarmonyParser throws NotImplementedError: structure_info not used with HarmonyParser).

Proposed Implementation

Restore Tool Protocol selector for OpenAI-Compatible provider:

1. Modify src/utils/resolveToolProtocol.ts - For the "openai" provider (OpenAI-Compatible), respect the user's toolProtocol preference instead of forcing native:

   // For OpenAI-Compatible provider, respect user preference since backend compatibility varies
   if (providerSettings.apiProvider === "openai" && providerSettings.toolProtocol) {
     return providerSettings.toolProtocol
   }

2. Add Tool Protocol selector to OpenAICompatible.tsx - Add a dropdown allowing users to choose between "native" (default) and "xml" tool protocols:

   • Use a Select component with options for "Native (Default)" and "XML (Legacy)"
   • Store the selection in providerSettings.toolProtocol
   • Add descriptive text explaining when to use XML (e.g., for backends that don't support native tool calling)

3. Update tests in resolveToolProtocol.spec.ts - Add test cases covering:

   • OpenAI-Compatible provider with XML preference should return XML
   • OpenAI-Compatible provider without preference should return Native
   • Locked protocol should still take precedence

This approach will:

• Allow OpenAI-Compatible users (SGLang, etc.) to explicitly opt for XML tool calling when their backends don't support native tools
• Maintain native as the default for users who don't explicitly change the setting
• Be minimally invasive (only affects OpenAI-Compatible provider, not other providers)

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[jgicquel]

Same kind of error for me with OpenAI Compatible provider : LiteLLM / vLLM backend

Extension version: 3.37.1
Provider: openai

400
OpenAI completion error: 400 litellm.BadRequestError: Hosted_vllmException - "auto" tool choice requires --enable-auto-tool-choice and --tool-call-parser to be set. Received Model Group=Codeo
Available Model Group Fallbacks=None

[slamj1]

I can confirm this issue still exists in 3.37.1