Python interpreter is lost every time I restart vscode

[iwant2believe]

Type: Bug

I recently switched to python 3.11 and built a new virtual environment, reinstalling everything I previously ran in a 3.9 venv. Everything works except that VSCode does not find the interpreter until I manually drill down to the python3.11 file every time. I have attempted to set the default interpreter in several places but when I shut down and come back I have to reset my interpreter again. I can't tell if it is a bug or simply that I don't understand where or how to tell it to find the correct python, but I have not had to do this running VScode and python 3.6-3.9 for the last 4+ years in this same environment on the same remote servers. The only other major variable is that I added several linters to the best of my understanding based on our company documentation. I am not sure if that can impact it, but I included it in case it can. Here are examples of the error messages I see in the console output when I start up VSCode and it can't find the python interpreter.
2024-08-14 14:53:42.592 [warning] Identifier for virt-virtualenv failed to identify /home/jh/nauto/venv-311/bin/python3.11 [Error: ENOENT: no such file or directory, scandir '/home/jh/nauto/venv-311/bin'] {
errno: -2,
code: 'ENOENT',
syscall: 'scandir',
path: '/home/jh/nauto/venv-311/bin'
}
2024-08-14 14:53:42.594 [warning] Failed to check if /home/jh/nauto/venv-311/bin/python3.11 is an executable [Error: ENOENT: no such file or directory, lstat '/home/jh/nauto/venv-311/bin/python3.11'] {
errno: -2,
code: 'ENOENT',
syscall: 'lstat',
path: '/home/jh/nauto/venv-311/bin/python3.11'
}
2024-08-14 14:53:42.594 [warning] Identifier for virt-virtualenv failed to identify /home/jh/nauto/venv-311/bin/python3.11 [Error: ENOENT: no such file or directory, scandir '/home/jh/nauto/venv-311/bin'] {
errno: -2,
code: 'ENOENT',
syscall: 'scandir',
path: '/home/jh/nauto/venv-311/bin'
}

VS Code version: Code 1.92.1 (eaa41d57266683296de7d118f574d0c2652e1fc4, 2024-08-07T20:16:39.455Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Remote OS version: Linux x64 4.18.0-553.8.1.el8_10.x86_64

System Info

Item	Value
CPUs	12th Gen Intel(R) Core(TM) i7-12800H (20 x 2803)
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 vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	31.69GB (14.78GB free)
Process Argv
Screen Reader	no
VM	0%

Item	Value
Remote	SSH:<server_name>
OS	Linux x64 4.18.0-553.8.1.el8_10.x86_64
CPUs	Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz (12 x 0)
Memory (System)	23.26GB (8.71GB free)
VM	100%

Extensions (13)

Extension	Author (truncated)	Version
vsc-python-indent	Kev	1.18.0
debugpy	ms-	2024.10.0
python	ms-	2024.12.3
vscode-pylance	ms-	2024.8.1
jupyter	ms-	2024.7.0
jupyter-keymap	ms-	1.1.2
jupyter-renderers	ms-	1.0.19
vscode-jupyter-cell-tags	ms-	0.1.9
vscode-jupyter-slideshow	ms-	0.1.6
remote-ssh	ms-	0.113.1
remote-ssh-edit	ms-	0.86.0
remote-explorer	ms-	0.4.3
jinja	who	0.0.8

[anthonykim1]

are you still running into this?

[iwant2believe]

No, I ended up spending time going through settings methodically and I figured out that it didn't seem to like using the full name of the python file with the version, so I used the symlink "python" instead. I was generally incorrectly setting the path as well. I have not had issues since setting the remote server and workspace default interpreter paths. Thank you for checking in, I had forgotten this was posted.