Fix remote terminal env var collection using wrong workspace scope

[renan-r-santos]

Fixes microsoft/vscode-python-environments#986

Hi @eleanorjboyd and @anthonykim1. I gave it a try at fixing the shellStartup issue reported here. I'd appreciate it if you could review this PR.

In remote/devcontainer multi-root workspaces, env var collections were scoped to whichever workspace folder the user last had open in the editor, not the terminal's actual workspace folder. So if you had proj1/main.py open and created a terminal for proj2, you'd get proj1's Python venv activated.

The local terminal path already handles this correctly by resolving the workspace folder from the terminal's CWD (getWorkspaceForTerminal). The remote path just used getLastActiveWorkspaceRoot() unconditionally. There's even a TODO in the codebase noting that "last active workspace is known to be unreliable".

The fix matches initialCwd against workspace folders on the server side before applying env var collections, falling back to the old behavior when the CWD doesn't match anything.

[renan-r-santos]

I manually verified this fixes microsoft/vscode-python-environments#986 by using the Test Resolver.

[eleanorjboyd]

@anthonykim1 is the right person to review this and should be able to get to this tmr- there are some failing checks so if you have time for those I can approve more CI runs.

[Copilot]

Pull request overview

Fixes remote terminal environment variable collection scoping in remote/devcontainer multi-root workspaces by deriving the workspace folder from the terminal’s initial CWD (instead of the last active editor workspace), improving correctness for workspace-scoped env var contributors like Python.

Changes:

• Add workspace-folder resolution for env var collection scoping based on initialCwd.
• Fall back to the previously provided activeWorkspaceFolder when no workspace folder matches the CWD.

[renan-r-santos]

Thank you for taking a look at this!

here are some failing checks so if you have time for those I can approve more CI runs.

I checked the logs, and the two failures seem to be related to temporary networking issues with GitHub when installing dependencies. Maybe a rerun might fix them, considering tests passed on Mac and Windows.

Error: Request https://api.github.com/ failed with status code: 403

[eleanorjboyd]

ah yes good catch- rerunning. AI comments you can ignore if you don't think they are applicable- I sometimes find them helpful

[anthonykim1]

Thanks for looking into this and creating the PR.

Maybe the better fix could be here:

vscode/src/vs/workbench/contrib/terminal/browser/remoteTerminalBackend.ts

Line 196 in c13b565

const activeWorkspaceRootUri = this._historyService.getLastActiveWorkspaceRoot();

Instead we could have

const activeWorkspaceRootUri = getWorkspaceForTerminal(shellLaunchConfig.cwd, this._workspaceContextService, this._historyService)?.uri;

where we use:

vscode/src/vs/workbench/contrib/terminal/common/terminalEnvironment.ts

Lines 382 to 391 in c13b565

	export function getWorkspaceForTerminal(cwd: URI | string | undefined, workspaceContextService: IWorkspaceContextService, historyService: IHistoryService): IWorkspaceFolder | undefined {
	const cwdUri = isString(cwd) ? URI.parse(cwd) : cwd;
	let workspaceFolder = cwdUri ? workspaceContextService.getWorkspaceFolder(cwdUri) ?? undefined : undefined;
	if (!workspaceFolder) {
	// fallback to last active workspace if cwd is not available or it is not in workspace
	// TOOD: last active workspace is known to be unreliable, we should remove this fallback eventually
	const activeWorkspaceRootUri = historyService.getLastActiveWorkspaceRoot();
	workspaceFolder = activeWorkspaceRootUri ? workspaceContextService.getWorkspaceFolder(activeWorkspaceRootUri) ?? undefined : undefined;
	}
	return workspaceFolder;

[renan-r-santos]

Maybe the better fix could be here:

Yes, definitely! Thanks for the suggestion.
I noticed there were no tests for getWorkspaceForTerminal, so I added some covering the CWD-based resolution and the fallback behavior.