Why does Bolt.new forget my project context?

Bolt.new forgets your project context because it stuffs your whole codebase, chat history, and system prompt into a single 200K-token Claude window, and once a project grows past roughly 15–20 components the oldest context gets evicted first. The fix is to keep a persistent project memory outside Bolt that survives any single chat.

Bolt.new runs every project inside a WebContainer and feeds the entire visible file tree, your message history, and its own system prompts into Claude on every turn. Three constraints make forgetting inevitable:

1. The 200K token ceiling. Anthropic's Claude model behind Bolt has a 200K-token context window. Bolt has its own internal cap reported by users at around 500K tokens before the chat freezes. Your project files plus chat history both compete for that space. A medium SaaS frontend can fill it on day one.

2. The whole tree is in the prompt by default. Bolt reads every file in your project on each turn unless you explicitly add it to .bolt/ignore. As components, hooks, and configuration files accumulate, the share of the window left for new instructions shrinks until Bolt starts ignoring or paraphrasing earlier requirements.

3. Chat history is part of the same budget. Bolt's "memory" of what you said yesterday lives in the rolling conversation. Once the window overflows, the oldest turns get truncated. Decisions, constraints, and "do not touch this file" rules disappear silently.

The result: Bolt knows your codebase right now, but it does not remember the project around it.

Every time Bolt drops context, you pay for it twice — once in tokens, once in cleanup.

• Rewritten work. Bolt regenerates a component it built last week because it no longer sees the original intent, leaving you to diff and merge.
• Lost requirements. "Use Supabase for auth, never Firebase" gets evicted, and Bolt happily wires up Firebase on the next prompt.
• Broken cross-file logic. When a referenced file falls out of context, Bolt invents a stub and your routes 404.

These are not edge cases. The Bolt GitHub issue tracker has multi-hundred-comment threads about "prompt is too long: 200001 tokens > 200000 maximum" errors that wipe sessions mid-build.

StackBlitz has shipped three mitigations. They help, but none of them give you real project memory.

The `.bolt/ignore` file. Modeled on .gitignore, it tells Bolt which folders and files to exclude from the prompt. It buys you headroom but also blinds Bolt to anything you exclude — touch a route that imports an ignored helper and Bolt will rebuild it from guesswork.

Chat targeting. You can scope a request to a single file or folder by mentioning it directly. This narrows the working set for one turn but does not persist constraints across turns.

StackBlitz cloud backups. Your project syncs to StackBlitz, so the code survives even when the chat does not. The code is not the problem. The reasoning, the rules, and the decisions that produced the code are what get lost.

For deeper guidance, the Bolt team documents these levers in the official Bolt help center.

For a 5-screen prototype, the natives are fine. For a real product, they are not.

The deeper issue is that Bolt's memory cannot leave Bolt. The moment you move a screen to v0 for a design polish, hand backend work to Cursor, or ask Claude to review the architecture, the context vanishes. Every new tool starts blank, and you become the only persistent memory in the loop — pasting the same paragraph of constraints into three different chats.

This is the gap a cross-tool memory layer fills: one project memory that every AI in your stack can read from, so Bolt is one chair at the table, not the whole table.

MemoryLake stores your project's intent — the files, decisions, naming patterns, and rules — outside Bolt's chat window. Bolt reads from MemoryLake at the start of each session, and so does every other tool you switch to.

• Project memory that outlives the chat. Specs, design notes, ADRs, and prior conversations live in a MemoryLake Project. When you open a new Bolt chat, you paste a short context summary pulled from MemoryLake and Bolt starts the day already aligned with the project, not 200K tokens of raw files.
• 10,000× more context than raw prompting. MemoryLake's retrieval engine reads from billions of tokens of project memory and returns only what is relevant per turn. You stop trying to cram an entire app into a 200K window.
• Portable across the vibe-coding stack. The same project memory works in v0, Lovable, Replit Agent, Cursor, and Claude. Jump from Bolt to v0 for a UI pass and the project comes with you.

MemoryLake scored 94.03% on the LoCoMo long-context benchmark, 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 something like "Bolt — landing page rebuild". Upload your spec, brand guidelines, component inventory, and any past Bolt chat transcripts through the Document Drive. Add hard rules ("never use Firebase auth", "Tailwind only, no styled-components") as entries in the Memories tab.
2. Generate an MCP Server endpoint. Open the MCP Servers tab inside your project, click Add MCP Server, name it "Bolt integration", and click Generate. MemoryLake returns an API key ID, secret, and endpoint URL. Copy the secret immediately — it is shown only once.
3. Connect Bolt.new. Bolt does not yet speak MCP natively, so call the MemoryLake REST API with your Bearer token to fetch a compact project summary, then paste that summary into Bolt's chat at the start of a new session. Developers can wire the Python SDK into a pre-prompt hook so every new Bolt project opens with the same source of truth.