False positive: trailing period in directory name triggers 'suspicious Windows path pattern' warning on macOS

Summary

Claude Code flags paths containing a directory name with a trailing period (e.g., ABC Co.) as a suspicious Windows path pattern, blocking writes to CLAUDE.md without manual approval. This is a false positive on macOS, where trailing periods in directory names are valid.

Environment

• OS: macOS (Darwin 25.5.0)
• Path type: Google Drive for Desktop shared drive (mounted at ~/Library/CloudStorage/)

Reproduction

1. Have a directory anywhere in a file path whose name ends with a period — e.g., ABC Co.
2. Place a CLAUDE.md file inside that path (or a subdirectory of it)
3. Ask Claude Code to write to that CLAUDE.md

Blocked path (triggers warning):

/Users/kendavis/Library/CloudStorage/GoogleDrive-ken@relay.build/Shared drives/ABC Co./Inventory-Reporting/CLAUDE.md

Warning shown:

"Claude requested permissions to write to [path], which contains a suspicious Windows path pattern that requires manual approval."

Expected behavior

No warning. Trailing periods in directory names are valid on macOS/HFS+/APFS. The pattern check should not fire for paths that are otherwise normal macOS absolute paths.

Actual behavior

The write is blocked and requires manual approval every time, even though:

• The user is on macOS
• The path is a standard absolute POSIX path (starts with /Users/)
• No Windows-specific characters (backslashes, drive letters, UNC \\ prefix) are present

Workaround

Renaming the directory to remove the trailing period (ABC Co. → ABC Co) resolves the issue immediately — subsequent writes to CLAUDE.md go through without any prompt.

Root cause hypothesis

The path pattern scanner likely uses a regex that matches directory names ending in . (a period followed by /), treating it as a Windows-style file extension in a path component. On Windows, directory names cannot end with a period (NTFS strips them), so such a path would indeed be unusual on Windows — but it's perfectly valid on macOS.

Suggest tightening the check to only fire when other Windows indicators are present (backslashes, drive letters like C:, UNC prefix \\), or to skip the check entirely when the path starts with / (unambiguously a POSIX absolute path).