How to Fix VSCode Invalid Interpreter in WSL Ubuntu after Python 3.13: Restore Python 3.12 Virtual Environments, pip, and Pylance

Fix WSL Ubuntu after Python 3.13: resolve VSCode invalid interpreter, Pylance errors, and missing pip by recreating 3.12 venvs and selecting interpreter.

Working in WSL Ubuntu after installing Python 3.13 can unexpectedly break existing virtual environments created with Python 3.12. VSCode starts reporting an invalid interpreter, Pylance stops resolving imports, and pip seems to vanish even though it sits right there in the virtual environment’s bin directory. Below is a concise walkthrough of what’s happening and how to bring your workspace back to a consistent state.

Problem

In VSCode, the interpreter selection suddenly becomes invalid, and every import is flagged as unresolved. The editor shows a warning:

An Invalid Python interpreter is selected, please try changing it to enable features such as IntelliSense, linting, and debugging. See output for more details regarding why the interpreter is invalid.

Activating the environment still works in the shell, but installing or using packages fails with:

ModuleNotFoundError: No module named 'pip'

System ensurepip behaves inconsistently across versions in Ubuntu, and pip inside the environment appears present but isn’t used correctly by the tools.

Code example that reproduces the issue

Below is a minimal sequence that mirrors the scenario in WSL after Python 3.13 lands:

source env_py/bin/activate
python3 --version
which python3
python3 -m ensurepip
python3.12 -m ensurepip
python3.12 -m pip --version
python3.12 -m pip install --upgrade pip

The shell can activate the environment, yet the editor keeps failing to resolve imports and flags the interpreter as invalid.

What’s going on

After Python 3.13 is installed, the system-wide python3 often points to 3.13. A virtual environment created earlier with Python 3.12 still records its home interpreter internally, but tooling in VSCode can end up invoking python3, not the environment’s exact binary. That mismatch breaks IntelliSense, linting, and import resolution. It can also affect how the pip script in the virtual environment is executed if its shebang references the generic python3 shim that now maps to 3.13.

Ubuntu’s packaging adds a wrinkle: ensurepip is intentionally disabled for the system Python, so trying to bootstrap pip via python3.12 -m ensurepip produces a notice about being disabled, while pip itself still works when invoked via python3.12 -m pip.

Solution

Start by confirming what python3 resolves to and where it lives. This establishes whether your default interpreter changed to 3.13.

python3 --version
which python3

Inspect the virtual environment configuration to see which interpreter it expects. Inside the environment directory, check the interpreter path referenced by the environment:

cat env_py/pyvenv.cfg

You should see an entry similar to:

home = /usr/bin/python3.12

In VSCode, explicitly select the environment’s interpreter. Open the command palette and choose Python: Select Interpreter, then point to the concrete binary inside the environment, not the system shim:

/path/to/env_py/bin/python

Verify the pip launcher inside the environment to ensure it isn’t tied to the generic python3 shebang. If the first line points to the system alias, the environment will be inconsistent after the upgrade:

head -n 1 env_py/bin/pip

If the environment is out of sync, rebuild it with the intended interpreter and refresh dependencies while keeping the same Python 3.12 base:

python3.12 -m venv --upgrade-deps env_py

If that does not settle things cleanly, recreate the environment from scratch and reinstall packages:

rm -rf env_py
python3.12 -m venv env_py
source env_py/bin/activate
pip install -r requirements.txt

On Ubuntu, having the correct packages for venv and distutils for Python 3.12 is expected. Install them if they are missing:

sudo apt install python3.12-venv python3.12-distutils

With the environment rebuilt and the interpreter path explicitly selected in VSCode, features like IntelliSense, linting, and imports work as before.

When the editor keeps switching back

There are setups where the editor reverts to python3.13 even after manually choosing 3.12. In such a case, recreating the environment and reinstalling dependencies resolved the issue for that workflow.

Why this matters

WSL and Ubuntu make it convenient to run multiple Python versions, but editor integrations and shebangs are sensitive to the default system alias. When python3 advances to 3.13, legacy virtual environments that assume 3.12 can silently drift. That drift surfaces as invalid interpreters, broken import resolution, and pip that seems present but doesn’t behave in the editor.

Summary and practical advice

After installing a new system Python, always verify what python3 points to and what your virtual environment records in pyvenv.cfg. In VSCode, select the environment’s concrete interpreter binary, not the system alias. If pip’s launcher inside the environment references the generic python3 shim, rebuild the environment with the intended version. When in doubt or if the editor keeps snapping back to the newer system interpreter, remove the environment, recreate it with python3.12, and reinstall requirements. Keeping python3.12-venv and python3.12-distutils installed ensures venv creation behaves as expected on Ubuntu. This small checklist prevents ambiguous interpreter resolution and keeps your WSL development environment predictable after version bumps.