[BUG] Read/Edit Tools Don't Support Bash-Style Paths (Inconsistent with Other Tools)

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?

Read and Edit tools fail with bash-style paths (/c/Users/path/file.txt) on Windows, while Glob, Grep, and Write tools work correctly with the same path format.

This creates inconsistent behavior across Claude Code's file operation tools. Users working in git bash environments must remember which tools support which path formats, and paths must be converted between formats when switching between tools.

Bash-style paths WORK in these tools:

• ✅ Glob tool: Glob(pattern: "*.txt", path: "/c/Users/[user]/path-test") - Success
• ✅ Grep tool: Grep(pattern: "search", path: "/c/Users/[user]/path-test") - Success
• ✅ Write tool: Write(file_path: "/c/Users/[user]/file.txt") - Success (file created correctly)

Bash-style paths FAIL in these tools:

• ❌ Read tool: Read(file_path: "/c/Users/[user]/file.txt") - Error: "File does not exist"
• ❌ Edit tool: Edit(file_path: "/c/Users/[user]/file.txt") - Error: "File does not exist"

What Should Happen?

All file operation tools should support bash-style paths consistently. Since Glob, Grep, and Write already support this format, Read and Edit should as well.

Expected: Read(file_path: "/c/Users/[user]/file.txt") should successfully read the file, just like Glob/Grep/Write do.

Error Messages/Logs

### Read Tool with Bash-Style Path

Read(file_path: "/c/Users/[user]/path-test/test.txt")
Error: File does not exist


### Edit Tool with Bash-Style Path

Edit(file_path: "/c/Users/[user]/path-test/test.txt", old_string: "test", new_string: "updated")
Error: File does not exist

Steps to Reproduce

Setup

# Create test file in git bash
mkdir -p /c/Users/[user]/path-test
echo "test content" > /c/Users/[user]/path-test/test.txt

Read Tool - Reproduces Bug

1. Run Read(file_path: "/c/Users/[user]/path-test/test.txt")
2. Result: ❌ Error: "File does not exist"
3. Run Read(file_path: "C:/Users/[user]/path-test/test.txt")
4. Result: ✅ Success - reads 1 line

Edit Tool - Reproduces Bug

1. First read with Windows path: Read(file_path: "C:\\Users\\[user]\\path-test\\test.txt")
2. Then edit with bash path: Edit(file_path: "/c/Users/[user]/path-test/test.txt", old_string: "test", new_string: "updated")
3. Result: ❌ Error: "File does not exist"
4. Edit with Windows path: Edit(file_path: "C:/Users/[user]/path-test/test.txt", old_string: "test", new_string: "updated")
5. Result: ✅ Success

Glob/Grep Tools - Work Correctly (for comparison)

1. Run Glob(pattern: "*.txt", path: "/c/Users/[user]/path-test")
2. Result: ✅ Success - finds files
3. Run Grep(pattern: "test", path: "/c/Users/[user]/path-test")
4. Result: ✅ Success - finds matches

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.27

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Note: The file definitely exists - it can be read successfully with Windows-style paths and found by Glob/Grep with bash-style paths.

Impact

Current workaround: Convert all bash-style paths to Windows-style before calling Read/Edit

• Adds unnecessary complexity to path handling logic
• Inconsistent behavior is confusing for users
• Users in git bash must mentally track which tools support which formats
• Breaks the principle of least surprise - tools should behave consistently

Root Cause (Suspected)

Read and Edit tools likely use a different path resolution mechanism than Glob/Grep/Write. The working tools probably normalize paths or use a library that handles bash-style paths, while Read/Edit use a simpler resolver.

Proposed Fix

Add bash-style path support to Read and Edit tools to match Glob/Grep/Write behavior:

1. Detect /c/path format
2. Convert to Windows-style internally: C:\path or C:/path
3. Proceed with operation

This would provide consistent path format support across all file tools.

Related Issues

• Issue #7935 - Cache poisoning bug with forward-slash paths (separate but related)
• Note: This bug is specifically about bash-style /c/path support (not Windows C:/path format)
• The cache bug affects Windows forward-slash paths; this is about Unix-style paths

Testing Methodology

All tests performed with:

• Fresh bash-created files
• Isolated test directory
• Clean state between tests
• Reproducible across multiple sessions
• Full test matrix available (19 isolated test files)

Comprehensive Testing Results

Read Tool Path Format Support

| Path Format | Path Used | Result | Error Message |
|-------------|-----------|--------|---------------|
| Windows Backslash | C:\Users\[user]\path-test\test.txt | ✅ Success | Read 1 line |
| Windows Forward | C:/Users/[user]/path-test/test.txt | ✅ Success | Read 1 line |
| Bash Style | /c/Users/[user]/path-test/test.txt | ❌ Failed | "File does not exist" |

Edit Tool Path Format Support (after valid Read)

| Read Format | Edit Format | Edit Result | Error Message |
|-------------|-------------|-------------|---------------|
| C:\ | C:\ | ✅ Success | Updated file |
| C:\ | C:/ | ✅ Success | Updated file |
| C:\ | /c/ | ❌ Failed | "File does not exist" |

Even with valid cache from successful Read, bash-style Edit fails.

Glob/Grep Tool Path Format Support (demonstrating expected behavior)

| Tool | Path Format | Result | Notes |
|------|-------------|--------|-------|
| Glob | C:\path | ✅ Success | Found 15 files |
| Glob | C:/path | ✅ Success | Found 15 files |
| Glob | /c/path | ✅ Success | Found 15 files |
| Grep | C:\path | ✅ Success | Found 10 files |
| Grep | C:/path | ✅ Success | Found 10 files |
| Grep | /c/path | ✅ Success | Found 10 files |