Unnecessary permission prompts for symlinked files in allowed directory

Bug description

When the current working directory contains symlinks pointing to files in another directory, Claude Code repeatedly asks for read permission on those files — even though:

1. The files (symlinks) are located within the current project directory
2. Read permission for the project directory is already granted (e.g., via CLAUDE.md rules or user approval)

Claude Code seems to resolve the symlink target path and then evaluate permissions against the target directory rather than the link location. Since the target directory is different from the project directory, it triggers a permission prompt.

Expected behavior

If a symlink resides inside an allowed directory, reading it should not require additional permission — regardless of where the symlink target points. The permission check should be based on the symlink's location, not the resolved target path.

Steps to reproduce

1. Create a project directory with a CLAUDE.md that grants read access to all files in the project folder
2. Add a symlink inside the project directory that points to a file in a different directory (e.g., ln -s /other/path/file.txt ./file.txt)
3. Ask Claude Code to read ./file.txt
4. Claude Code will prompt for permission, even though the file is inside the allowed project directory

Environment

• OS: Windows 10 Pro (also likely reproducible on Linux/macOS)
• Claude Code: latest version
• Symlinks created via mklink (Windows) or ln -s (Unix)

Additional context

This is particularly annoying for projects that use symlinks extensively (e.g., shared preamble files, dotfiles, monorepo setups). The user has to repeatedly approve reads for files that should already be permitted.