Claude Code Read Prompts Now Show Where Symlinks Lead and Windows Hooks No Longer Fail Open on Quoted Commands
Claude CodeClaude Code 2.1.310 makes file read permission prompts show where a symbolic link actually leads, so users can see the real destination before approving a read. The release also fixes a Windows gap where PreToolUse and PermissionRequest hooks let a tool call through when Git Bash was missing and the hook command was only quoted strings. Auto mode's first-read prompt is clearer as well, explaining when blocking reads outside the working directories makes shell commands ask for permission.
Key Takeaways
- Read permission prompts now show a symlink's destination, so a link inside a project can no longer hide a read of a file elsewhere on the machine.
- A Windows hook fail-open is fixed: PreToolUse and PermissionRequest hooks no longer let a call through when Git Bash is missing and the command is only quoted strings.
- A hook that fails open silently removes the guardrail it was written to provide, which is why the fix matters even though it affects a narrow setup.
- The Windows fix follows related hook fixes in 2.1.309 and 2.1.299, showing a continued tightening of how hooks behave when they cannot run.
- Auto mode's first outside-read prompt now explains that blocking those reads makes shell commands ask for permission, so the trade-off is clear up front.
- None of the changes add a setting; they put the information for an informed approval into prompts users already see.
Read prompts reveal where a symlink leads
Claude Code 2.1.310 changes what a file read permission prompt shows when the file is a symbolic link. Before this release, the prompt named the path Claude asked to read but did not show where the link pointed. A link inside a project folder can point to a file somewhere else on the machine, so approving the read could expose a file the user never meant to share with the session.
The prompt now displays the link's destination. A user who sees a request to read a file in the project can tell at a glance that it resolves to a credentials file, a shell profile or a folder outside the repository, and can decline. The change does not add a new rule or setting. It puts the information needed for an informed decision into a prompt users already see, which matters most for anyone who approves reads quickly during long sessions.
Windows hooks no longer let a tool call through
The second fix closes a fail-open case on Windows. PreToolUse and PermissionRequest hooks are the mechanism teams use to inspect or block a tool call before it runs. Claude Code 2.1.310 fixes a case where these hooks let a tool call through when Git Bash was missing from the machine and the hook's command consisted only of quoted strings, such as a quoted path to a script.
In that situation the hook could not run, and Claude Code treated the result as permission to proceed instead of as a failure. A hook that fails open quietly removes the guardrail it was written to provide, and the user sees no sign that the check never happened. The release makes these hooks behave as the configuration intends. The fix follows earlier work in 2.1.309, which addressed a related Windows case for hooks configured with "shell": "powershell", and in 2.1.299.
A clearer auto mode prompt for outside reads
Auto mode's prompt before the first read outside the working directories was also improved. It now says when blocking those reads makes shell commands ask for permission. Users who decline the first outside read were previously left to discover on their own why later shell commands started prompting. The new wording connects the two behaviors, so the choice is easier to make and the follow-on prompts are less surprising.
Why it matters
None of these changes adds a feature, yet each tightens the boundary between what an agent may do and what a user has authorized. Seeing a symlink's real destination and knowing a hook will actually run both help users keep control of a session that touches files and shells on their behalf.