Python public environment API selection diverges from run/debug/terminal interpreter #1896

Environment data

Reproduced on both macOS and Linux:

• Regression / last known working integration-on version: unknown.
• Observed through the documented Python extension API in isolated native extension development/test windows, without an attached extension-host debugger.
• Manual interpreter picker behavior has not been tested. This is an API/integrated-execution mismatch, not a claim that the picker itself is broken.

Repro Steps

1. Create two disposable venvs, env-a and env-b, and a trusted single-root Python project. Both environments must be resolvable.

2. Use a fresh profile with:

   {
       "python.useEnvironmentsExtension": true,
       "python.defaultInterpreterPath": "<test-root>/env-a/bin/python",
       "python-envs.workspaceSearchPaths": [
           "<test-root>/env-a",
           "<test-root>/env-b"
       ],
       "python-envs.terminal.autoActivationType": "command",
       "python.terminal.activateEnvironment": true,
       "workbench.enableExperiments": false,
       "python.experiments.enabled": false,
       "telemetry.telemetryLevel": "off"
   }

3. Open a Python document and let Python/Environments activate naturally.

4. From extension-host code, use Python's public API to select A, then B for the same workspace URI:

   const api = vscode.extensions.getExtension("ms-python.python").exports.environments;
   const resource = vscode.workspace.workspaceFolders[0].uri;
   
   await api.updateActiveEnvironmentPath(envAExecutable, resource);
   // Run the probe below; it uses A.
   
   await api.updateActiveEnvironmentPath(envBExecutable, resource);
   console.log(api.getActiveEnvironmentPath(resource));

5. After the B update resolves and allowing propagation time (the macOS harness waited four seconds before inspecting selection), compare:

   • Python's public getter;
   • Environments' getEnvironment(resource);
   • Run Python File in Terminal (python.execInTerminal);
   • a newly created Python terminal (python.createTerminal), executing python probe.py;
   • a debugpy launch of probe.py, without an explicit interpreter override.

   Probe interpreter identity, not terminal labels:

   import json
   import sys
   print(json.dumps({"executable": sys.executable, "prefix": sys.prefix}))

Expected behavior

Python's public updateActiveEnvironmentPath sets the active environment for the resource. The reported selection and the interpreter used for run/debug/new terminals should agree, including when Environments integration is enabled.

Actual behavior

After requesting B through Python's API, its getter reports B, but Environments retains A and all three execution surfaces use A.

The reciprocal control also fails to synchronize: selecting B through Environments' API makes execution use B, while Python's public getter stays on A.

Native API control:

const envs = vscode.extensions.getExtension("ms-python.vscode-python-envs").exports;
const environment = await envs.resolveEnvironment(vscode.Uri.file(envBExecutable));
await envs.setEnvironment(resource, environment);

Logs / measured results

The macOS run collected 15 actual sys.executable / sys.prefix probes across three fresh workflow profiles. After requesting B through Python's public API with integration on:

Python public getter:       env-b/bin/python
Environments active env:    env-a/bin/python
Run Python File executable: env-a/bin/python
New terminal executable:   env-a/bin/python
Debug executable:          env-a/bin/python

The off and native-selection controls instead execute env-b/bin/python for all three B probes. Prefixes agree with the measured executables.

The public-API integration-on mismatch was also reproduced in two independent Linux profiles. Linux controls included integration off in both selection orders and native Environments selection.

Additional context

• This points to unsynchronized selection state/API routing across the extensions, rather than establishing an independent terminal-activation defect.
• Existing terminals retaining an earlier environment also occurs in off controls; that is not the distinguishing failure here.
• Python's public getter/setter currently read/update Python configuration state, while integrated execution uses Environments state. The exact fix and ownership should be investigated across both repositories.
• Filing here as a Python Environments integration bug; coordinated changes in microsoft/vscode-python may be necessary.
• No reload-persistence, notebook, manual-picker, or production-population claim is made. Experiments and telemetry remained off.