Why does Cline forget my task history?

Cline forgets your task history because each task is an isolated conversation pinned to your current VS Code workspace, with no automatic carry-over of decisions, file edits, or reasoning into the next task. The task list stores titles and transcripts, not a structured project log. The fix is to give Cline a persistent project memory it reads on every new task through native MCP support.

Cline is a VS Code coding agent that scopes itself to the active workspace and works one task at a time. Three design choices push your history out of the model's working memory:

1. Tasks are stateless toward each other. New Task opens a clean conversation. The previous task's plan, file reads, command outputs, and decisions are not loaded — they exist as historical transcripts you can scroll through, but the agent does not consult them automatically.

2. The task list is a transcript log, not a structured history. Cline stores each task's chat for you to revisit. There is no queryable index of "what did we change in src/auth/", "which tests started failing", or "which API approach did we reject". You get the prose back, not the facts.

3. Workspace is the unit of state. Switch VS Code workspaces — a teammate's clone, a new machine, a fresh checkout — and the task list does not follow. Cline's open-source extension and its session model are documented at github.com/cline/cline.

The result: Cline is sharp during a task and amnesic between them.

Every new task pays a re-discovery tax, and the cost compounds across a project:

• Repeated exploration. Cline opens the README, walks the source tree, and rebuilds a mental map you already paid for in the previous task. Every minute is tokens you spend twice.
• Lost decisions. "We tried Redis caching and rolled it back because of session affinity" is reasoning trapped in a closed task. The new task happily proposes Redis again.
• Broken handoffs. A teammate cloning the repo, or you on a new laptop, starts with no task history at all. The previous week of progress is invisible to the agent.

The fix is not "scroll through old task transcripts before each session" — it is to extract task history into project memory the agent reads automatically.

Cline ships three features that help with continuity. None replaces a real project memory.

Task list and resume lets you reopen a previous task's chat. Useful when you remember exactly which task contained the decision you want. Useless across machines, teammates, or weeks of history when titles blur together.

Checkpoints snapshot the workspace state at moments during a task so you can roll back. Excellent inside a task and irrelevant between tasks — checkpoints are workspace state, not memory.

Memory Bank (community pattern) keeps a memory-bank/ folder with files like activeContext.md and progress.md that you update manually. It is the closest thing to a project log Cline natively supports, and it is only as fresh as the last time you remembered to write to it.

The deeper issue is that task history is project history. You probably run Cline on more than one machine, alongside Cursor or Claude Code, and possibly with teammates. Task lists do not sync, Memory Bank only travels in git if someone commits it, and none of these record the reasoning behind a change automatically.

Project history needs to live above the editor, or it drifts the moment you switch context.

MemoryLake is a cross-model memory layer Cline reads from on every new task. Instead of relying on scrollable transcripts and a hand-edited Memory Bank, you give the project its own log and let every task open with the relevant history already retrieved.

• Structured task and decision log. Every closed task can be summarized into Memories — files touched, decisions made, dead ends ruled out. The agent retrieves the relevant slice per new task instead of re-exploring.
• Same history across machines and teammates. Open Cline on a new laptop or in a teammate's clone and the project's task history is there. No memory-bank/ syncing, no manual catch-up.
• 10,000× the retrieval reach of raw prompting. MemoryLake's engine reads from billions of tokens of project memory and feeds Cline only the relevant prior work per turn, so you stop blowing the context window on transcripts.

MemoryLake scored 94.03% on the LoCoMo long-context benchmark, the top published result as of 2026, with millisecond retrieval and AES-256 end-to-end encryption.

1. Create a project and load your context. Sign in to MemoryLake, open Project Management, click Create Project, and name it "Cline — Acme dashboard". Upload your memory-bank/ markdown, prior task summaries, ADRs, and runbooks into the Document Drive. Add structured "what changed and why" notes through the Memories tab so they travel with the project.
2. Generate an MCP Server endpoint. Open the MCP Servers tab inside your project, click Add MCP Server, name it "Cline task memory", and click Generate. MemoryLake returns an API key ID, secret, and endpoint URL. Copy the Bearer token immediately — it is shown only once.
3. Connect Cline through VS Code MCP settings. Open Cline's MCP Servers panel in VS Code, click Add Server, paste the MemoryLake endpoint URL, and add the Bearer token in the auth header. Save and reload the window. Every new task now opens with prior task summaries, decisions, and file context already retrieved.