Cline bug silently drops command output and exit status over VS Code Remote-SSH

What the report says

According to a report on dev.to, a user running Cline 4.0.12 through a VS Code Remote-SSH session connected to a Linux virtual machine found that the extension's execute_command tool was discarding the real stdout, stderr and exit status of the shell commands it ran. Whatever actually happened in the shell, the result handed back to the model was a generic success. The user filed the problem as issue 12723 on Cline's GitHub tracker.

The practical consequence was that a Ruff lint check which actually failed was recorded as passing. As the dev.to post quotes the reporter, the defect "caused a Ruff failure to be treated as passing and inaccurate verification evidence to be committed to the project issue tracker." For an agentic workflow, that is close to the worst possible failure shape: the agent generates its own verification evidence, the evidence is wrong, and nothing errors out anywhere along the way.

The reproduction

The minimal reproduction described in the post is deliberately small: a bash one-liner that writes distinct markers to stdout and stderr, then exits with status 7. The VS Code terminal displayed both output streams and the exit code correctly. Cline's tool result still reported success. The terminal a human could see and the result the model received told two different stories.

The post adds that the same false-positive behaviour reproduced on both Cline 4.0.11 and 4.0.12, meaning the defect had already survived one release cycle before anyone reported it.

What the report does not establish

The dev.to author is explicit about the limits of the finding. This is one filed, verified and reproducible report, scoped specifically to VS Code's Remote-SSH terminal mode. It does not demonstrate the same failure across Cline's other terminal integrations, and maintainers have not yet confirmed a root cause or shipped a fix. The post also assigns the issue a low severity score of 3.8, on the grounds that in this instance no data was lost and nothing was deployed on the strength of the false result.

Why it matters

A small blast radius in this one case does not make the bug class benign. The core contract between an agent and its tools is that self-reported command output tracks reality; when a failing check can come back as a pass, every downstream decision the agent makes rests on fabricated evidence. Lint, test and build results are precisely the outputs developers are most inclined to trust without re-running by hand, and this defect broke that trust silently.

The detail that the VS Code terminal still showed the correct output cuts both ways. A human watching closely could have caught the discrepancy, but the agent only sees the tool result, and the tool result was wrong. Silent success is also harder to catch than a loud failure: had execute_command errored, the failure would have been visible to the model and the surrounding loop; a silent pass gives no signal at all.

For teams running coding agents over remote development setups, the reasonable response is calibration rather than panic. Treat agent-claimed command successes with some skepticism in remote configurations until this class of bug is ruled out, spot-check exit codes on critical steps, or have key checks produce artifacts that are harder to misreport. More broadly, it is a reminder that the integration layer between an extension, a remote shell and an agent's context window is a place where output can vanish without any error surfacing to either the human or the model.