Skip to main content

Many Processes, Many Interpreters (Why VS Code Shows Different Python Versions)

Modern Python tooling doesn’t run on “one Python.” Instead, different parts of your development environment may be running different Python interpreters concurrently, each with its own purpose.

This is why you may see:

  • One version in poetry env info
  • A different version in the VS Code status bar
  • Another version running the language server
  • Yet another version building wheels, linting, formatting, or running tests

All of these are normal — because each subsystem invokes Python independently.

1. Your project interpreter​

This is the Python interpreter located in your virtual environment:

./.venv/bin/python   →   Python 3.x

This interpreter is used for:

  • Running your code
  • Executing scripts inside the venv
  • Tools installed inside the venv (pytest, ruff, black, mypy, etc.)
  • Poetry’s isolated runtime
  • VS Code intellisense (eventually…)

This is the one you care about for correctness.

2. The global interpreter​

When VS Code starts, it boots using whichever Python is first in your PATH. This might be:

/usr/bin/python3.10

This interpreter may be used for:

  • Bootstrapping VS Code’s Python extension
  • Running the Pylance language server (initially)
  • Running extension host utilities
  • Providing Python paths before a venv is selected

VS Code launching with a global Python does not affect your project unless the extension fails to switch over properly.

3. The language server interpreter​

VS Code’s Python tooling (Pylance, the Python extension) is itself a program that needs a Python executable to operate.

The language server:

  • Starts before you select an interpreter
  • Often stays bound to the Python it started with
  • Sometimes fails to restart automatically when selecting a new interpreter
  • May display its own Python version in the bottom status bar (misleading)

This is why the status bar can show something like:

Python 3.10.19 (qlir-py3.13)

even though your actual venv is Python 3.13.7.

4. Tools that may use their own Python processes​

Some tools don’t use your venv Python at all unless configured:

Ruff​

Runs as a separate Rust binary → doesn’t care about Python versions.

Mypy​

May spawn its own Python interpreter based on your configuration.

Pytest​

Runs under the selected interpreter, but discovery may use the global one.

Poetry​

Uses your system Python + its own internal environment to manage deps.

Debug Adapter​

VS Code’s debugger uses the interpreter you select, but its own internal processes may still run under a global Python.

5. The result: many interpreters simultaneously​

At any moment, you may have processes running under:

  • ./.venv/bin/python (the actual project)
  • /usr/bin/python3.10 (global)
  • An internal Poetry Python (python3.13)
  • VS Code’s extension host Python
  • The Python fork used for building wheels
  • The Python used by testing or linting tools

This is completely normal.