[BUG] vscode extension incorrectly prepends /usr/bin to PATH

Status Fixed / completed
Reported on v2.1.87
Maintainer reply None cached
Activity 3 comments · opened Jun 3, 2026 · closed Jun 4, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet (except once where it was closed as stale)
  • [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?

Summary

When claudeCode.usePythonEnvironment is enabled (the default), the VS Code extension detects the system Python prefix (/usr) as a virtual environment and sets VIRTUAL_ENV=/usr, which prepends /usr/bin to PATH. This changes the PATH ordering for all tool/bash calls within Claude Code sessions.

This happens in projects that have nothing to do with Python and are unaware of this setting, leading to subtle hard-to-diagnose issues which don't reproduce in the user's terminal (or in terminal claude sessions) due to incorrect binary selection (since newer versions are conventionally installed in locations like /usr/local/bin).

Actual behavior

The extension's Python environment activation logic sets:

VIRTUAL_ENV=/usr
PATH=/usr/bin:$PATH

This causes /usr/bin to appear first in PATH, ahead of /usr/local/bin and any other user-configured entries.

Root cause

In extension.js, the usePythonEnvironment feature (enabled by default) calls into Python environment detection. When no virtual environment is found, it falls back to the system Python, whose sys.prefix is /usr. The venv activation logic then does path.join(VIRTUAL_ENV, "bin") → /usr/bin and prepends it to PATH.

This only affects session launches (not the initial auth status call, which uses a different code path).

Impact

  • Programs installed in /usr/local/bin may be shadowed by /usr/bin versions
  • Breaks user expectations about PATH ordering, especially for users who install newer tool versions to /usr/local/bin
  • Does not occur when launching claude from the CLI directly

What Should Happen?

PATH ordering should match the user's login shell. On a typical Ubuntu system with /etc/environment setting PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:..., the user expects /usr/local/bin to come before /usr/bin.

Error Messages/Logs

Steps to Reproduce

  1. Open a project in VS Code that has no Python virtual environment (no .venv, no venv, no conda env)
  2. System Python's sys.prefix is /usr (standard on Debian/Ubuntu)
  3. Start a Claude Code session via the VS Code extension
  4. Run echo $PATH in a Claude bash tool call
  5. Observe /usr/bin is prepended to PATH

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.87 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Workaround

Add to .vscode/settings.json:

{
    "claudeCode.usePythonEnvironment": false
}

Environment

  • Claude Code extension v2.1.87
  • VS Code on Linux (Ubuntu)
  • No Python virtual environment in project
  • System Python at /usr/bin/python3 with sys.prefix = /usr

---

_Refiling #41081, which was closed as stale. The bug still reproduces on the latest version._

_See also #56047, of which this is an identical copy._

View original on GitHub ↗

3 Comments

github-actions[bot] · 4 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/41081
  2. https://github.com/anthropics/claude-code/issues/56047

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

rssprivacy-commits · 4 months ago

Adding a macOS data point and a downstream symptom that this claudeCode.usePythonEnvironment behavior triggers but isn't captured above.

macOS manifestation — With no interpreter explicitly selected, the resolved interpreter is the Apple Command Line Tools Python (/usr/bin/python3), whose sysPrefix is the framework dir. The extension exports:

VIRTUAL_ENV=/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9
PATH=/Library/Developer/CommandLineTools/.../3.9/bin:$PATH

Decompiled extension.js (gated by claudeCode.usePythonEnvironment, default true) confirms the mechanism — it calls getExtension("ms-python.python").exports.environments.getActiveEnvironmentPath → resolveEnvironment, then unconditionally:

x = K.executable?.sysPrefix || dirname(dirname(K.executable.uri.fsPath));
Z.VIRTUAL_ENV = x;
Z.PATH = `${x}/bin${delimiter}${Z.PATH || process.env.PATH || ""}`;   // no venv/conda kind check

Downstream symptom (visible to users) — Because a VIRTUAL_ENV is now present, the ms-python.vscode-python-envs (Python Environments, preview) extension — which ships inside ms-python.python's extensionPack — pops "VIRTUAL_ENV is set for this VS Code session. Selection saved for new terminals only" and also throws a transient Cannot read properties of undefined error toast every time a Claude Code tab is opened. So the impact isn't only PATH ordering; the synthesized VIRTUAL_ENV actively drives another bundled extension's prompt + crash. (Uninstalling ms-python.vscode-python-envs removes the visible toasts but not the root VIRTUAL_ENV/PATH behavior reported here.)

Repro env — Claude Code extension v2.1.162, VS Code 1.121.x, macOS (Apple Silicon).

Same fix as OP — only set VIRTUAL_ENV when the resolved environment is actually a virtual/conda env (gate on environment kind), or use the Python extension's official activation variables for global/system interpreters rather than synthesizing VIRTUAL_ENV from sysPrefix.

github-actions[bot] · 2 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.