[BUG] Claude.ai Projects: project files are not injected into the sandbox when a chat joins a project after the container has already been created

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?

Note on repo choice: this is a Claude.ai Projects / project-knowledge issue, not Claude Code. Filing here because this is the only public Anthropic issue queue and the closest related reports (#92752, #10647) live here. Several required template fields have no applicable option; the least-wrong values are given and flagged as N/A rather than presented as accurate.

Summary

Project knowledge reaches a conversation through two independent channels:

1. The file list in the assistant's system context — file names plus /mnt/project/ paths, with an instruction to read them using the file tools.
2. Actual injection of those files into the sandbox filesystem at /mnt/project/.

When a chat is created outside a project, triggers sandbox creation, and is then added to a project, channel 1 updates correctly but channel 2 does not. The assistant is handed a list of 23 project files under /mnt/project/ and told to read them, while /mnt/project/ does not exist in the filesystem at all.

Why this is worse than a missing feature

This is a silent failure. From inside the conversation, the assistant cannot distinguish:

(a) "this project exposes knowledge only through semantic retrieval, no filesystem channel", from
(b) "the filesystem channel exists, but injection failed for this particular conversation".

In observed cases the assistant concludes (a) and proceeds accordingly. In one instance it produced a lengthy, internally consistent, and incorrect self-diagnosis — attributing the problem to retrieval chunk granularity and warning the user that any file it reconstructs may contain undetectable omissions. The underlying cause was simply that /mnt/project/ had not been populated.

The system context actively points the assistant at a path that does not exist, so the wrong conclusion is the reasonable one to draw.

<img width="847" height="714" alt="Image" src="https://github.com/user-attachments/assets/c06e633d-fdf5-419a-be1b-960f25a7c971" />
<img width="841" height="795" alt="Image" src="https://github.com/user-attachments/assets/0760b27d-f5b1-497c-b800-e6f48742e5fc" />

What Should Happen?

Either of these would resolve the silent-failure aspect:

1. File injection re-resolves on container (re)creation using the chat's current project membership, rather than a value fixed at first creation. This is the preferable fix, and evidence below suggests the re-injection machinery already exists.
2. Or: the file list in the system context is not populated when the corresponding files are absent from the sandbox. Even without fixing the injection, this would let the assistant detect the gap and fall back to project_knowledge_search deliberately, instead of being directed to a broken path and inferring the wrong architecture.

Error Messages/Logs

bash: wc -l /mnt/project/CLAUDE.md
→ wc: /mnt/project/CLAUDE.md: No such file or directory

view: /mnt/project/CLAUDE.md
→ Path not found

(while the system context concurrently lists 23 files under /mnt/project/)

Steps to Reproduce

Two runs differing by exactly one variable. Requires a project with at least one file in its knowledge base.

Control — works as expected:

1. Start a new chat outside any project.
2. Send a message that does not require any tool use (e.g. "guess what I want you to do"). The sandbox is not created at this point.
3. Add the chat to the project (chat menu → add to project).
4. Ask it to run wc -l /mnt/project/<a-file-in-your-project>.

→ Succeeds. Correct line count for the current version of the file.

Failing case — differs only at step 2:

1. Start a new chat outside any project.
2. Ask it to run ls /mnt/project. This triggers sandbox creation while the chat has no project. It correctly reports that /mnt/project does not exist, and lists only attach, sandboxing, skills, transcripts, user-data under /mnt.
3. Add the chat to the same project.
4. Ask it to run wc -l /mnt/project/<same-file>.

→ Fails. bash returns No such file or directory; the view tool returns Path not found. The assistant simultaneously reports that its system context does list 23 project files under /mnt/project/.

The only difference between the two runs is whether step 2 caused the container to be created before the chat joined the project.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — Claude.ai web, not Claude Code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This does not self-heal — the resolution appears bound to first container creation

Containers are created lazily (not at conversation start) and are destroyed and recreated repeatedly during a conversation's life. Measured in a correctly initialised conversation in the same project:

• /proc/uptime read 0.0 minutes while the conversation itself spanned three weeks → containers are short-lived and recreated on demand.
• The injected files reflected the current project state, not the state at conversation start: a file that was 199 lines when the conversation began read 291 lines on a later turn → recreation does re-inject current project knowledge.
• /mnt/project is absent from findmnt output and its files carry a normalised mtime (1979-12-31) → the files are injected as a packaged layer, not bind-mounted. A side effect is that mtime cannot be used to tell whether the snapshot is current.
• /mnt/user-data/outputs persists across container recreation (real mtimes); /home/claude does not (contents cleared).

Despite all of the above, a conversation affected by this bug still cannot read /mnt/project/ three weeks and many container recreations later. This rules out "injection is merely delayed" or "reopen the chat and it resolves" — the resolution is evidently bound to a value determined at first container creation and reused on every subsequent recreation.

Workarounds

• Prevention: create the chat from inside the project when filesystem access to project knowledge will be needed.
• Mitigation for an already-affected chat: upload the needed files directly into the conversation; they land in /mnt/user-data/uploads and are readable. (Same class of workaround noted in #92752, which reports that direct upload bypasses both the container snapshot and the retrieval index.)

Related issues
#92752 — project knowledge index serves stale file state; notably distinguishes the "container snapshot" from the "retrieval index" as two separate delivery paths, which is the same two-channel split this report isolates.
#10647 — /mnt/project/ present but incomplete: only manually uploaded files readable, GitHub-connector files missing entirely. Establishes that partial/absent /mnt/project/ population is a pre-existing failure mode.
#48394 — unrelated surface (local Claude Code), same shape: identity bound at creation time, so moving the project breaks the association.