Support remote server being treated like a 'local' server when on same machine as VS code extension host

Current Working Directory is not the current notebook directory.

This goes against default behaviour in jupyter notebook and jupyter lab.

Can this be fixed? If not, how can I automate setting the current work directory to the file location? Is there some environment variable that is set to the current notebook file that I can read in a setup cell?

Environment data

• VS Code version: 1.61.1
• Jupyter Extension version (available under the Extensions sidebar): v2021.9.1101343141
• Python Extension version (available under the Extensions sidebar): v2021.10.1336267007
• OS (Windows | Mac | Linux distro) and version: Windows 21H1
• Python and/or Anaconda version: 3.9
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): conda
• Jupyter server running: Remote

Expected behaviour

from pathlib import Path; Path.cwd() returns the directory where the current notebook is.

Actual behaviour

The directory where the jupyter remote server was started is returned.

Steps to reproduce:

1. Externally, start jupyter server at ~
2. Create folder at ~/a
3. Create folder at ~/a/b
4. With vscode remote ssh, open ~/a.
5. Run vscode command to create notebook at ~/a/b/c.ipynb
6. In the notebook, run from pathlib import Path; Path.cwd()

[TTTPOB]

is there a reason you want the remote server there? Maybe sharing with other people that don’t use VS code?

for me there is just one reason: remote sessions won’t be closed when i close vscode

a job lasting for days is common for me, I can’t keep my laptop connected to the server for like a few days

[lasergyro]

Regarding getting the server start path: the dummy kernel would work; presumably if vscode sees the kernel file via remote ssh in the same place, then it can assume it is the same machine.

The server is remote because it places the code closer to the data. There’s a few reasons for not wanting to manage jupyter with vscode. Having the lifecycle of VScode tied to Jupyter makes it harder to debug issues that show up in one of them ( jupyter crashes / vscode crashes / vscode ui issues ). I am not even at 50% usage of vscode-jupyter due other issues, and that’s another reason to not want vscode managing it, I often jump back to jupyterlab. I often leave the jupyter server running while I have closed vscode, either finishing some computation or because my client machine was powered off.