What happened with Cline in STUPID-2026-0076?

Cline's experimental_repairToolCall path falls back to the jsonrepair library when standard JSON parsing of a streamed tool call fails. jsonrepair closes unterminated strings as-is instead of rejecting them, so a tool call cut off mid-argument comes out as syntactically valid but semantically corrupted JSON — and Cline executed it without any warning that truncation had occurred. Because the affected code path is generic (ai-sdk.ts's registration of experimental_repairToolCall, and json.ts's use of jsonrepair), it applies to any tool accepting a free-form string argument, including write_file (file contents) and terminal/shell command execution. The reporter's minimal repro fed a truncated write_file call — `{"path":"config/database.yml","content":"production:\n host: db.prod.internal\n password: correct-horse-battery-sta` — into the parsing path and got back a valid-looking object with the cut-off password string, no error raised.

How severe was the Cline failure?

The incident was rated 5.8/10 (medium). No named production incident was reported alongside this issue — it was filed as a code-level defect with a reproduction, not a user recounting data loss. The risk it describes is real regardless: any write_file or terminal argument truncated mid-string by a max_tokens limit would be silently written or executed with corrupted content (e.g. a cut-off password or config value landing on disk, or a partial shell command running) with no diagnostic signal to the model or the user. Cline's maintainers treated the report as credible — it was assigned to a maintainer and fixed in PR #13015, merged six days later on 2026-08-12, which adds truncation detection that rejects unterminated strings instead of repairing them.

What caused the Cline failure?

The root cause was classified as Other. The instruction given was: None specific to this bug — the defect lives in Cline's tool-call streaming pipeline itself and can trigger during any task where the model's tool-call arguments get cut off mid-value, most commonly by hitting a max_tokens limit while still writing a long string argument (file contents, a terminal command, a commit message).

STUPID-2026-0076

Cline's tool-call JSON repair silently executed truncated write_file and terminal arguments as valid

5.8

medium

August 6, 2026VerifiedReproducible

Instruction given
None specific to this bug — the defect lives in Cline's tool-call streaming pipeline itself and can trigger during any task where the model's tool-call arguments get cut off mid-value, most commonly by hitting a max_tokens limit while still writing a long string argument (file contents, a terminal command, a commit message).
Expected behavior
When a streamed tool call's arguments are truncated mid-value, Cline should surface the truncation as a recoverable error so the model can retry with the full argument, rather than treating the incomplete data as a successfully parsed tool call and executing it.
Actual behavior
Cline's experimental_repairToolCall path falls back to the jsonrepair library when standard JSON parsing of a streamed tool call fails. jsonrepair closes unterminated strings as-is instead of rejecting them, so a tool call cut off mid-argument comes out as syntactically valid but semantically corrupted JSON — and Cline executed it without any warning that truncation had occurred. Because the affected code path is generic (ai-sdk.ts's registration of experimental_repairToolCall, and json.ts's use of jsonrepair), it applies to any tool accepting a free-form string argument, including write_file (file contents) and terminal/shell command execution. The reporter's minimal repro fed a truncated write_file call — `{"path":"config/database.yml","content":"production:\n host: db.prod.internal\n password: correct-horse-battery-sta` — into the parsing path and got back a valid-looking object with the cut-off password string, no error raised.
Damage
No named production incident was reported alongside this issue — it was filed as a code-level defect with a reproduction, not a user recounting data loss. The risk it describes is real regardless: any write_file or terminal argument truncated mid-string by a max_tokens limit would be silently written or executed with corrupted content (e.g. a cut-off password or config value landing on disk, or a partial shell command running) with no diagnostic signal to the model or the user. Cline's maintainers treated the report as credible — it was assigned to a maintainer and fixed in PR #13015, merged six days later on 2026-08-12, which adds truncation detection that rejects unterminated strings instead of repairing them.

A Cline user (canblmz1) reported that the agent's tool-call error-recovery path could turn a truncated tool call into one that executes anyway, with corrupted arguments and no warning. When a model's streamed tool-call arguments get cut off mid-value — commonly by hitting a `max_tokens` limit while still writing a string — Cline's `experimental_repairToolCall` step falls back to the `jsonrepair` library to salvage a parse. `jsonrepair` closes unterminated strings rather than rejecting them, so the truncated call comes out looking like a normal, successfully parsed tool call instead of a failed one. Because the affected code sits in Cline's generic tool-call parsing layer, it isn't limited to one tool: any tool taking a free-form string argument is exposed, including `write_file` (file contents) and terminal/shell command execution. The reporter's minimal reproduction fed a truncated `write_file` call — a YAML config with a password cut off mid-string — through the parsing path and got back a valid-looking object containing the incomplete password, with no error raised anywhere in the chain. Cline's maintainers treated the report as credible: it was assigned, and a fix shipped as PR #13015 six days later, adding detection for unterminated strings so truncated arguments are now rejected and surfaced as a recoverable error instead of executed silently.