System message tools parser intercepts quoted tool syntax as real tool calls

[shanevcantwell]

Bug

The system message tools parser in interceptSystemToolCalls.ts treats any text matching tool call patterns as a real invocation. When a model tries to describe, quote, or explain its own tool syntax, the parser intercepts the quoted text and executes it as an actual tool call.

Observed behavior

1. Ask a model on the system message tools path to explain how its tools work
2. Model writes something like "The read_file tool is called with TOOL_NAME: read_file..."
3. Parser detects tool_name: at a chunk boundary after splitAtCodeblocksAndNewLines() splits on the newline
4. Parser treats the quote as a real tool call → "Continue tried to read path/to/the_file.txt"

Root cause

This is fundamentally the same class of bug as lmstudio-ai/lmstudio-bug-tracker#1592 (parser scans inside <think> blocks for tool call patterns). Both are context-free pattern matchers on output streams — neither distinguishes invocation context from conversational text.

Two specific mechanisms in Continue's parser:

1. Aggressive bare tool_name: start pattern
acceptedToolCallStarts in toolCodeblocks/index.ts lines 9-12:

["tool_name:", "```tool\nTOOL_NAME:"],

This is case-insensitive (detectToolCallStart.ts line 14). Any chunk starting with tool_name: triggers parsing — even mid-response, even in quoted/explanatory context. The comment says "Poor models are really bad at following instructions, alternate starts allowed."

2. Chunk-boundary detection loses positional context
splitAtCodeblocksAndNewLines() splits content at every backtick triple and newline. Each resulting chunk is checked independently via detectToolCallStart(). A newline-separated line starting with tool_name: triggers detection regardless of where in the response it appears.

Why this can't be fully fixed at the text level

Without Harmony-style structural tokens that distinguish tool invocations from content at the vocabulary level, any text-level parser faces a precision/recall tradeoff: tighten the patterns and weak models fail to trigger real tool calls; loosen them and quoted syntax triggers false positives. This is the same tradeoff LM Studio faces with its Harmony parser.

Files

• core/tools/systemMessageTools/toolCodeblocks/index.ts:9-12 — acceptedToolCallStarts
• core/tools/systemMessageTools/detectToolCallStart.ts:14 — case-insensitive matching
• core/tools/systemMessageTools/interceptSystemToolCalls.ts:70-74 — chunk-level detection
• core/tools/systemMessageTools/systemToolUtils.ts:7-9 — splitAtCodeblocksAndNewLines

Environment

Observed with qwen3.5-35b via LM Studio using system message tools path (capabilities: []).

[shanevcantwell]

Tangentially related: llama.cpp just merged an automatic parser generator that derives tool call parsing from Jinja templates, making it phase-aware by construction. This should reduce the volume of malformed tool output reaching downstream harnesses like Continue, since the inference layer will handle reasoning/tools/content boundaries more cleanly.

The system message tools parser is a separate code path, but the same design insight applies — parsing derived from structure definitions rather than pattern matching on the output stream.