Skip to content

Deactivation may be triggered in restored terminal session where "deactivate" is not defined #1490

@Stasshe

Description

@Stasshe

Environment data

  • Python Environments extension version: latest (reproduced on current main)
  • Python extension (ms-python.python) version: latest
  • VS Code version (Help → About): VS Code Insiders (recent build)
  • OS and version: Windows 11 + WSL2 (Ubuntu)
  • Python version: 3.12 (system)
  • Environment manager in use: venv
  • Shell: zsh (likely shell-agnostic; depends on function-based activation)
  • Remote / container scenario: WSL
  • Workspace type: single folder
  • Is this a regression? Unknown

Screenshot

Image

Repro Steps

  1. Open a WSL workspace in VS Code Insiders.
  2. Ensure persistent terminal sessions are enabled.
  3. Create and activate a virtual environment:
rm -rf .venv
python3 -m venv --without-pip .venv
source .venv/bin/activate
  1. Confirm that the environment is active and that deactivate is defined:
echo $VIRTUAL_ENV
typeset -f deactivate | head
  1. Remove only the shell function while keeping the environment variables:

Note: This step intentionally creates an inconsistent shell state for reproducibility.

unset -f deactivate
echo $VIRTUAL_ENV
typeset -f deactivate | head

At this point:

  • VIRTUAL_ENV is still set
  • deactivate function no longer exists
  1. Close VS Code without killing the terminal.
  2. Reopen VS Code (e.g., from the app icon so that it restores the previous session).

Expected behavior

It should avoid sending deactivate when the shell no longer has it defined.

It should either:

  • verify that the command/function exists before calling it, or
  • skip deactivation when terminal state is uncertain after restore.

Actual behavior

The restored terminal may execute a deactivation command and produce:

zsh: command not found: deactivate

Logs

(No additional logs captured yet — behavior is observable directly in terminal output.)

Additional context

  • This issue does not depend on workspace files or .vscode/settings.json.
  • It can be reproduced in a minimal temporary workspace.
  • It appears related to terminal session restore, not environment creation itself.
  • The issue does not reproduce when opening the same workspace explicitly via CLI (code-insiders ., or code .).
  • The issue does reproduce reliably when VS Code restores a previous window/session (e.g. launching from the app icon).

Relevant code (potentially related):

shellDeactivation.set(ShellConstants.ZSH, [{ executable: 'deactivate' }]);

It appears that a deactivation command may be sent while restoring a terminal with stale shell state.

If this behavior is owned by VS Code core rather than this extension, please let me know and I can move the issue there.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions