read_file tool returns "File not found" for valid absolute paths on Windows

Environment

• OS: Windows 10
• Hermes version: latest (2026-05-31)
• Shell: git-bash (MSYS)

Bug description

The read_file tool consistently returns "File not found" for valid files that are confirmed to exist and are readable by Python.

Reproduction

1. File exists and is readable via Python:

os.path.exists(path)   # True
os.path.getsize(path)  # > 0
open(path).readline()  # works fine

1. read_file with the same absolute path fails:

read_file(path="/absolute/path/to/readable.py")
→ {"error": "File not found", "similar_files": [".\\__pycache__", ...]}

1. The similar_files list is always the same static set — suggesting fallback to a default directory listing when path resolution fails.

Pattern

• Fails: absolute paths to files outside the session working directory
• Fails: absolute paths to files inside the working directory (intermittent)
• Fails: paths on different drives (e.g. D:\)
• Works: execute_code + Python open() (always)
• Works: terminal with MSYS-translated paths (e.g. /c/Users/...)

Suspected root cause

The tool's path resolution CWD differs from the Python process CWD in the sandbox. The backend sandbox appears to have a different working directory than the session's configured cwd, causing absolute paths to be rejected when they don't map into the sandbox's view of the filesystem.

Workaround

execute_code("open(path).read()")  # works reliably
terminal("cat /path/to/file")       # works via MSYS translation

Impact

Moderate. Breaks reading skills files, vault files, and cross-drive files. Workaround exists but adds friction.