[BUG] Working directory resolves Windows junction points instead of using VS Code workspace path

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?

When opening a project folder via a Windows junction point in VS Code, Claude Code
resolves the junction and reports the physical path as the working directory instead
of the junction path that was used to open the folder.

For example, opening via junction path:
C:\Users\User\Cloud\MyProject

Claude Code reports:
C:\Users\User\OneDrive\MyProject

Other VS Code extensions (e.g., GitHub Copilot) correctly see the junction path,
suggesting Claude Code uses an OS-level call (like process.cwd()) that resolves
junctions, rather than reading from VS Code's workspace API.

What Should Happen?

Claude Code should use the path as opened in VS Code — i.e., the junction path —
consistent with how VS Code's workspace API (vscode.workspace.workspaceFolders)
reports it. The fix would be to read the working directory from the VS Code
workspace folder API instead of the OS-level call.

Error Messages/Logs

Steps to Reproduce

1. Create a Windows junction point pointing to a project folder:

mklink /J "C:\Users\User\Cloud\MyProject" "C:\Users\User\OneDrive\MyProject"

1. Open the junction folder in VS Code (File > Open Folder, select the junction path)

1. Start a Claude Code session

1. Ask Claude Code what the project folder is

1. Claude Code reports the resolved physical path instead of the junction path

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.52

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_