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.