Code Runner runs Python before your venv in VS Code: align the interpreter and stop ModuleNotFoundError

Python fails first run in VS Code with Code Runner because venv activates after execution. Set executorMap to use VS Code's interpreter for consistent runs.

After a recent VS Code update, some developers noticed that running Python files via the Code Runner extension executes the system interpreter first and only then activates the virtual environment. The first run fails with missing modules, the second run succeeds because the venv gets activated afterward. This isn’t a VS Code bug; it’s a misconfiguration and a launch-order mismatch between VS Code and Code Runner.

Reproducing the symptom

Consider a simple file that relies on packages installed inside a virtual environment:

from flask import Flask
print("File Executed")

When executed through Code Runner, the terminal shows the Python process starting before the virtual environment is activated. The result is an import error, followed by a late activation, and only then a successful re-run:

python -u "/home/user/project/panel/__init__.py"
ModuleNotFoundError: No module named 'flask'
source /home/user/project/.venv/bin/activate.fish
python -u "/home/user/project/panel/__init__.py"
File Executed

If Code Runner is disabled and you use VS Code’s built-in run behavior, the order is different: the activation command runs first, and then the Python interpreter from the virtual environment runs the script:

source /home/user/project/.venv/bin/activate.fish
/home/user/project/.venv/bin/python "/home/user/project/panel/__init__.py"

What’s actually happening

Code Runner starts the Python process immediately, so the command uses the global interpreter. VS Code’s terminal then activates the venv afterward, which is too late for the command that has already executed. Disabling Code Runner restores the expected order in which the activation happens before execution. The behavior has been discussed in Code Runner’s issue tracker and tied to how the extension resolves the Python command.

Fixing the misconfiguration

The solution is to make Code Runner use the same interpreter that VS Code has selected for the workspace. Update the executor map so the Python command uses the interpreter path provided by VS Code:

"code-runner.executorMap": {
  "python": "$pythonPath -u $fullFileName"
}

Alternatively, you can point Code Runner directly to the Python binary inside your venv:

"code-runner.executorMap": {
  "python": "/home/user/project/.venv/bin/python -u $fullFileName"
}

With either variant, Code Runner will launch the correct interpreter up front, so the script runs with the intended environment and the import error disappears.

Why this matters for your workflow

Environment drift is a subtle source of failures, especially when your dependencies live inside a venv. If your runner invokes the wrong interpreter, you get inconsistent results: missing packages on first run, confusing success on subsequent attempts, and non-reproducible behavior across shells like fish or bash. Aligning Code Runner with VS Code’s interpreter selection removes that mismatch and keeps execution predictable.

Practical takeaways

Ensure that the tool invoking Python is the same one providing the interpreter path. If you rely on Code Runner for a universal “run” shortcut across languages, configure its Python executor to use $pythonPath or pin it to your project’s venv Python. If you prefer the default behavior without the extension, VS Code already activates the venv before running your file. In both cases, the goal is the same: the process must start under the correct interpreter so your modules resolve as expected.

Set the executor map once, and your runs will be consistent again—no extra keystrokes, no second-run surprises.