how do the extension determine whether the "remote" jupyter kernel is actually local or true remote?

[TTTPOB]

On my end, I would define a kernel "local" if the kernel share the same filesystem as my local one. By this difinition, when working on a HPC cluster, if I submit a job to run a jupyter server on the task node, portforward it to login node's localhost:7788, connect it on login node in vscode, the kernel would be considered remote, but I think it this case it should be considered local since they share the same filesystem thus allow the language server work on static analysis.
According to 1.87 release note, vscode-jupyter extension will treat actually local "remote" kernel as local running one, and enable ls support for it. So how is the criterion? In my case, how do i let the extension think it is a actually a local running kernel?

[DonJayamanne]

how do i let the extension think it is a actually a local running kernel?

You don't need to do anything
We run some code in the kernel to check if dinner of the local files exist on the remote server kernel as well, if they do, then we treat it as local.
Ie the python executable is assumed to be local.

[DonJayamanne]

Does the remote kernel have access to local files system?

[TTTPOB]

the remote machine (computation node) and the local machine (login node) mounts the same nfs to /home, and all my project files, python environments, are under `/home. So I think I can say yes, the remote kernel have access to local filesystem.

[TTTPOB]

Thank you for your explanation and sorry about this, when trying to upload log to facilitate the debugging, I found this in this HPC system, the jupyter extension is downgraded by my college share the same account with me. After updating to to the latest version, it worked.