[BUG] Project file delivery failure with clean type split: all text files (.md/.docx) missing from container while all binary files present — file list still announces everything

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 claude.ai Projects session, the file list announced at conversation start promised the full project knowledge base (~130 files at the time). The actual container (/mnt/project/) contained only 81 files — every single one of them binary (jpg, png, pdf, xlsx). Zero text files (.md, .docx) were delivered, although they made up the majority of the project.

The failure was a clean split along file type, which suggests a specific delivery branch (text-file provisioning) failed while another (binary provisioning) worked.

What Should Happen?

The file list announced at session start should reflect what is actually delivered into the container — or the delivery failure should be surfaced to the user instead of failing silently. In this case: all ~130 announced project files (including every .md/.docx text file) should have been present in /mnt/project/, not only the 81 binary files.

Error Messages/Logs

No error message was surfaced to the user. Inside the session, any file read (view/ls) on a .md/.docx path failed because those files were simply absent from /mnt/project/, while ls listed 81 binary files (jpg/png/pdf/xlsx). Semantic search over project knowledge still returned content from the missing files — findable, but not openable. The silence of the failure is part of the problem.

Steps to Reproduce

Note: the failure is transient/session-scoped (a later session the same day received all files), so it cannot be reproduced on demand. The following steps reliably DETECT the condition when it occurs:

1. Open a claude.ai Projects session (web UI) in a project containing both text files (.md/.docx) and binary files (jpg/png/pdf/xlsx).
2. Ask Claude to list the actual container contents: ls /mnt/project/.
3. Compare the count against the file list announced at conversation start. → Observed on 15 July 2026: ~130 files announced, 81 delivered.
4. Break the delivered files down by extension.

→ Observed: 100% binary (jpg/png/pdf/xlsx), zero .md/.docx — although text files made up the majority of the project.

1. Ask Claude to view any of the missing .md files → fails (file absent from disk).
2. Ask Claude to search project knowledge for content that lives in one of the missing .md files → search RETURNS the content.

→ The missing files are findable (semantic index works) but not openable (file delivery failed) — a clean split along file type, suggesting the text-file provisioning branch failed while binary provisioning and indexing worked.

1. Start a fresh session in the same project → full delivery (in our case: 204 files incl. 107 .md), confirming the failure is session-scoped, not project-side.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

-

Claude Code Version

N/A — claude.ai web UI (Projects feature), no CLI involved. Failure was transient: a fresh session in the same project the same day (15 July 2026) received all files, so this is not a version regression but a session-scoped delivery failure.

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Terminal/Shell: N/A — issue occurred entirely in the claude.ai web UI (Projects), no terminal involved.

Suggested mitigation pattern (what worked for us, shared in case it helps others)

We now run this routine at the start of every session, and it caught the failure immediately:

1. Verify the disk, not the list. At session start, have the assistant actually read the key files (ls/view) instead of trusting the announced file list. The list is generated from the project manifest, not from what actually arrived in the container.
2. If the first read fails, count by type. ls + extension breakdown takes seconds. Text files missing while binaries are present is the signature of this platform failure — it is not a project or user error, and no amount of re-uploading inside the session will fix it.
3. Never let the assistant rebuild file contents from semantic search results. That is where fabricated file versions come from. In a degraded session, restrict work to receiving information and preparing a handover; do real file edits only in a session that has the full container (start a new session if needed).
4. Treat "most recently listed" and "actually current" as different claims — verify content, not metadata.

Impact

Without a start-of-session verification routine, this failure is invisible: the assistant appears to know the project (search works) while being unable to read any of its actual text files — the exact precondition for confident, fabricated output.

Related issues: #10647 (files announced/connected but not accessible),
#2144 (file contents replaced by generated versions), #10841 (stale content served despite updated file list).