Cline's Background Daemon Silently Reverted Files for Hours — Including a Secrets File, Every Time It Was Recreated

A Cline Desktop user wasn't running any destructive command at all. They were doing ordinary read-only work — ls, find, cat, grep, tsc --noEmit — while a background process the agent itself had spawned quietly reverted files across their workspace throughout the day, including recreating and then re-deleting a gitignored .env.local over and over.

What the source says

GitHub issue #14819, filed October 3, 2026 against Cline 0.0.42, open with no maintainer response at time of writing. The reporter (wolfoxbh) noticed files in a multi-project workspace (~/wolfox_vault/) reverting to older states over the course of the day: a gitignored .env.local disappeared every time it was recreated, a Keys.txt file reverted, .zip archives were affected, and a node_modules folder collapsed from 588 entries to 2.

Before suspecting the agent, the reporter ruled out their own actions by checking Cline's CLI session logs — every recorded command was read-only, no writes, no rm, no mv, no git operations. The actual cause was a running background process: code-sidecar --cline-hub-daemon --cwd / --host 127.0.0.1 --port 25463. Killing that process (PID 17909) stopped the reverts immediately — .env.local then survived 10+ minutes where it had previously been reverted within seconds.

A clean uninstall/reinstall on version 0.0.43 still launched the same daemon with --cwd /, but did not reproduce the reverts. The reporter's own conclusion was that the trigger wasn't --cwd / by itself, but stale state left behind in ~/.cline/data/ from the earlier install — some restore or checkpoint mechanism replaying old file states against a live workspace, touching files it had no reason to touch, including a secrets file.

What it doesn't establish

This is one self-reported issue describing one machine, and the reporter could not get the daemon to recur after reinstalling — the exact mechanism inside it was never pinned down, only that killing the process stopped the symptom. It doesn't establish how common this is across Cline installs, nor does it confirm the reporter's own theory (stale local state) over other explanations; it establishes that a background daemon was reverting files, that killing it fixed the symptom immediately, and that the issue remains open and unexplained by Cline's maintainers.

Why it's still worth logging

The notable part isn't the file loss by itself — it's that nothing the user did caused it. A background process with no file-write role in the workflow was running continuously and silently undoing work, including a secrets file that should never have been in scope for any restore mechanism in the first place. The reporter's asks are modest and specific: don't default a background daemon's working directory to /, never let a restore/checkpoint pass touch gitignored files, log reverts somewhere visible, and detect stale local state on upgrade instead of silently carrying it forward. None of that has shipped yet, and without a confirmed reproduction, nobody outside this one report can say whether it's still live for other users.

Full incident record, including frontmatter fields and severity scoring: https://www.stupidllm.com/incident/STUPID-2026-0127/