I checked what 6 AI coding tools write to disk to stop the agent forgetting its plan. Half write nothing.

A developer investigated why AI coding tools forget their plans and found that the issue is often a filesystem problem, not a context-window limitation. The developer's own tool suffered because the plan was never saved to disk, and a review of six popular tools showed that those that don't persist plans (Cursor and bolt.new) have the most complaints about forgetting. The developer recommends persisting plans and archiving them on completion, and warns that prompting a model to maintain a file is unreliable.

Every AI coding tool has the same top complaint: "it forgot what we were doing." I spent weeks assuming that was a context-window problem. It mostly isn't. It's a filesystem problem — and you can predict which tools suffer from it by asking one question: where does the plan get written down? Our own builder had it badly. You'd say "build me a CRM," the agent would plan it, start building, hit its step limit, stop. You'd type "continue" — and it would either start over from a different angle or silently drop half the plan. The cause was mundane and a little humbling. The plan was never saved anywhere. It was a local variable inside one function, parsed out of the model's own output text, used for step tracking during that single turn, then discarded: js // inside one turn, then gone const activePlan = parsePlanFromModelOutput text ; A savePlan function existed. Nothing in the codebase ever read a plan back. The UI reset the plan to null on every new message. So "continue" was always a cold start — the agent had no record that a plan had ever existed. Then it got worse. We had a completePlan that fired whenever the agent hit its max iteration limit — i.e. in the exact moment before a user types "continue" — and it marked every pending step skipped . We were actively erasing the roadmap at the worst possible moment. And one more: the plan object was only ever built on one model provider's code path. Route the session through a different provider and there was no plan at all. The bug was load-bearing on which model you happened to be using. So I went and read the docs, changelogs and forum threads for the tools people actually use. This is from public documentation and user reports — I can't read their source. | Tool | Durable plan? | Always-injected memory | |---|---|---| Claude Code | Yes — plan files under ~/.claude/plans/ , survive compaction | CLAUDE.md , re-read from disk after every compaction | Lovable | Yes — .lovable/plan.md + an archive dir, inspectable and diffable | AGENTS.md + knowledge layers injected every message | Replit Agent | Yes — .local/session plan.md + a native task board | replit.md , persists across sessions | Devin | Yes — structured JSON plan, editable, survives crashes | scoped memory layers + playbooks | Cursor | No first-class plan; the community maintains a TODO.md by hand | .cursor/rules/ .mdc | bolt.new | No — Plan Mode keeps the plan in the chat | agents.md + Project Knowledge | The two that write nothing to disk are the two with the loudest "it forgets" threads. Cursor's forum has the "completely forgets it's trying to solve a problem" thread; bolt's own documentation concedes that after many prompts the AI loses track of earlier decisions and contradicts its own code. That correlation isn't proof of causation. But it's a strong hint that this is an engineering decision, not a model-intelligence ceiling. If you're building something similar, persistence alone isn't the finish line. Both of these are real and documented: session plan.md isn't cleared between sessions, so the agent abandons what you just asked for to go finish an old plan. A plan that survives forever is its own bug.So: persist the plan, and archive it on completion . The plan now lives as plan.json plus a human-readable PLAN.md on the workspace's persistent volume. It's written through on every step transition, re-read at the start of every turn, and archived when complete. If the agent stops early, pending steps persist untouched instead of being wiped. We added a provider-parity test so the plan can't silently exist on only one code path again. This is the part I'd actually tell other people building agents: You cannot ask a model to maintain a file by putting it in the prompt. We told our agent to keep a NOTES.md of its decisions. It never created it. Not once. I only found out by inspecting the container. It also kept referring to a "bug log" it claimed to have been writing. There was no such file anywhere in the codebase — I grepped. It had hallucinated its own persistence layer, and it described it confidently. The moment we made it a tool the agent has to call , it worked — because a tool call shows up in the trajectory and is verifiable. A prompt instruction is a suggestion; a tool call is evidence. Enforce it in code. Don't ask the model nicely. Stop tuning your prompt and go ask where the plan is written to disk. If the answer is "nowhere," you've found your bug. It's a persistence problem wearing a memory problem's clothes. I build NoCoder https://nocoder.codes/?utm source=devto&utm medium=article&utm campaign=plan-persistence , an AI app builder where you review every change as a diff before it applies. It's a beta. If you want to try to break it, I'd genuinely value that more than a compliment. Curious what the folks here have hit — has anyone found a tool that handles long-running plan state well?