Python env auto-activation regression: Terminal no longer activates unless legacy settings are enabled

[JVSCHANDRADITHYA]

Environment

• VS Code version: your version

• Python extension version: your version

• OS: Windows 10/11

• Shells tested:

  • PowerShell
  • CMD
  • Git Bash

---

Summary

After recent Python extension updates (last ~4–5 months), Python environment auto-activation no longer works in Terminals unless the Python Extension settings are explicitly enabled, despite extension stating they are overridden by the new python.envs.terminal.autoActivationType setting.

This is a regression. Behavior was previously consistent.

---

Actual Behavior

Case 1 — Python Extension settings disabled

python.terminal.activateEnvironment = false
python.terminal.activateEnvInCurrentTerminal = false
python.envs.terminal.autoActivationType = "command" // even shell startup does the same

Opening a CMD terminal results in:

F:\Project>

• No environment name
• No activation commands run
• Running a Python file uses the wrong environment, causing import failures

Expected: Environment auto-activates
Actual: No activation occurs at all

---

Case 2 — Python Extension settings enabled

python.terminal.activateEnvironment = true
python.terminal.activateEnvInCurrentTerminal = true
python.envs.terminal.autoActivationType = "command"

• CMD terminal now auto-activates
• Activation is delayed because commands are queued
• Running Python before activation results in errors
• Activation happens only after the script fails

Activation technically occurs, but it is unreliable.

---

Expected Behavior

Documentation states:

python.envs.terminal.autoActivationType takes precedence over (Python Extension) settings.

Therefore:

• Auto-activation should work even if legacy settings are disabled
• Activation should occur before Python execution, not after

---

Why This Is a Problem

• Shells cannot auto-activate unless deprecated settings are re-enabled
• Scripts run with the wrong interpreter when activation is delayed
• Legacy settings still control activation despite being marked deprecated
• shellStartup mode does not activate CMD at all
• command mode activates too late (after execution begins)

This combination makes CMD activation effectively broken.

---

Reproduction Steps

1. Disable both legacy settings:

python.terminal.activateEnvironment = false
python.terminal.activateEnvInCurrentTerminal = false

2. Set:

python.envs.terminal.autoActivationType = "command"

3. Open a CMD/PWSH terminal in VS Code
4. Observe that the environment does not activate
5. Run a Python file
6. Script fails due to the wrong interpreter
7. CMD activates the environment only after the failure

---

Notes

• PowerShell auto-activation fails
• CMD behavior has changed recently; it previously worked reliably (CMD Neither works after legacy in case of shellStartup, but that's for another issue)
• This issue is not related to conda; it also occurs with venv
• The problem appears specific to VS Code’s Python extension activation logic
• Many Windows developers depend on CMD for tooling and workflows

---

Request

Please restore the original behavior:

• python.envs.terminal.autoActivationType should be authoritative
• Legacy settings should not be required for activation
• CMD activation should occur immediately, not after script execution
• CMD should be fully supported under both shellStartup and command activation modes

Logs can be provided if needed.

---

[eleanorjboyd]

will investigate thank you!

[anthonykim1]

cmd auto activation should work again if you set autoActivationType to shellStartup. #1000 There was a recent regression that was resolved in latest insiders. Insiders build

Its weird to me that activation command doesnt show up when you have autoActivationType to command though.
This makes me wonder if correct venv is selected from env extension, and correct activation commands are selected in the first place.

Auto-activation comes after that.

[JVSCHANDRADITHYA]

Thanks for the update and for pointing to the insiders fix.

To clarify a few points from my side:

shellStartup + CMD
On my setup, even with this..

python.envs.terminal.autoActivationType = "shellStartup"

CMD still does not auto-activate, while PowerShell does. If this is fixed in the latest Insiders build, I will verify again there and report back.

command mode not triggering activation at all
With:

python.terminal.activateEnvironment = false
python.terminal.activateEnvInCurrentTerminal = false
python.envs.terminal.autoActivationType = "command"

no activation command runs at all (no delayed activation either). This suggests the legacy flags are still acting as a gating condition for activation, even though documentation states the new envs activation service should take precedence.

Environment selection
The correct environment is selected in the Python Environments UI, and the expected activation command is correct once the legacy flags are re-enabled. Auto-activation only breaks when those two legacy settings are set to false.

I will test again on the latest Insiders build to check whether:

shellStartup now works correctly for CMD

command mode works without requiring the legacy flags

and will update with results.

[anthonykim1]

@JVSCHANDRADITHYA Thanks for the response.
You also need pre-release of Python environment extension, latest along with latest vscode insiders.

[JVSCHANDRADITHYA]

Thanks for the update. I’ll install the latest VS Code Insiders along with the prerelease Python Environments extension and retest the activation behavior there.

To keep this issue focused, the two problems I’m observing on stable builds are:

• Auto-activation only works if the legacy Python extension settings are enabled, even though autoActivationType is supposed to replace them.
• CMD does not auto-activate in shellStartup mode, despite being listed as a supported shell.

I’ll verify both behaviors again in Insiders.
Also, I’m interested in contributing to fixing this once I confirm the current state. Let me know if there’s any specific area of the activation service I should start looking into.

[JVSCHANDRADITHYA]

@eleanorjboyd @anthonykim1 I tested this on VS Code Insiders with the prerelease Python Environments extension, and shellStartup auto-activation is working correctly now. I’ve attached a screenshot for reference.

I wasn’t very attentive to which extension originally handled environment activation in the past, but I believe it was Don Jayamanne’s earlier work before it was deprecated (Is it ?). Has that functionality been fully migrated into the new Python Environments extension now, especially for activation flow? Just trying to understand the history here as I'm learning how the current system is structured.

I’d also be interested in contributing to this area once I understand more about the new activation pipeline. Let me know if there’s any specific code path or component I should start looking into.