External Conda environment appears twice after restart

[eleanorjboyd]

Problem

A previously selected external Conda environment can appear twice in the environment collection after restarting VS Code, adding an extra identical entry to the interpreter picker. Refreshing environments removes the extra entry; the selected interpreter remained correct in the observed runs.

Steps to reproduce / verify a fix

1. Enable Python and Python Environments in a disposable VS Code profile with "python.useEnvironmentsExtension": true, "python-envs.defaultEnvManager": "ms-python.python:conda", and an explicit "python.condaPath" pointing to Conda.
2. Create a working Conda prefix outside the workspace and configured Conda environment directories. Disable registration with the process-local environment variable CONDA_REGISTER_ENVS=false during creation and subsequent test launches. Use an isolated HOME/CONDARC and CONDA_ENVS_PATH; confirm the target is absent from the initial discovered list. The tested prefix was named audit-duplicate-target, with Python 3.11.15.
3. Resolve and select that interpreter for the project, refresh environments, and confirm there is exactly one underlying entry for its path. The verified harness seeded the selection through the extension API (example below).
4. Close and reopen the window using the same profile and workspace, preserving the saved selection. Do not manually refresh yet.
5. Open the project's environment picker (python-envs.setEnv with the project URI) and filter by the prefix name. Observed: three matching rows: one normal Recommended copy and two Conda entries. Expected after a fix: only one underlying Conda entry, plus the normal Recommended copy.
6. Cancel the picker and verify the selected interpreter is unchanged. Allow startup work to settle and check the collection again: in the failing runs, it still contains two objects for the same prefix, with different envId.id values.
7. Refresh environments and reopen the picker. Confirm the extra entry disappears, selection remains unchanged, and subsequent restarts no longer introduce an extra entry after a fix.

The seed operation used in step 3, run in a VS Code extension host:

const api = await vscode.extensions.getExtension('ms-python.vscode-python-envs').activate();
const project = vscode.workspace.workspaceFolders[0].uri;
// interpreterPath is the absolute path to Python inside the external prefix.
const selected = await api.resolveEnvironment(vscode.Uri.file(interpreterPath));
if (!selected) {
    throw new Error('External Conda interpreter did not resolve');
}
await api.setEnvironment(project, selected);
await api.refreshEnvironments(undefined);

Use api.getEnvironments('all') and filter by environmentPath.fsPath to count underlying entries. The picker was the real rendered UI, not a mocked picker. The API-based seeding above is the verified setup; a separate end-to-end manual interpreter-path-entry flow was not tested.

Observed results

Tested against commit 4ab81cfabe1652f43f689eefcbd67eaa0f23ffef on macOS arm64, VS Code Insiders, Python extension 2026.4.0, Conda 26.1.0, Python 3.11.15.

Two independent workspace/profile seeds were each closed and cloned into three independent restart profiles. Each seed had exactly one target entry; saved selection/cache state was intentionally retained.

Measurement	Result
Restarts with two target objects after startup settled	6/6
Underlying target objects after explicit refresh	1 in all six
Filtered picker rows before / after refresh	3 / 2 in all six
Selected interpreter remained correct	6/6

Four runs already had two objects at the first startup snapshot; two initially had one and later acquired the duplicate. These are results for this controlled fixture, not a universal occurrence rate.

The original build reproduced the issue without instrumentation. There were no malformed/broken sibling fixtures or project-local .conda. Discovery could still see other environments from the existing Conda installation; the entire discovered collection was not isolated to the test prefix.

Source evidence

Two additional runs with a separate instrumented bundle captured both insertions at the project branch of loadEnvMap:

• One invocation came from refresh().
• The other came from get() / startBackgroundInit().
• Both check for the path before awaiting resolution, then append without rechecking. At the second append, the first object for the same prefix was already in the collection. The insertion order reversed between the two trace runs.

The picker renders a Recommended copy plus the manager's entries, exposing the extra object.

The initiating consumer of the startup refresh was not traced; the Python extension was enabled in every run. This is not a claim that Python Environments independently schedules that refresh, or a Remote-SSH-specific failure. No wrong-interpreter execution or lost selection was demonstrated.