[BUG] CLAUDE.md not loaded when working directory is a UNC path (Windows)

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?

On Windows, when the workspace / working directory is a UNC path (\\server\share\...), Claude Code loads no CLAUDE.md / .claude/CLAUDE.md memory files. The exact same folder opened via a mapped drive letter, or copied to local disk, loads them correctly.

Notably, .claude/settings.json (permissions + PreToolUse hooks) does load correctly from the same UNC working directory, so this is specific to memory-file discovery, not general .claude/ discovery. Reproduced on two separate machines.

What Should Happen?

CLAUDE.md, .claude/CLAUDE.md, CLAUDE.local.md, and .claude/rules/* should load regardless of whether the working directory is a UNC path, a mapped drive, or a local path - the way it did in 2.1.156 and earlier.

Error Messages/Logs

No error or warning is shown - memory simply isn't loaded (silent failure).

Steps to Reproduce

1. Create a project on a network share containing .claude/CLAUDE.md.
2. Open it / run claude -p with the working directory as a UNC path, e.g. \\server\share\proj, and ask whether project memory is loaded -> NOTLOADED.
3. Map the same share to a drive letter and open the same folder as Z:\proj; ask again -> LOADED (model can quote a line from the file).
4. Copy the folder to a local disk -> LOADED.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.156

Claude Code Version

2.1.159 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Running the VS Code native Claude Code extension (anthropic.claude-code-2.1.159-win32-x64). Also reproduced by directly running the bundled resources\native-binary\claude.exe from PowerShell with the working directory set to a UNC vs a mapped path - so the fault is in the binary, not the extension wrapper.

Bisected by testing versions 2.1.156 through 2.1.159: the regression was introduced in 2.1.157, and 2.1.156 is the last working version. Likely related to 2.1.157's repo-root resolution change (changelog: "Fixed --worktree/--worktree --tmux returning to the canonical repo root instead of the current linked worktree") - the memory ancestor-walk appears unable to resolve the \\server\share root and therefore finds zero memory files.