[BUG] VS Code extension sets VIRTUAL_ENV for system Python interpreters, corrupting the environment

Resolved 💬 4 comments Opened Mar 30, 2026 by mpgerlek Closed May 4, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

The Claude Code VS Code extension queries the ms-python.python extension API to get the active Python environment and unconditionally sets VIRTUAL_ENV and prepends to PATH, even when the active interpreter is a system Python (not a virtualenv).

This causes poetry install, pip, and other Python tools to see a bogus VIRTUAL_ENV pointing to a Python framework directory.

What Should Happen?

Reproduction steps

  1. Install ms-python.python extension
  2. Have "python.defaultInterpreterPath": "/opt/homebrew/bin/python3" in VS Code settings (or let it auto-detect a system Python as the active interpreter)
  3. Open a workspace in VS Code
  4. Open Claude Code panel
  5. Run echo $VIRTUAL_ENV

Expected: VIRTUAL_ENV is unset (no virtualenv is active)

Actual: VIRTUAL_ENV=/opt/homebrew/opt/python@3.14/Frameworks/Python.framework/Versions/3.14 (the sysPrefix of the system Python, not a virtualenv path)

PATH also has /opt/homebrew/opt/python@3.14/Frameworks/Python.framework/Versions/3.14/bin prepended.

Root cause

In extension.js, the function that resolves Python environment variables (minified name C46) does this:

let activeEnvPath = pythonAPI.environments.getActiveEnvironmentPath(workspaceFolder.uri);
let resolved = await pythonAPI.environments.resolveEnvironment(activeEnvPath);
let sysPrefix = resolved.executable?.sysPrefix || dirname(dirname(resolved.executable.uri.fsPath));

// Unconditionally sets VIRTUAL_ENV regardless of environment type
env.VIRTUAL_ENV = sysPrefix;
env.PATH = `${join(sysPrefix, "bin")}${delimiter}${existingPATH}`;

The code should check resolved.environment?.type (or similar) and only set VIRTUAL_ENV when the resolved environment is actually a virtual environment (venv, Poetry, conda, etc.), not a system/global Python installation.

Confirmed via process inspection

| Process | Has VIRTUAL_ENV? |
|---|---|
| VS Code main (Electron) | No |
| Extension host (Code Helper Plugin) | No |
| Claude Code binary | Yes -- injected here |
| Shell spawned by Claude Code | Inherited from above |

Workaround

In VS Code, use "Python: Select Interpreter" to select an actual virtualenv (e.g., a Poetry venv) instead of a system Python. The extension will then set VIRTUAL_ENV to the correct venv path.

Environment

  • macOS Darwin 25.4.0 (Apple Silicon)
  • VS Code 1.113.0
  • Claude Code extension 2.1.87
  • ms-python.python 2026.4.0
  • Python: /opt/homebrew/bin/python3 (3.14.0) as default interpreter

Error Messages/Logs

n/a

Steps to Reproduce

see above

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.79 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗