[BUG] Read tool fails with 'EUNKNOWN: unknown error, read' on local D: drive files while child processes read the same files fine (Windows 11, desktop app)

Environment

• Claude Code (desktop app harness), CLI version 2.1.197 (was also present on 2.1.187)
• Windows 11 Home 10.0.26200, LG 15U50P laptop
• Project working directory: D:\ (second internal SATA HDD, NTFS, plain local volume — not SUBST, not network, not BitLocker)
• C: is NVMe system drive; Read works fine there

Symptom

Any Read tool call targeting a file on D: fails immediately with:

EUNKNOWN: unknown error, read

This includes freshly created tiny text files (echo test > D:\WiNG\_test.txt then Read → fails). \\?\D:\... extended-length path form fails identically. Images on D: cannot be viewed at all.

Key isolation facts (why this looks like a Read-tool-layer bug, not an OS/AV issue)

1. Child processes spawned by the Bash/PowerShell tools read the same file fine: Node.js fs.readFileSync, async fs.readFile, and raw fs.open+fs.read all succeed on the exact same path in the same session; Python open() succeeds; Get-Content succeeds; ripgrep (Grep tool, single-file target) succeeds.
2. Immediately re-running Read on that same file still fails with EUNKNOWN.
3. EUNKNOWN is not a standard libuv/Node errno name surfaced by normal fs failures (ENOENT/EACCES/EBUSY would be expected) — it is the fallback for an unmapped native error code, which suggests the failure happens in the harness's own file-access path (broker/sandbox layer?), not in a plain fs.read.
4. Reproduces with all AV/filters unchanged for both drives: Defender service fully stopped; AhnLab Safe Transaction / ALYac minifilters are registered globally (would affect C: too, but C: reads work).
5. Multi-file (directory-recursive) Grep on D: also silently drops matches that single-file Grep finds — possibly related.
6. Edit/Write on D: files DO work (this session successfully patched a D: file via PowerShell and via Edit tool on C→D copies), so it is specifically the read path.

Timeline

• Started around CLI 2.1.187 (2026-06-26) and persists on 2.1.197 (2026-07-02).
• Independent of a separate (now fixed) issue where user-level TEMP pointed to D: and caused temp-file cleanup races.

Expected

Read should read local NTFS fixed-drive files the same way on any drive letter, or at minimum surface the real errno.

Workarounds in use

• Grep with a single-file path and head_limit: 0 (loses >400-char lines)
• Copy-Item to C: then Read