Auto-activation forces a single environment across an entire multi-project workspace root, injecting activate commands into unrelated terminals

[silenThunderr]

Summary

python-envs.terminal.autoActivationType (default "command") auto-injects a source .../activate command into every new integrated terminal, based on a single environment resolved for the entire workspace root — even when that root folder contains many independent subprojects, each with its own .venv, and the new terminal's cwd is a different subproject than the one whose environment got selected.

Repro

1. Open a folder (e.g. ~/AILab) that is not itself a Python project, but contains several subfolders that each are (e.g. AILab/ProjectA/.venv, AILab/ProjectB/.venv, AILab/ProjectC/.venv).
2. Work in ProjectA for a while (open files, run terminals) — the extension resolves/selects ProjectA/.venv as "the" environment for the workspace root AILab (log: Changed environment from undefined to .venv (...) for: /Users/silent/AILab).
3. Open a brand new integrated terminal cwd'd in ProjectC (a completely unrelated subproject with its own .venv).
4. Observed: the terminal automatically runs source AILab/ProjectA/.venv/bin/activate — activating the wrong project's environment — without the user typing anything. The extension log shows this is driven by workspaceSearchPaths (default [".venv", "*/.venv"]) resolving one environment for the whole root rather than scoping per-subfolder/per-terminal-cwd.

Example from my logs:

2026-07-11 19:29:06.742 [info] Python API: Changed environment from undefined to .venv (3.12.13.final.0) for: /Users/silent/AILab
2026-07-11 19:29:11.749 [error] Shell execution timed out:  source /Users/silent/AILab/Medical_Agent/.venv/bin/activate
2026-07-11 19:29:11.749 [info] Terminal is activated: /Users/silent/AILab/Medical_Agent/.venv/bin/python

This also repeatedly logs Shell execution timed out, suggesting the injection itself is unreliable/retried.

Impact

• Wrong environment silently activated in terminals for unrelated subprojects — confusing at best (mismatched dependencies, wrong Python version) and could cause real harm if a script in one project runs against another project's environment/dependencies.
• Because this fires for every integrated terminal regardless of the extension/tool that opened it, it also leaks into third-party terminal-integration extensions (e.g. Claude Code's integrated terminal panels), where the injected activation line was mistaken for injected/leaked chat input since it appears in the terminal buffer unprompted.
• The setting is scope: "machine", so it cannot be scoped per-workspace-folder to opt individual multi-project roots out — the only escape is fully disabling auto-activation ("off") machine-wide, losing the feature everywhere, even in genuine single-project workspaces where it'd be wanted.

Expected behavior

• Auto-activation should be scoped to the environment resolved for the specific terminal's cwd / the specific subfolder project, not a single environment resolved for the entire (possibly multi-project) workspace root.
• Alternatively, workspaceSearchPaths/environment resolution should not silently pick one .venv out of several sibling */.venv matches to represent an entire root folder that isn't itself a Python project.
• autoActivationType should ideally support workspace-folder scope, not just machine, so it can be disabled for specific multi-project roots without losing it elsewhere.

Environment

• ms-python.vscode-python-envs v1.36.0 (darwin-arm64)
• VS Code, macOS
• Workspace: single large folder containing multiple independent Python subprojects, each with their own .venv