[BUG] Project knowledge index serves stale file state after update/delete/re-upload, and diverges from the interface file list

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?

In a RAG-enabled Claude.ai Project, the content the assistant reads from project knowledge lags the actual file state shown in the Project interface, and the two stay diverged across turns and across a session. Note: this is a Claude.ai Projects / project-knowledge issue, not Claude Code — this tracker is the only public Anthropic issue queue and the related reports (#10841, #51501) live here, so it is filed here.

Three symptoms, all pointing at the retrieval index rather than the file store:

1. Deletions not reflected — a file removed in the interface still appears in the assistant's view of project knowledge for a period afterward.
2. Updates not reflected / stale content served — after replacing a document, the assistant keeps returning the old version's content. Matches #10841, including that a new chat did not reliably clear it and the cache appears keyed on indexed content, not filename.
3. Interface and retrieval disagree, with no signal of which is current — from inside the execution environment, a present file and a deleted-but-not-yet-de-indexed file are indistinguishable in a directory listing. Only a screenshot of the Project Context panel resolved which state was true.

What Should Happen?

After a file is added, removed, or replaced in a Project, the retrieval index and the assistant's view should reflect the change within a short, bounded, ideally stated interval — or the interface should expose an "indexing" state the assistant can also read, so stale reads are attributable rather than silent.

Error Messages/Logs

Steps to Reproduce

1. In a Project with RAG active (the "Search mode" indicator is showing), note the file list in the interface.
2. Delete one file and replace another with a modified version.
3. In the same or a new chat, ask the assistant to list the project files and summarize the modified one.
4. Observe: the assistant's file listing and/or content reflects the pre-change state, while the interface shows the post-change state.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A — Claude.ai Projects (web), not Claude Code

Platform

Other

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is a Claude.ai Projects issue, not Claude Code. Several required fields above (Claude Code Version, Platform, Terminal, regression) have no applicable option; answers given are the least-wrong available and are flagged here as not applicable rather than accurate.

Related issues: #10841 (persistent caching after delete/re-upload), #51501 (files stuck in "Indexing"), #25983 (no way to sync/list project-knowledge files). This report is broader than any single one and adds two dimensions they don't cover:

• Format-forced external storage: some legitimate source files can't be uploaded to project knowledge at all (SVG is rejected as unsupported), forcing the source outside the Project while a derived PDF sits inside it. This compounds the staleness problem, because the one file whose source isn't in project knowledge is also the one hardest to cross-check when the index lags.

• Skills lag with worse consequences: when a skill (a procedure the assistant runs) is added or updated via the Project, the environment may not see it or sees an old version — the assistant has been observed reporting a skill as unavailable when present, or running an outdated procedure. Pasting the skill file into chat doesn't fix this (readable as content, not wired in as executable), so it changes how work is done, not just what is read. Compare #29746.

Only reliable in-product workaround: upload the file directly into the chat, which bypasses both the container snapshot and the retrieval index — but fixes only that one conversation, not the Project, and doesn't work for skills.

Suggested remedies, in order: (1) expose a readable per-file indexing state both interface and assistant can see; (2) a manual "re-index project" control that confirms completion; (3) document update/delete propagation behaviour and its interval in the RAG-for-Projects help article, which currently covers only capacity and retrieval; (4) bound the propagation interval and state it.