[BUG] Project files no longer available on the session disk (/mnt/project) since the 6 October sessions change

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?

Subject: Project files no longer available on the session disk (/mnt/project) since the 6 October sessions change

Since the project chat was merged into the unified session interface, files in my claude.ai Projects are no longer available to Claude as files on disk. This has stopped a workflow that had been running for months. I would like to know whether this is a regression that will be fixed, or a permanent change I need to design around.

To be clear up front: everything below happened inside Claude, in Claude's own cloud environment. I have not run anything on my own computer, there is no terminal or local install involved, and there is nothing on my side that could be misconfigured. The commands shown were run by Claude, in Claude's sandbox, at my request.

What changed

Until early October, a chat opened inside a Project could see that Project's files on disk at /mnt/project. Claude could run Python scripts against them, checksum them and edit them in place. That is what my workflow depends on.

As of now, in every session I have tried, that path does not exist:

$ ls /mnt
attach
sandboxing
skills
user-data

$ python3 /mnt/project/preflight.py /mnt/project
python3: can't open file '/mnt/project/preflight.py': [Errno 2] No such file or directory
EXIT=2

The files themselves are fine. They are listed in the Context panel, they all have content, and Claude can read them through the project tool. They are just not on disk, so nothing can be run against them.

Scope of testing

• Three separate sessions, across two different Projects (38 files and 40 files)
• Identical result every time
• Model: Opus 5.5 (claude-opus-5-5) throughout
• Tested 12 October 2026
• One of the three was an existing chat in the older Project, not a new session

Why this stops the work rather than slowing it

The Project holds a document-production system: around eight Python scripts that verify and process the Project's own files. Each takes a directory of files as input. The documented first step is a preflight check that confirms the files in the Project match the ones that were built, by checksum and line count.

Without the mount, none of it runs. Asking Claude to reconstruct the files through the project tool and run the scripts on the copies does not work either, because the entire point of the check is to verify the actual bytes in the Project. A checksum of a reconstructed copy proves nothing.

A second, possibly separate problem

When I asked a session for the line count of one file, it reported that the project tool had returned only the first 262,144 bytes of a 485,445-byte file. 262,144 is exactly 256 KiB, which looks like a deliberate retrieval cap rather than a transfer error.

If that is right, then any Project file over 256 KiB is stored whole but served to sessions truncated, with no warning. In my case that is the single most important file in the Project, and roughly its second half is unreachable. This would still be a problem even if the mount were restored tomorrow.

What I am asking

1. Is the loss of /mnt/project a known regression, and is it going to be fixed?
2. If it is not coming back, is there any supported way for a session to read Project files as files, complete and unmodified?
3. Is the 262,144-byte limit intended, and is it documented anywhere?

Even a plain "this is permanent" would help. At the moment I cannot tell whether to wait or to rebuild around it, and I have a stalled project either way.

This is also reported on the GitHub tracker as issue #100261, filed by someone else with the same symptom.

What Should Happen?

expected 39 files, found 39
142 citations · 25 checkable (18% coverage) · 0 DRIFT
PASS — 8 chapters, all with a record, all reaching the
always-read zone (lowest reach 5, floor 3)
PREFLIGHT PASS — 3 gating checks

Error Messages/Logs

The preflight didn’t run: /mnt/project doesn’t exist in this session (can't open file '/mnt/project/preflight.py', exit 2). Your project files aren’t mounted on disk here. They’re only reachable through the project connection, and nothing is in uploads either.

So I have no wc -l or md5sum results to report.

Model name, as this runtime states it: Opus 5.5 (model ID claude-opus-5-5)

I could copy the project docs into a local folder through that connection and run all of this there, but there are two catches. First, the checksums would be for the retrieved copies, which may not match your original uploaded bytes byte-for-byte. Second, fetching a chapter can show its text to me, which goes against “do not open any chapter.” Do you want me to do that, and if so, should I leave the chapters out?

Steps to Reproduce

Run: python3 /mnt/project/preflight.py /mnt/project
Then report: wc -l of RUN_ORDER_v1_9.md and PROJECT_SYSTEM_v2_7.md;
md5sum of every file in /mnt/project; and the model name exactly as
this runtime states it. Nothing else. Do not open any chapter.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

The workspace reports 2.1.296 (Claude Code), from claude --version.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Windows Terminal

Additional Information

Project files no longer available on the session disk (/mnt/project) since the 6 October sessions change