[BUG] The file system tools in Claude's environment have inconsistent behavior when handling files with Unicode characters in their names.

Environment

• Platform (select one):
• [ ] Anthropic API
• [ ] AWS Bedrock
• [ ] Google Vertex AI
• [X] Other: <!-- specify --> Claude MCPs
• Claude CLI version: <!-- output of claude --version --> $ claude --version

1.0.27 (Claude Code)

• Operating System: <!-- e.g. macOS 14.3, Windows 11, Ubuntu 22.04 --> Darwin ningal.local 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:48:46 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T8103 arm64

• Terminal: <!-- e.g. iTerm2, Terminal App --> iTerm, VSCode

File System Tools Unicode Bug Report

Summary

The file system tools in Claude's environment have inconsistent behavior when handling files with Unicode characters in their names. Files containing characters like the narrow no-break space (U+202F) can be listed in directory operations but cannot be accessed by any file manipulation operations.

Bug Description

File system tools exhibit inconsistent Unicode handling:

• Working operations: list_directory, search_files, directory_tree successfully find and display files with Unicode characters
• Failing operations: move_file, read_file, get_file_info, write_file (when used with existing Unicode filenames) all fail with "ENOENT: no such file or directory" errors

Reproduction Steps

1. macOS Screenshot Files

macOS automatically creates screenshot files with narrow no-break space characters (U+202F) before "AM"/"PM" in timestamps:

Screenshot 2025-06-15 at 7.32.08<U+202F>PM.png

2. Directory Listing Works

list_directory(/Users/philip/Desktop)

Returns:

[FILE] Screenshot 2025-06-15 at 7.32.08 PM.png

3. File Operations Fail

move_file(
  source: /Users/philip/Desktop/Screenshot 2025-06-15 at 7.32.08 PM.png
  destination: /Users/philip/Desktop/Screenshots/Screenshot 2025-06-15 at 7.32.08 PM.png
)

Returns:

Error: ENOENT: no such file or directory

4. All File Operations Fail

The following operations all fail on the same files that appear in directory listings:

• get_file_info
• read_file
• move_file
• File operations via repl using window.fs.readFile

Technical Details

Character Analysis

The problematic character is U+202F (narrow no-break space):

• Character code: 8239 (decimal)
• Hex: 0x202F
• Appears visually identical to regular space (U+0020) in most contexts
• Commonly used by macOS in screenshot filenames before AM/PM

Attempts Made

1. Exact filename matching: Used filenames exactly as shown in directory listings
2. Unicode escape sequences: Tried \u202F in parameters
3. Programmatic construction: Built filenames using String.fromCharCode(0x202F)
4. Various escaping: Attempted backslash escaping, quotes, etc.
5. Direct file system API: Used window.fs.readFile in repl environment

All approaches failed despite the files being visible in directory operations.

Expected Behavior

One of the following should occur:

1. Consistent Unicode support: All file operations should handle Unicode characters the same way directory listings do
2. Consistent filtering: Directory listings should exclude files that cannot be manipulated by other operations
3. Clear error messaging: Operations should indicate when Unicode character issues are the cause of failures

Impact

This bug prevents users from:

• Organizing screenshot files (common use case)
• Working with files created by macOS and other systems that use Unicode in filenames
• Performing basic file management tasks on legitimately named files

Environment

• Claude file system tools
• Files created by macOS screenshot functionality
• Unicode characters: U+202F (narrow no-break space)

Recommended Fix

Implement consistent Unicode normalization and handling across all file system operations, ensuring that if a file can be listed, it can also be manipulated by other file operations.