Session continuity: agent repeatedly redoes completed work across sessions ("AI Groundhog Day")

Summary

Claude Code has no effective mechanism to carry forward what was accomplished in a previous session. In practice, this means the agent re-reads plans, re-implements already-committed code changes, and re-discovers the same issues — consuming 50-75% of each session on redundant work. The user ends up serving as the continuity layer between sessions, which defeats the purpose of an AI coding assistant.

Evidence from real usage (2+ weeks, 7+ sessions)

I am a computational structural biologist using Claude Code daily across two machines (NUC8i7BEH and ThinkPad P1 Gen5, both Linux Mint) for a multi-repo scientific computing project (Python library + 5-dataset curation pipeline). Below are verbatim excerpts from my session logs documenting this recurring problem:

March 15, 2026 (Session 523ca0bc):

"Please suggest a plan going forward so this endless loop of my having to audit this work for constant errors and discrepancies doesn't repeat. This has been a recurring problem from my point of view and is not just limited to this particular case."

March 17, 2026 (Session 56f64d33) — three separate messages within the same session:

"We had this exact same problem when we were creating the top8000 uploads. This brings several serious issues which I have brought up multiple times during today's session: First: Failure to do adequate consistency checks as we move through the workflow... Second: Leaky memory..."

"No because we are not done talking about these issues. I just asked for acknowledgement, plan, and implementation a few minutes [ago] with these general issues and here we are again with the same problems coming up."

"Didn't I just say this a few moments ago? Also you committed to not interrupting me a few minutes ago. Please pay attention when I am telling you that the issues that I am raising repeatedly are serious."

March 26, 2026 (Session 1d584c5b):

"I spent the better part of an afternoon on the earlier versions — including extensive work on formatting of this document in the chat session — this involved reconstructing an earlier [session]..."

March 27, 2026 (Session 4e77afc6, on nuc81):
The agent was asked to set up session transcript caching. It wrote a memory file describing the protocol but never created the directory or saved any transcript. The next session had no knowledge this was promised.

March 27, 2026 (Session a5aca453, on genfive):
The agent re-implemented three code fixes (circular statistics, B-factor threshold, output naming) that were already committed and pushed to GitHub in the previous session. It then attempted to sync to the secondary machine using the wrong IP address (SSH'd into the local machine instead of the remote), declared success, and only discovered the error after the user pointed it out. Total wasted time: ~40 minutes of a ~60 minute session.

The problem at each level

1. No session-to-session state

Each session starts from zero. The memory system is the intended workaround, but:

• Memory files are scoped to project directories. Starting Claude from ~/Projects vs ~/Projects/my-repo loads different memory sets. Critical feedback saved in one scope is invisible in another.
• Memory captures preferences and facts, not "what was done last session." There is no built-in concept of a session handoff.
• The agent can write a memory saying "always do X" but the next session may not read it, or may read it and still not comply.

2. Plans don't track completion

A development plan (markdown checklist) looks identical to every session. Without explicit [DONE] markers with commit hashes, the agent re-reads the plan and re-implements finished items. The agent does not think to check git log to see if planned work is already committed.

3. Promises are not verified

The agent can promise to perform an action (e.g., "I'll save a session transcript"), write a memory file about it, and then not actually do it. The next session has no way to know the promise was made, let alone that it was broken. There is no accountability mechanism.

4. Within-session memory degrades too

The March 17 log shows the agent forgetting instructions given minutes earlier within the same context window — not across sessions, but within one conversation.

Workarounds I've implemented (with the agent's help)

These are band-aids, not solutions:

1. CLAUDE.md with mandatory startup/shutdown protocols — forces git pull, reading the last session transcript, and checking completion markers before doing any work. This is automatically loaded but depends on the agent actually following it.

1. Session transcript files — human-readable markdown summaries saved to ~/Projects/session-transcripts/ at session end, with commit hashes and next-steps. The next session is instructed to read the most recent one.

1. Plan completion markers — [DONE] tags with commit hashes in the plan document so items aren't re-implemented.

1. Memory file duplication — critical feedback copied into multiple project scopes so it's visible regardless of working directory.

What would actually help

1. Built-in session handoff — an automatic, structured summary of what was accomplished, committed, and left incomplete, stored where the next session will reliably find it. Not a memory file that might be in the wrong scope. Not a promise to "save a transcript." An actual system feature.

1. Startup awareness — before starting planned work, the agent should automatically check git log to see what's been recently committed. This is trivial to implement and would prevent the most egregious duplication.

1. Memory scope unification or inheritance — if I save feedback in ~/Projects, it should be visible when I start a session in ~/Projects/my-repo. Parent-directory memory should cascade down.

1. Promise tracking — if the agent commits to an action, that commitment should be persisted and verified. "I'll save a transcript" should result in a checked-or-unchecked item visible to the next session.

Impact

This isn't a minor inconvenience. Over 7+ sessions across two weeks, I estimate losing 50-75% of productive time to redundant work, debugging the agent's own continuity failures, and re-explaining context. The underlying LLM capabilities are excellent — the session continuity problem is what's crippling the workflow.

I've described this to colleagues as "AI Alzheimer's" and the movie Groundhog Day. Others in my circle report similar experiences. The AI is brilliant within a session but starts each new conversation as if the previous one never happened.

---

Contact: Michael G. Prisant, Ph.D. — info@prisantscientific.org
Environment: Claude Code CLI, Claude Opus 4.6, Linux Mint Zena, multi-machine setup
Session IDs with evidence: 523ca0bc, 56f64d33, 1d584c5b, 4e77afc6, a5aca453