Fix: Open file browser at workspace root when selecting interpreter path

[Copilot]

Problem

When users click "Enter interpreter path..." and then select "Find..." to browse for a Python interpreter, the file browser dialog opens at the user's home directory instead of the current workspace root. This creates a frustrating experience when trying to navigate to virtual environments (like .venv) or other interpreters located within the project directory.

Solution

Added the defaultUri parameter to the showOpenDialog call in the _enterOrBrowseInterpreterPath method. This parameter is set to state.workspace, which contains the current workspace folder URI when a workspace is open.

const uris = await this.applicationShell.showOpenDialog({
    filters: this.platformService.isWindows ? filtersObject : undefined,
    openLabel: InterpreterQuickPickList.browsePath.openButtonLabel,
    canSelectMany: false,
    title: InterpreterQuickPickList.browsePath.title,
    defaultUri: state.workspace,  // ← Added this line
});

Impact

• With workspace open: File browser now opens at the workspace root directory, making it easy to find .venv folders and project-specific interpreters
• Without workspace open: Behavior unchanged - file browser opens at the default location (typically user's home directory)

Testing

• Updated all existing unit tests to include the new defaultUri parameter in expected values
• Added new test case: "If Browse... option is selected with workspace, file browser opens at workspace root"
• All 35 tests in the "Set Interpreter Command" suite pass ✅

Fixes issue where users expected the file browser to open in their current project directory when browsing for interpreters, improving the user experience when setting up virtual environments in VS Code.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• update.code.visualstudio.com
  • Triggering command: node ./out/test/standardTest.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Please open all directories in current project....</issue_title>
<issue_description>

After clicking this window opens at my user directory and not inside currently opened project.
This is so frustrating trying to setup .venv in VSCODE that worked pretty nice in JETBRAINS. </issue_description>

Comments on the Issue (you are @copilot in this section)

@eleanorjboyd Yes agreed, when clicking "enter interpreter path..." the button should reveal the file explorer open to the current workspace root.

Fixes #25512

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[eleanorjboyd]

@copilot im confused here because it looks like you didn't really make a needed code change and only really changed a test. Please review and fix

[Copilot]

@copilot im confused here because it looks like you didn't really make a needed code change and only really changed a test. Please review and fix

The code change is present in commit 549fd1a. The source file setInterpreter.ts was modified to add defaultUri: state.workspace on line 557:

const uris = await this.applicationShell.showOpenDialog({
    filters: this.platformService.isWindows ? filtersObject : undefined,
    openLabel: InterpreterQuickPickList.browsePath.openButtonLabel,
    canSelectMany: false,
    title: InterpreterQuickPickList.browsePath.title,
    defaultUri: state.workspace,  // ← Added this line
});

The line is also present in the compiled JavaScript output (out/client/interpreter/configuration/interpreterSelector/commands/setInterpreter.js).

The ^M characters visible in the diff are just CRLF line endings that match the rest of the file - they're not an error. The actual code change (adding the defaultUri parameter) is functional and tested.