How do I get out of a venv in VSCODE?

Question

I made a venv in vscode using python shell to try it out and accidentally deleted all the venv files before deactivating the venv. Now I can't deactivate it.

Again, the og files are GONE.

I've done some research and simply typing "deactivate" didn't even work the first time. Exiting the shell doesn't work. Clearing caches doesn't work. Uninstalling and reintstalling vscode doesn't work. Every time I open the program im in a venv.

Someone please help, I'm at my wits end.

I've also tried sudo commands. The only thing I haven't tried is commands from my OS cmd prompt. Frankly Im too scared I'll mess something up in there if I am just going around deactivating stuff.

Answer 1

Have you tried changing your Python interpreter? In the bottom right of the window, just to the left of the notifications bell, you have the version of your Python interpreter and if it's in a venv/conda virtual environment. If you click on it you will bring up the list of Python interpreters that are currently installed on your computer. Now, click on the 64-bit python.exe (the global one). This should get you out of the venv.

Answer 2

Accidentally deleted the virtual environment folder before deactivating it properly in VS Code. Since the files are gone, VS Code still thinks the environment is active even though it no longer exists. Here are a few things you can try to reset it:

1. Close VS Code entirely and reopen it. This sometimes resets the cached virtual env.
2. Delete the .vscode folder in your project directory. This contains VS Code config files that may still reference the deleted venv.
3. Open a terminal/command prompt outside of VS Code and run deactivate. This deactivates any active virtual envs in that shell session.
4. Lookup where VS Code keeps its global virtual env settings and delete any references to the deleted venv there. For example, on Linux it's in ~/.config/Code/User/settings.json.
5. Use shortcuts "ctrl+shift+P" and type "Python: Clear Workspace Interpreter Settings" AND "Python: Select Interpreter" to change the environment. As a last resort, uninstall and reinstall VS Code. This will reset all its settings.

The key is fully closing VS Code and clearing any cached/config files that still think the venv exists. Doing this should allow VS Code to pick up that the virtual environment is gone and reset itself.

If these steps don't work then Deleting the VS Code cache/config files can potentially help resolve these issues.

1. The .vscode folder in your project directory. This contains workspace/project specific settings and cache for VS Code.
2. The global VS Code config folders, which are located here:

• Windows: %APPDATA%\Code\User
• Mac: ~/Library/Application Support/Code/User
• Linux: ~/.config/Code/User

Deleting these folders will remove any cached/configured settings related to the virtual environment that no longer exists. It will reset VS Code's state and should allow it to detect that the virtualenv is gone.

Answer 3

I had a problem similar to this, only in my case it was attempting to activate a venv and was just hanging. I discovered that several crashes left behind orphaned bash sessions. As a result, VS Code was attempting to activate using /bin/bash - an old bash version (the one built in to Mac, Bash 3, which is a whole other thing that's outside the scope of this convo).

My solution

First, I completely quit VS Code.

Then, in a terminal window, I listed the sessions:

$ ps -aef | grep bash
  504 39690     1   0  1:42PM ttys007    5:16.07 /bin/bash --init-file /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
  504 41070 41069   0  1:45PM ttys008    0:00.61 -bash
  504 41681 41070   0  1:48PM ttys008    0:00.01 grep bash
  504 37841     1   0  1:36PM ttys011   11:34.55 /bin/bash --init-file /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
  504 38136     1   0  1:36PM ttys013   11:14.87 /bin/bash --init-file /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
  504 38446     1   0  1:37PM ttys015   10:24.80 /bin/bash --init-file /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh
  504 38776     1   0  1:38PM ttys017    8:56.99 /bin/bash --init-file /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh

(I'm on a Mac so I used ps -aef, but you may need different flags for different flavors of UNIX...IIRC, -aux may work if -aef doesn't.)

Then I ran tty to see which of the sessions I didn't want to kill (it was pretty obvious, but just in case....)

$ tty
/dev/ttys008

And then I kill -9-ed the zombie sessions left behind by previous VS Code executions:

$ kill -9 39690 37841 38136 38446 38776

I ran another ps command just to make sure there were no lingering sessions, then restarted VS Code.

After starting VS Code again, I noticed that a ps -aef command brought up another instantiation of the app but this time, instead of /bin/bash (the BSD one), it was using /usr/local/bin/bash, which is GNU Bash...the correct one.