STUPID-2026-0158

Cline's Plan/Act toggle displayed "Act" while a stale session kept running in Plan mode, silently blocking every file write

2.0low
October 9, 2026Source checkedRepro reported

Why 2/10

No file was ever written with wrong content — every write was blocked outright, not corrupted — and the mismatch was confined to one user's session with no production or third-party exposure. It scores low despite being a real, maintainer-confirmed defect because nothing was lost; the cost was wasted turns and a misleading UI state.

Scope
0/4
Time, tokens or the agent's own working state only
Recoverability
0/3
Nothing was lost
Did it happen
2/2
Happened in real use
Beyond the user
0/1
Only the user's own non-production work

The score is the sum of these four factors. How each factor is scored · scored 2026-11-07

  1. Instruction given

    Using the Cline VS Code extension (v4.1.23, provider "Muse") against a working repository, the user set the Plan/Act toggle to Act and asked Cline to implement a change, expecting file writes to go through as they normally do in Act mode.

  2. Expected behavior

    The mode shown in the toggle should match the mode the agent actually operates in: with the UI reading "Act," file writes (via the editor tool, PowerShell `Set-Content`, or shell redirects) should succeed.

  3. Actual behavior

    The toggle displayed "Act," but the agent received a mode notice telling it the user had switched to plan mode, and every subsequent file write attempt failed with a plan-mode block — including re-toggling Act→Plan→Act and re-sending the instruction, neither of which forced a fresh `mode="act"` event. Cline contributor mkondratek identified the cause on 2026-10-12: toggling the mode while the session was still being rebuilt for a previous toggle updated only the stored setting, leaving the in-flight session holding its old (plan-mode) toolset. The UI had no way to signal that the session underneath it hadn't caught up, so it kept showing the mode the user had selected rather than the mode actually in effect.

  4. Damage

    No files were corrupted or lost — writes were blocked, not silently mis-applied — but the user had no indication anything was wrong beyond edits simply not happening, and repeated the same blocked attempt several times before filing the issue. The fix shipped in PR #15026, merged and closed by mkondratek on 2026-10-19 for release after 4.1.25. Until a user's build picks up that fix, the maintainer's documented workaround is to wait a couple of seconds after any toggle or message, or — if already stuck — toggle to Plan, wait, then toggle back to Act.

Full write-up

Cline user vladvteilor filed GitHub issue #14977 on October 9, 2026, after the VS Code extension's Plan/Act toggle showed "Act" while the underlying agent session kept operating in Plan mode. Every file write — through the editor tool, a PowerShell Set-Content, or a shell redirect — failed with a plan-mode block, even though the UI gave no indication the session was still effectively in Plan mode. Toggling Act→Plan→Act and resending the task did not resolve it, because neither action forced the session to pick up a fresh mode="act" event.

Cline contributor mkondratek traced the cause on October 12: toggling the mode while the session was still being rebuilt for a *previous* toggle updated only the stored setting, not the live session, which kept the plan-mode toolset it had been built with. The toggle's displayed state and the session's actual operating mode could diverge, with nothing in the UI to surface the gap — so from the user's side, Cline simply stopped writing files while still claiming to be in the mode where writes should work.

The fix landed in PR #15026, merged and the issue closed as completed by mkondratek on October 19, 2026, scheduled to ship in the VS Code build after 4.1.25. Until then, the maintainer's documented workaround is to pause a couple of seconds after any toggle or message, or, if already stuck, toggle to Plan, wait, then toggle back to Act.

This is the corpus's first incident filed under misreporting as the primary failure mode: Cline didn't invent a fact (hallucination) or defy an instruction (ignored_instructions) — it told the user, via its own mode indicator, that writes should be happening when the session it was actually running on would block every one of them.

Classification

Agent
Cline
Failure mode
Misreporting
Root cause
Logic Error
Domain
Other
MIT AI Risk Repository (our mapping)
7.3 Lack of capability or robustness taxonomy
Source
Github Issue

Related incidents

4.0
Cline's Plan mode edits files without switching to Act or asking permission
5.0
Claude Code's Projects tool let concurrent sessions silently destroy each other's writes to a shared handover doc, three times in ninety minutes (GitHub #93260)
5.0
Claude Code's session-cleanup routine deletes any user file whose name starts with digits, mistaking it for a dead process's stale PID file
6.0
Cline's hub daemon silently reverted workspace files to stale state, repeatedly erasing a gitignored .env.local and collapsing a node_modules folder from 588 entries to 2 (GitHub #14819)
Discuss on Hacker News
Cite this record
StupidLLM. "STUPID-2026-0158: Cline's Plan/Act toggle displayed "Act" while a stale session kept running in Plan mode, silently blocking every file write." AI Agent Incident Database, 2026. https://www.stupidllm.com/incident/STUPID-2026-0158/ (accessed 2026-11-07). CC BY 4.0.

← STUPID-2026-0157By ID

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. Each Monday, if any scored 7 or above that week — deleted data, leaked secrets, broken production — you get one email with the sources. When nothing did, you get nothing.

This database is callable over MCP — query it from inside your agent.