[FEATURE] de-duplicate file content system reminders across messages when file hasn't changed

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Summary
When Claude reads or modifies a file in a VSCode session, the extension injects the full file contents as a system reminder on every subsequent message for the rest of the session, even when the file hasn't changed again. This burns tokens proportional to session length rather than proportional to actual file changes.

Current behavior
Claude reads or edits foo.rs (200 lines)
On every subsequent message in the session, foo.rs full contents are injected as a system reminder (~500 tokens each)
In a 30-message session touching 5 files: ~75,000 tokens consumed by stale reminders
Expected behavior
File contents should be injected as a system reminder once per change event, not once per message. If the file hasn't changed since the last injection, don't re-inject it.

Suggested behavior
Track a content hash (or modification timestamp) per file
On each message, only re-inject files whose content has changed since the last injection
Alternatively: inject on change, then stop until the next change

Impact
This significantly degrades long coding sessions:

Each file touched accumulates a per-message token tax for the rest of the session
Sessions with many file interactions (e.g. multi-agent workflows, large refactors) hit context limits faster and cost more than necessary
The content is already in the conversation history — re-injecting identical content adds no information

Environment
macOS, Claude Code VSCode extension
Reproducible in any session where files are read/edited

Proposed Solution

Track a content hash (or modification timestamp) per file. On each message, only re-inject files whose content has changed since the last injection.

The simplest implementation: the extension maintains a Map<filePath, lastInjectedHash>. Before each message, for each tracked file, compute its current hash — only inject if hash differs from last injected. After injecting, update the stored hash.

This means a file gets injected once when first modified, then again only if it changes again — not on every message.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

Track a content hash (or modification timestamp) per file. On each message, only re-inject files whose content has changed since the last injection.

The simplest implementation: the extension maintains a Map<filePath, lastInjectedHash>. Before each message, for each tracked file, compute its current hash — only inject if hash differs from last injected. After injecting, update the stored hash.

This means a file gets injected once when first modified, then again only if it changes again — not on every message.

Additional Context

_No response_