Plan mode exists in Cline for exactly one reason: so the agent gathers information and proposes changes, but never touches disk until you explicitly flip it to Act mode. That guarantee has now failed three times, in three separate bug reports, over three months.
What happened
A Cline user running v4.1.7 with a self-hosted DeepSeek model via LiteLLM filed GitHub issue #13140: while still in Plan mode, Cline called write_to_file and replace_in_file directly and modified files on disk. No approval prompt. No switch to Act mode. The reporter traced it to the v4.0.0 SDK migration, which reworked how Plan/Act mode is handled through new SDK coordinators.
Not the first report
This is the third documented instance of the same boundary failing:
- #10497 (2026-05-01) — the original report, with a clean reproduction: a planning prompt after which the model auto-switched to Act mode and began implementing without confirmation. The issue thread quotes Cline's own prior refusal message back at itself: "You must manually toggle to Act Mode using the Plan/Act toggle button below. I do not have the ability to switch modes myself."
- #12907 (2026-08-04) — closed as a duplicate of #10497.
- #13140 (2026-08-10) — this incident. Still open, no maintainer response as of publication.
Three independent users hit the same failure across three months, and the tool's own error message describes a guarantee it doesn't actually enforce.
Why it matters even without data loss
No damage was reported in any of the three threads — no deleted files, no corrupted state. That's arguably what makes this worth flagging rather than what excuses it: Plan mode is the thing a cautious user reaches for specifically to avoid an agent making unreviewed changes to a real codebase. If the gate silently doesn't hold, the user's mental model of what's safe is wrong, and they won't find out until something is edited that they didn't approve.
Disposition
Filed 2026-08-10 against v4.1.7. Two prior reports of the same defect exist going back to 2026-05-01. As of this writeup, #13140 is open with no maintainer response.
Full incident record, severity scoring, and sourcing: STUPID-2026-0077
This is one of 77+ verified, severity-scored AI agent incidents documented at StupidLLM, an open incident database for AI coding agent failures.
Top comments (0)