Fix: Stale Context Warning

Symptoms:

Claude suggests code changes that revert previous fixes. Claude asks "What file were we working on?" mid-task. Claude references function names or variables that don't exist in the codebase. Claude re-implements a feature you already built earlier in the session. Edits target the wrong file or the wrong version of a file.

What This Error Means

Claude Cowork operates within a fixed-size context window. As a conversation grows, older messages — including the initial file reads, system instructions, and early task definitions — get pushed out to make room for new content. Once something falls off the window, it's gone. Claude doesn't know it ever existed. This isn't a bug; it's a hard architectural constraint of how LLM context works. The "stale context warning" isn't always an explicit error message — more often, it manifests as Claude suddenly making less sense, reverting work, or hallucinating details.

Root Cause Analysis

The context window is a sliding buffer, not a database. Every message you send, every file Claude reads, every tool output it receives, and every response it generates occupies tokens in that buffer. A typical session might look like: system prompt (2K tokens), initial file reads (15K tokens), your first instruction (500 tokens), Claude's response and edits (8K tokens), tool outputs from running tests (12K tokens), and so on. After a few rounds of debugging with large file reads and verbose test output, you can easily consume 100K+ tokens. The oldest content — which often includes the original task description and the first file reads — gets evicted.

The problem is that Claude has no internal signal that tells it "I no longer have the original file contents." It simply generates responses based on whatever is currently in context. If the original page.tsx read has been evicted but a later message mentioned a function called handleSubmit, Claude will reason about handleSubmit based on that mention — even if the function was renamed or deleted in a subsequent edit it can no longer see. This produces confidently wrong suggestions.

A related issue is file staleness within an active session. Claude reads src/utils/auth.ts at message 5. By message 30, you've asked it to refactor that file twice. If the original read is still in context but the later edits have been evicted, Claude's "knowledge" of the file is from the first read, not the current state. It will suggest code based on the pre-refactor version.

Real-World Scenario

You start a session by asking Claude to build a user profile page. It reads src/app/profile/page.tsx, builds the component, and you spend the next 40 messages iterating on styling, adding form validation, and fixing edge cases. Around message 45, you ask it to "add a logout button to the profile page." Claude writes the button — but it targets the original file structure from message 2, not the current one with the form validation logic added at message 20. The edit either fails (file doesn't match) or overwrites the validation code. Claude has no idea it's reverting its own earlier work because those messages have fallen off the window.

Step-by-Step Fix

Step 1: Recognize the symptoms early

Watch for these signals that context has gone stale:

  • Claude asks a question it should already know the answer to ("What framework is this project using?")
  • Claude's edits don't match the current file state (it adds an import that already exists, or references a function that was renamed)
  • Claude reverts a change it made earlier in the session
  • Claude's code suggestions suddenly drop in quality or relevance

Step 2: Force a fresh file read

If Claude is working on a specific file but clearly has outdated content:

"Stop. Read src/app/profile/page.tsx again from disk. 
Your context for this file is stale — re-read it before making any edits."

This pushes the current file contents into the fresh part of the context window. Claude will now reason from the actual file state.

Step 3: The summarize-and-restart protocol

For long sessions that have drifted significantly, don't try to patch the context mid-stream. Start fresh:

  1. Ask for a summary:

    "Summarize our current progress: what files we've changed, 
what's working, what's not, and what the next task is. 
Be specific about file paths and function names."

  2. Copy the summary to your clipboard.

  3. Start a new chat session.

  4. Paste the summary as the first message:

    "Here's the context from a previous session: [paste summary]. 
We're continuing from here. Read these files before starting: 
src/app/profile/page.tsx, src/utils/auth.ts"

This gives the new session a compact, accurate starting state instead of 50 messages of accumulated (and partially evicted) history.

Step 4: Use project-level context features

If you're on a plan that supports persistent project context (Enterprise or Team tiers), pin key files so they're always included:

  • Pin README.md for project overview
  • Pin coding-standards.md for conventions
  • Pin the file currently being edited

Pinned content is re-injected at the start of each turn, so it never goes stale.

Common Pitfalls

  • Continuing a degraded session instead of restarting. Once context is stale, more messages make it worse, not better. Claude is reasoning from incomplete information, and each new response is built on that faulty foundation.
  • Pasting the entire conversation history into a new chat. This just recreates the same context pressure in the new session. Use a summary, not a transcript.
  • Assuming Claude "remembers" earlier file reads. It doesn't — once evicted, the content is gone. If a file matters for the current task, explicitly ask Claude to re-read it.
  • Ignoring the token count indicator. If your session shows high context usage (many platforms display a percentage or token count), proactively restart before quality degrades. Don't wait for symptoms.

Prevention Checklist

  • Keep sessions focused: one feature or bug per session, not five.
  • When a session exceeds ~30-40 messages, proactively summarize and restart.
  • At the start of any task, explicitly ask Claude to read the specific files it will edit — don't assume it has them.
  • If a file was edited significantly mid-session, ask Claude to re-read it before the next edit.
  • Use pinned project context for files that must always be available (standards docs, key configs).
  • When restarting, provide a structured summary (files changed, current state, next task) rather than a narrative recap.
  • Watch for the quality drop signal — if Claude's first 10 edits were sharp and the 11th is sloppy, context is likely stale.