Since 1.42, every resolveEnvironment call spawns conda --version for capability telemetry (sustained high CPU with Anaconda installed) #2001

Environment data

• Python Environments extension version: 1.42.0 (stable) and 1.43.2026110601 (pre-release). Both affected.
• Python extension (ms-python.python) version: 2026.10.0 (also installed: Pylance 2026.4.1, Python Debugger 2026.6.0, Jupyter 2025.9.1)
• VS Code version (Help → About): 1.143.0 (snap)
• OS and version: Ubuntu 24.04.5 LTS, kernel 7.0.0-42-generic
• Python version (& distribution if applicable, e.g. Anaconda): 3.12.3 in the workspace venv. Anaconda is also installed at ~/anaconda3 (conda 25.11.0).
• Environment manager in use: venv (the selected interpreter is <workspace>/backend/.venv/bin/python). Conda is installed but not selected.
• Shell: bash
• Remote / container scenario: none
• Workspace type: single folder, a monorepo with the venv nested at backend/.venv
• Is this a regression? Yes. Last known working version: 1.40.0

Summary

Since 1.42.0, every call to the public resolveEnvironment API starts a capability query for every registered environment manager. Each query then runs getManagerVersionForTelemetryWithTimeout, which calls manager.getVersion(). For conda that spawns conda --version. The result is never cached, so every resolve spawns a new conda process.

On my machine resolveEnvironment is called continuously, about 385–400 times a minute, so the extension spawns about 6–7 conda --version processes a second. Each one takes 0.4–1.1 s of CPU, because conda is a Python program. The extension host sits at 100% of one core with 1.9 GB RSS, and the conda processes use about 2.5 more cores. It never stops on its own: it ran until I reloaded the window, both times it happened.

Repro Steps

I don't have a minimal repro. It started on its own twice:

1. Install Anaconda (conda on disk at ~/anaconda3/bin/conda). Leave pipenv, poetry and pyenv uninstalled.
2. Open a single-folder workspace with a venv at backend/.venv, selected as the interpreter. Python, Pylance, Python Debugger and Jupyter are installed.
3. Wait. On 6 Nov (1.42.0) the loop started about 3 minutes after VS Code started. On 9 Nov (1.43 pre-release) it started 22 s after a package refresh. The Python extension's installed-packages check ran because backend/app/requirements.txt had changed, Python Environments then ran pip list for the venv, and the loop began.

Expected behavior

Resolving an environment does not start a process. If capability telemetry needs a manager's version, it looks the version up once per session (or once per manager change) and caches it.

Actual behavior

• Sustained resolves: "Resolved Python Environment" appears about 385–400 times a minute, steadily, for as long as the window stays open.
• One process per resolve: each resolve is followed by Pipenv not found via settings, cache, or PATH, Using conda from cache, and a new conda --version process ("Ran conda in 424–1104 ms").
• Timeouts: the 1 s telemetry timeout often fires ("Manager version lookup timed out") for conda, pyenv, poetry and pipenv. The timeout doesn't kill the spawned process, so the work continues anyway.
• Log growth: the output channel grows by about 2,500 lines a minute (2.5 MB in about an hour).

Counts from the logs:

Analysis

From dist/extension.js in 1.43.2026110601:

async resolveEnvironment(e) {
  await waitForAllEnvManagers();
  ...
  for (const e of new Set([...n, ...this.envManagers.managers]))
    this.getEnvironmentManagerCapability(e.id, EnvironmentCapability.Resolve).catch(k);
  return await handlePythonPath(e, this.envManagers.managers, n);
}

getEnvironmentManagerCapability leads to captureCapabilityQuery, which in its finally block calls getManagerVersionForTelemetryWithTimeout(e, 1000), which calls manager.getVersion(). For the conda manager that is new CondaVersionCommand(...).execute(), which spawns a process. For pipenv, poetry and pyenv it is a PATH lookup that isn't cached when nothing is found.

This code was added between 1.40.0 and 1.42.0, apparently by #1874, #1923 and #1936. 1.40.0 contains none of it (captureCapabilityQuery, getManagerVersionForTelemetryWithTimeout and EnvironmentCapability.Resolve are absent).

I couldn't tell which caller makes the sustained resolveEnvironment calls. Python, Pylance, Python Debugger and Jupyter all call resolveEnvironment and subscribe to the environment change events, but none of them calls the capability APIs directly. Without conda installed, the resolves would probably cost so little that nobody would notice, which may be why this hasn't been reported yet.

Possible fixes:

• Cache each manager's version, per manager and per session.
• Record capability telemetry once per manager and capability per session, not on every API call.
• Kill the child process when the telemetry timeout fires.
• Cache negative tool lookups (pipenv, poetry, pyenv not found).

Logs

Excerpt from the "Python Environments" output channel (default log level, paths shortened):

12:38:31.220 [info] Using conda from cache: ~/anaconda3/bin/conda
12:38:31.232 [info] Resolved Python Environment <workspace>/backend/.venv/bin/python
12:38:31.267 [info] Pipenv not found via settings, cache, or PATH
12:38:31.268 [info] Using conda from cache: ~/anaconda3/bin/conda
12:38:31.297 [info] Resolved Python Environment <workspace>/backend/.venv/bin/python
12:38:31.304 [info] Pipenv not found via settings, cache, or PATH
...
12:49:30.205 [info] Resolved Python Environment <workspace>/backend/.venv/bin/python
12:49:30.207 [info] Ran conda in 763: ~/anaconda3/bin/conda --version
12:49:30.208 [info] Ran conda in 899: ~/anaconda3/bin/conda --version
12:49:30.208 [info] Ran conda in 1104: ~/anaconda3/bin/conda --version
12:49:30.339 [info] Resolved Python Environment <workspace>/backend/.venv/bin/python
...
12:38:49.018 [error] Failed to retrieve manager version for capability telemetry: ms-python.python:conda [Error: Manager version lookup timed out.
	at Timeout._onTimeout (~/.vscode/extensions/ms-python.vscode-python-envs-1.43.2026110601-linux-x64/dist/extension.js:2:372250)
	at listOnTimeout (node:internal/timers:685:17)
	at process.processTimers (node:internal/timers:618:7)]

Additional context

Workaround: install 1.40.0 and pin it (code --install-extension ms-python.vscode-python-envs@1.40.0 --force), then quit and restart VS Code completely. "Reload Window" alone kept loading the old version. Switching to the pre-release did not help.