[BUG] Complaint: Claude Code does not retain project decisions across sessions, despite keeping the same session link open

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Submitted by: Dr James A Robertson (The ERP Doctor)
Product: Claude Code (cloud/web session)
Session affected: https://claude.ai/code/session_01SPRPzZxaFq1ReiurnaMtzE
Date of this incident: 2026-10-14
Repository: drjamesarobertson-design/taxonomy_builder
Summary
I have deliberately kept one single Claude Code session open across many days of work specifically to maintain continuity on this project. Despite that, Claude had no knowledge of substantial, already-completed work from earlier in the same project’s history — including a full SMTP email provider setup (Resend, integrated with Supabase, DNS-verified, tested and confirmed working by me directly) — and actively told me this still needed to be set up from scratch. I lost real time acting on that incorrect instruction before catching the error myself.
What happened

1. I reported that a new user sign-up was not receiving its confirmation email.
2. Claude’s response assumed no custom email provider had ever been configured, and told me Supabase’s default mailer was "for testing only" and that I would need to set up a provider such as Resend from scratch.
3. This was wrong. Resend had already been fully configured as Supabase’s custom SMTP provider — the domain had been DNS-verified, the integration had been wired up, and I had personally tested and confirmed it was working, weeks earlier, in this same ongoing project.
4. When I challenged this ("we set up the Taxonomy Builder notification email with my own email address about two weeks ago, how come you do not remember that?"), I had to supply Claude with my own complete manual record of the conversation — an 8,800-paragraph Word document I had kept myself — before it could recover the correct information.
5. Claude confirmed, after reviewing that document, that the setup had genuinely already been completed, and that this information had simply never been written into the project’s own persistent documentation file (MASTER_BRIEFING.md), which is the one place later sessions are supposed to be able to read it back from.

Why this matters
• I was given no warning, at any point before this, that "the same session link" does not mean "the same memory." I had structured how I work with this product specifically around the (reasonable, in my view) assumption that it would.
• The actual persistence mechanism — a project file that has to be manually and reliably kept up to date by Claude itself, every time, without being asked — is fragile and depends entirely on Claude’s own discipline in a given session. It failed here with no indication to me, at the time, that it had failed.
• I only recovered the correct information because I happen to keep my own manual backup of the entire conversation. A user without that habit would have no way to correct Claude’s mistaken belief, and no way to know the belief was mistaken in the first place.
• This is not a trivial inconvenience. I am running a real commercial software project through this tool. Confidently wrong answers about already-completed infrastructure work cost real time and could, in a different instance, cause real damage (e.g. being told a security measure or a payment integration isn’t in place when it already is, and "fixing" something that didn’t need it).
What I would like addressed

1. Clear, prominent, upfront disclosure — at the point a session is created or reused across days, not buried in documentation — of what actually does and does not persist between working sessions, so users don’t have to discover the limitation the way I did.
2. A more reliable mechanism for project continuity than "Claude remembers to write it down," for users doing exactly what I was doing: long-running, multi-session, real-world project work.
3. Acknowledgement that "keeping the same session URL open" is a reasonable thing for a user to believe preserves continuity, and that the product should either make that true, or make very clear that it isn’t.
4. Fundamentally you need to decide whether Claude Code is a serious production tool for commercial software or a toy for amateurs who create useless small items

The full supporting record (the conversation transcript referenced above) is attached

Claude Taxonomy Builder Spec v 1.23.docx

What Should Happen?

Claude should provide robust continuity of ALL information relating to a project

Error Messages/Logs

Steps to Reproduce

Run the same session over multiple days and you will discover that Claude Code does NOT remember what it did yesterday unless it has been prompted to record what it did at the end of the previous session

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Sonnet 5

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This is serious, up to this morning I was seeing Claude Code as a serious development tool for serious software development, I now am doubting this and seriously wondering if the many hours of work over the last six weeks have been wasted