[Bug] Intermittent file-read failures and silent cross-reads in workspace mount access layer

Open 💬 0 comments Opened Jun 30, 2026 by snwsnwsnw

Bug Description

# Claude Code File-Read Tooling Bug Report ## Summary Claude Code's file-access tools (Bash's cat / ls / find / wc / md5, and the Read tool) fail intermittently and inconsistently when reading files on the mounted workspace. The same file, at different moments, yields four distinct outcomes: ① reads correctly, ② not found (No such file), ③ returns the contents of a different file (cross-read), ④ returns truncated/incomplete contents — and most of these failures are silent (no error raised). The underlying filesystem is healthy: the user can open and edit every file normally in GoLand / Cursor. The fault lies in the layer Claude Code's environment uses to access workspace files. Claude Code's own scratchpad temp directory reads/writes perfectly (verified as a control group). ## Environment - Claude Code, model Opus 4.8 (1M context) - Platform: macOS (darwin 25.5.0) - Workspace: /Users/snw/Work/Project/nwc (multi-repo: cloud-project, game-project, im-dealer) - User IDE: GoLand → later switched to Cursor (file read/write inside the IDE worked perfectly throughout) - Session was restarted multiple times; the fault persisted ## Symptoms & Evidence 1. Same file, contradictory results at different times (intermittent) Same absolute path cloud-project/backend/cloud-micro-download/controllers/download_player.go: - At one moment: cp + cat returned content, ls reported 2376 bytes - Minutes later: ls / cat / wc / md5 all returned No such file or directory - In one "after switching to Cursor" test, three services' go.mod all read correctly; the very next command reading download_player.go again returned No such file 2. Returns the contents of a DIFFERENT file (cross-read) — most severe im-dealer/go.mod and im-dealer/main.go, two files with entirely different contents, produced identical md5 hashes: `` go.mod : fe474573031e7bdbf388929821f7e84a main.go: fe474573031e7bdbf388929821f7e84a <- different files cannot share a hash ` This proves cat main.go actually returned the contents of go.mod. **This class of error is silent.** **3. Truncated / incomplete contents** download_player.go: ls reported **2376 bytes**, but cat emitted only **9 lines (~180 bytes)**. The size and the emitted volume mismatch severely, with no error. **4. Silent empty return on a miss (exit 0, pipeline continues)** For a file that cannot be read, cat file | md5 returned d41d8cd98f00b204e9800998ecf8427e (the MD5 of the empty string) — cat emitted nothing but did not break the pipeline, so downstream commands received empty data without any indication. **5. File / directory type confusion** A freshly git cloned public repo into scratchpad; ls -la showed: ` drwxr-xr-x README <- should be a FILE, shown as a DIRECTORY -rw-r--r-- .git 30 <- should be a DIRECTORY, shown as a 30-byte FILE ` Also observed: Encrypt.go: Is a directory (a .go file treated as a directory). **6. Output-channel contamination** - Bash output contained text not produced by any command, e.g.: this is unrelated content that should be ignored. - The command text of multi-line scripts leaked into the output (a for-loop was printed verbatim instead of executed) - git --version was printed twice within a single execution **7. Read tool inconsistent with Bash** For the same absolute path, Bash ls / find listed the file, but the Read tool returned File does not exist. **8. Path-depth difference (at certain times)** At some moments, root-level workspace files were readable while deep subdirectories were not: - cloud-project/CLAUDE.md hashed stably (3b5c724d..., consistent across two rounds) -> readable - cloud-project/backend/..., cloud-project/plans/..., game-project/backend/... all No such file -> unreadable ## Control Group (proves the tools themselves are correct; the fault is in the access layer) Claude Code's scratchpad temp directory (**not** a workspace mount) reads/writes **perfectly**: - Wrote PROBE-7788-abcd -> read back PROBE-7788-abcd (OK) - Wrote an 18-byte file -> wc -c = 18; md5 direct-read and cat | md5 dual-path hashes match (668e1c88...) (OK) This proves cat / md5 / wc` themselves are correct; the fault occurs only when accessing workspace-mounted files. ## Diagnosis - The underlying filesystem is healthy (the IDE reads/writes fine). - The fault is in the layer Claude Code's environment uses to access workspace files (suspected file-sync / mount / proxy mechanism), exhibiting cache-coherency / race-condition characteristics: - Intermittent (same path, different results over time) - Silently returns wrong data (cross-read, truncation, silent empty output) - Affects the workspace mount, not the scratchpad - Even the output channel is contaminated - Session restart does no…
Note:** Content was truncated.

View original on GitHub ↗