VS Code issues relating to new terminal activation feature

[karrtikr]

This is to track outstanding VS Code bugs so terminal activation feature can stabilize:

• .zshrc is overriding the environment variable set by shell integration on macOS vscode#205102
• Prepending using shell integration does not work for zsh, even when shell integration is activated vscode#205133
• Expose API whether shell integration is working or not vscode#205058
• onDidExecuteTerminalCommand does not fire events for hidden terminal vscode#199611
• Environment collection should not be applied on hidden terminals (non-windows) vscode#197187
  • Provide a way to exempt a terminal from applying any env collections vscode#194819
    • This is not needed if #197187 is solved
  • Resolve Provide a way to exempt a terminal from applying any env collections vscode#194819 (comment)
  • Resolve Environment collection should not be applied on hidden terminals (non-windows) vscode#197187 (comment)
• onDidWriteTerminalData event does not contain shell integration sequences for hidden terminals vscode#204616
• Prepending using shell integration does not work for fish when using starship prompt vscode#208465
• Ensure we use correct workspace folder for remote terminals vscode#180486
  • Multiroot workspaces for remote scenarios does not work currently because of this
• Expose shell integration command knowledge to extensions vscode#145234
• Explore terminal buffer API vscode#207504
  • We would need this to get command output, if microsoft/vscode#145234 doesn't cover it.
• Shell integration isn't enabled for Debug terminals vscode#204694
• Shell integration isn't enabled for Task terminals vscode#205177
• Environment collection replace API strips equals sign at the end vscode#197603

Our follow up action items based on that:

• Adopt to using VS Code API to access terminal output #22128
• If automatic shell integration is failing to activate environment, recommend users to do manual installation #23113
• Enable experiment for multiroot remote scenarios:

  vscode-python/src/client/common/experiments/helpers.ts

  Lines 12 to 17 in 0438813

  	export function inTerminalEnvVarExperiment(experimentService: IExperimentService): boolean {
  	if (!isTestExecution() && env.remoteName && workspace.workspaceFolders && workspace.workspaceFolders.length > 1) {
  	// TODO: Remove this if statement once https://github.com/microsoft/vscode/issues/180486 is fixed.
  	traceInfo('Not enabling terminal env var experiment in multiroot remote workspaces');
  	return false;
  	}

Issue to keep in mind:
PREPEND: #21906

[KayvanShah1]

Recently, after the pylance update and vscode update the Python environment activation feature doesn't activate the environment in the terminal while it shows up on the bottom status bar

[karrtikr]

Kayvan Shah (@KayvanShah1) note Git bash isn't officially supported by the Python extension, which is what you seem to be running into. Can you change the shell using Select default profile command to Command prompt or Powershell?

If that doesn't work, please open a new issue using Python: Report Issue command and we'll be happy to take a look.

[JoelFeiner-viimed]

I'm having this issue with zsh on Linux, pyenv and pipenv. Screenshot:

I downgraded to previous versions and it still doesn't work. I'm at a loss for what the issue is. It simply no longer runs the source ...activate command like it used to. No combination of settings or versions seems to make a difference. I wonder if there is something cached?

Relevant config in settings.json:

        "python.defaultInterpreterPath": "/home/joel/.local/share/virtualenvs/edge-K9fIdVPi/bin/python",
        "python.envFile": "${workspaceFolder}/edge/.env",
        "python.pipenvPath": "/home/joel/.local/share/virtualenvs/edge-K9fIdVPi/bin/pipenv",

[gabethehuman]

I have this annoying issue where VSCode adds stuff to my PS1. In this case I'm using pyenv, but it happens with conda as well.

system is what should be in PS1, the yt part is there only because I selected it in the bottom right corner in the Python extension.

Any chance it's related to any of the issues in the main post?
Similar to JoelFeiner-viimed I tried downgrading the extension or switching to the pre-release version, without any luck.

[karrtikr]

Gabriel Filipek (@gabethehuman) Opened #22882 for you to help out.

[karrtikr]

notes.md

[valhuber]

Critical Regression - VS Code Python Extension Breaking Both Terminal AND Application Execution

This issue represents a critical regression that has broken core Python development functionality. The VS Code Python extension changes have broken both terminal virtual environment activation AND Python application execution.

Background & Fundamental Goal

One of the fundamental goals of modern Python development tooling is to solve the default virtual environment issue for new users. New Python developers are often confused by virtual environments, and tooling should "just work" when a project specifies a virtual environment.

This is why we implemented computed default virtual environments in our ApiLogicServer project generator - to automatically configure the correct virtual environment for users so they don't have to manually figure out activation, paths, and environment management.

The Problem

With VS Code 1.102.0 and recent Python extension versions, python.defaultInterpreterPath correctly sets the interpreter in the UI, but fails to:

1. Activate virtual environments in terminals (no (venv) prompt, wrong Python path)
2. Execute Python applications with the correct environment (apps run with wrong interpreter)
3. Provide seamless experience for new users (defeats the fundamental goal)

Impact on Project Generators & New User Experience

This particularly affects project generators that create workspaces with shared virtual environments to solve the "default venv for new users" problem. Our ApiLogicServer project generator creates projects with:

• Virtual environment at: /Users/val/dev/ApiLogicServer/ApiLogicServer-dev/build_and_test/ApiLogicServer/venv
• Generated workspace setting: "python.defaultInterpreterPath": "/Users/val/dev/ApiLogicServer/ApiLogicServer-dev/build_and_test/ApiLogicServer/venv/bin/python"

The goal: New users run ApiLogicServer create and get a project that "just works" with the correct virtual environment activated automatically.

The reality: Users now get broken projects where nothing works as expected, defeating the entire purpose of computed default virtual environments.

What's Broken

1. Terminal Activation: New terminals don't activate the virtual environment despite python.terminal.activateEnvironment: true
2. Application Execution: Python scripts run with system Python instead of the configured virtual environment
3. Debugging: Debugger uses wrong interpreter environment
4. New User Experience: The "it just works" goal is completely broken

Required Workarounds

We've had to implement extensive workarounds in our project generator, adding complexity that defeats the "simple for new users" goal:

{
  "python.defaultInterpreterPath": "ApiLogicServerPython",
  "python.terminal.activateEnvironment": true,
  "python.terminal.activateEnvInCurrentTerminal": true,
  "python.envFile": "${workspaceFolder}/.env",
  "terminal.integrated.profiles.osx": {
    "venv": {
      "path": "/bin/zsh",
      "args": ["-c", "source ${workspaceFolder}/.vscode/venv_init.sh && exec zsh"]
    }
  },
  "terminal.integrated.defaultProfile.osx": "venv"
}

[eleanorjboyd]

Anthony Kim (@anthonykim1) should this be closed as it is related to the old activation stuff?

[valhuber]

Eleanor Boyd (@eleanorjboyd) Anthony Kim (@anthonykim1)

I am not an internals person, so I do not understand "old/new activation stuff", but I am happy to jump on a call to explain my needs, and explore alternatives.

[anthonykim1]

yeap, closing against: microsoft/vscode-python-environments#962