Missing brackts around virtual environment name in command prompt

[leo-maxwell]

Type: Bug

Behaviour

When using pyenv-virtualenv to create a virtual environment on macOS, enabling auto activation of virtual environment in terminal option will cause the terminal prompt to have a unbracketed env name in command prompt:

Steps to reproduce:

1. install homebrew
2. install bash using brew and use brew installed bash as default terminal
3. install pyenv as well as its extension pyenv-virtualenv
4. create a new virtual environment using pyenv virtualenv with latest python version (3.13+)
5. select this env as intepreter and enable the option described above

Diagnostic data

launch.json configuration

XXX

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

Output for Python Debugger in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python Debugger)

XXX

# Behaviour

XXX

Steps to reproduce:

1. XXX

Diagnostic data

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

Extension version: 2025.2.0
VS Code version: Code 1.98.2 (Universal) (ddc367ed5c8936efe395cffeec279b04ffd7db78, 2025-03-12T13:32:45.399Z)
OS version: Darwin arm64 24.3.0
Modes:

• Python version (& distribution if applicable, e.g. Anaconda): 3.13.2
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Pyenv
• Value of the python.languageServer setting: Default

User Settings

languageServer: "Pylance"

Installed Extensions

Extension Name	Extension Id	Version
cmake	twx	0.0.17
cmake-tools	ms-	1.20.53
cpptools	ms-	1.23.6
cpptools-extension-pack	ms-	1.3.1
cpptools-themes	ms-	2.0.0
datawrangler	ms-	1.20.1
debugpy	ms-	2025.4.1
gnuplot	mam	1.0.5
isort	ms-	2023.10.1
js-debug	ms-	1.97.1
js-debug-companion	ms-	1.1.3
jupyter	ms-	2025.2.0
jupyter-keymap	ms-	1.1.2
jupyter-renderers	ms-	1.1.0
makefile-tools	ms-	0.12.17
markdown-all-in-one	yzh	3.6.3
markdown-preview-enhanced	shd	0.8.18
material-theme	zhu	3.19.0
mesonbuild	mes	1.27.0
ninja	sur	0.0.1
pdf	tom	1.2.2
powershell	ms-	2025.0.0
python	ms-	2025.2.0
rainbow-csv	mec	3.18.0
remote-containers	ms-	0.401.0
rust-analyzer	rus	0.3.2345
vscode-css-peek	pra	4.4.3
vscode-docker	ms-	1.29.4
vscode-github-actions	git	0.27.1
vscode-html-css	ecm	2.0.13
vscode-js-profile-table	ms-	1.0.10
vscode-jupyter-cell-tags	ms-	0.1.9
vscode-jupyter-slideshow	ms-	0.1.6
vscode-language-pack-zh-hans	MS-	1.98.2025031209
vscode-nand2tetris-hdl	rob	0.1.1
vscode-pylance	ms-	2025.3.2
vscode-xml	red	0.28.0

System Info

Item	Value
CPUs	Apple M1 Max (10 x 2400)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	3, 3, 3
Memory (System)	64.00GB (1.21GB free)
Process Argv	--crash-reporter-id df70c873-806d-4434-a20c-c67603f06b4c
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vscod805cf:30301675
binariesv615:30325510
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
2e7ec940:31000449
pythontbext0:30879054
cppperfnew:31000557
dwnewjupyter:31046869
nativerepl1:31139838
pythonrstrctxt:31112756
nativeloc1:31192215
iacca1:31171482
5fd0e150:31155592
dwcopilot:31170013
6074i472:31201624
dwoutputs:31242946
customenabled:31248079
9064b325:31222308
copilot_t_ci:31222730
968h8231:31262364
jda6j935:31233686
pythoneinst12cf:31262606
bgcontrol:31262794
fh1c7952:31258891
6h6a5794:31261449
31787653:31262186

[leo-maxwell]

Update: the virtual environment is also not activated inside the terminal, if execute which python3, it does not show the correct interpreter. However, interestingly, trying to execute pyenv activate envname will suggest that this env is already activated.

[anthonykim1]

are you using terminal env var experiment? Try adding
"python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"] into your settings.json

[leo-maxwell]

Thank you for your advice, but it did not work. I spent some time in the source code and eventually, I found these lines:

function getPromptName(interpreter: PythonEnvironment) {
    if (interpreter.envName) {
        return `"(${interpreter.envName})"`;
    }
    if (interpreter.envPath) {
        return `"(${path.basename(interpreter.envPath)})"`;
    }
    return 'environment indicator';
}

in indicatorPrompt.ts, and I think my case is caused by such lines because now the env indicator is exactly the same as the basename of the path of the interpreter. Also, I found that such bug does not occur in earlier Python versions(3.11 tested) managed by pyenv. I don't know much about TypeScript, and I am just guessing those lines are relevant.

[anthonykim1]

@leo-maxwell Did "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"] effectively disable your auto-activation?

aka. Do you see explicit source... activate command on your terminal as the first thing when you launch a terminal?

It may be helpful to see wholistic screenshot of your terminal, just to make sure we see the expected source...activate command as the first thing to pop up in your terminal when you create one.

The mentioned code is only relevant for when you are opted-into the terminal env var experiment:
Ref:

vscode-python/src/client/terminals/envCollectionActivation/indicatorPrompt.ts

Lines 46 to 47 in 18efcd6

	if (!inTerminalEnvVarExperiment(this.experimentService) || useEnvExtension()) {
	return;

[Agalin]

I've encountered the same issue in poetry with new virtual environments. Extension seems to read VIRTUAL_ENV_PROMPT from the activate script while brackets are added directly in the PS1 overwrite call. With opt-out it works fine. Changing the prompt variable in the script and refreshing env cache (change interpreter -> restart extension host -> change back) gets the updated prompt value.

Tried downgrading the extension quite far back (2024.16.0) and it didn't change anything so maybe it's the activation script that has changed? I believe it was fine in the past in the terminal env var activation mode although I lack any old venvs right now to confirm.

[Agalin]

I think I've found it. Difference in behaviour matches this change in the venv implementation. In the past brackets and the whitespace were added to the main prompt variable but now they're only added to the prompt itself.

Looks like it was released with Python 3.13.0.

[leo-maxwell]

@leo-maxwell Did "python.experiments.optOutFrom": ["pythonTerminalEnvVarActivation"] effectively disable your auto-activation?

aka. Do you see explicit source... activate command on your terminal as the first thing when you launch a terminal?

It may be helpful to see wholistic screenshot of your terminal, just to make sure we see the expected source...activate command as the first thing to pop up in your terminal when you create one.

The mentioned code is only relevant for when you are opted-into the terminal env var experiment: Ref:

vscode-python/src/client/terminals/envCollectionActivation/indicatorPrompt.ts

Lines 46 to 47 in 18efcd6

if (!inTerminalEnvVarExperiment(this.experimentService) || useEnvExtension()) {
return;

Yes, I did see the command pyenv shell envname as the first thing in integrated terminal when Python project folder is opened. After that, though the envname does not appear anywhere in the shell prompt, the environment is indeed activated and everything works. Somehow I think it is better than seeing a broken, unbracketed envname in prompt.

[leo-maxwell]

I think I've found it. Difference in behaviour matches this change in the venv implementation. In the past brackets and the whitespace were added to the main prompt variable but now they're only added to the prompt itself.

Looks like it was released with Python 3.13.0.

Thank you! You must have made this issue much easier for developers to fix.

[github-actions]

Hey @anthonykim1, this issue might need further attention.

@leo-maxwell, you can help us out by closing this issue if the problem no longer exists, or adding more information.