Stale context injection after file edits causes repeated mismatch warnings and noisy sessions

[Xopher00]

Summary

When Claude edits or writes a file during a session, later proactive context injections may still contain an outdated version of that same file/content. This results in Claude repeatedly noticing that the injected context does not match the current on-disk file state.

Over medium-to-long sessions this creates significant noise, repeated self-corrections, and degraded context quality.

---

Observed Behavior

Typical flow:

1. Claude reads a file
2. Claude edits/writes the file
3. The plugin later injects cached/retrieved context related to that file
4. The injected content still reflects the older version
5. Claude notices the mismatch and comments on it repeatedly

Examples of symptoms:

• Claude states that “the file contents appear outdated”
• Claude mentions that injected context does not match current file state
• Claude repeatedly re-reads files to verify correctness
• Additional context becomes noisy with stale snippets
• Sessions accumulate increasing amounts of “cache mismatch” chatter

This becomes especially noticeable in refactor-heavy workflows where the same files are repeatedly modified.

---

Expected Behavior

After a file is edited or written:

• Any cached/contextual representation of that file should be invalidated or refreshed
• Future proactive context injections should reflect the current file contents
• Claude should not receive stale snapshots of files it has already modified during the same session

---

Likely Cause

The issue does not appear to be simple in-process memoization of search results.

Based on the current architecture, the more likely problem is:

• Reflexio indexing/extraction is asynchronous

• Session updates are published with:

  • force_extraction=False
  • skip_aggregation=True

• Retrieval happens before the updated file state has propagated into the searchable/indexed representation

As a result, retrieval can continue returning older indexed content even after the file has been modified locally.

Potentially relevant paths:

• events/stop.py
• events/session_end.py
• context_inject.py
• publish.py

---

Suggested Improvements

Possible mitigation strategies:

1. Invalidate/update file-related context after writes

When Edit, Write, or NotebookEdit succeeds:

• invalidate cached snippets associated with that file
• or immediately refresh local/session context state

2. Prefer live filesystem state over indexed snippets

If a retrieved snippet references a file currently present in the workspace:

• re-read the current file contents
• or verify modification timestamps before injection

3. Force extraction for recent edits

For recent write/edit operations:

force_extraction=True
skip_aggregation=False

at least periodically or for modified-file contexts.

4. Add recency/version metadata to injected context

Including timestamps or file hashes would help Claude reason about freshness and suppress repeated mismatch commentary.

---

Impact

This issue significantly affects long-running coding/refactor sessions because:

• Claude becomes distracted by stale context mismatches
• token usage increases due to repeated verification/re-reading
• proactive expansion quality degrades over time
• injected context becomes less trustworthy

The feature is otherwise extremely useful, but stale file injections reduce reliability during active development workflows.