Files in pull request opened by absolute path; not considered the same file as the file within the workspace

[zygoloid]

Type: Bug

I have a PR checked out in the root directory of my VS code workspace. Sometimes (I'm not sure exactly the conditions for this happening, but it happens frequently for me), PR comments do not appear when I open the corresponding file.

When this happens, if I open the file from the "GitHub Pull Requests" sidebar, a second editor view appears. In this second editor view, the path to the file is displayed as an absolute path (home > me > workspace > path > file) whereas the path in the first editor view is displayed relative to the workspace (path > file). VS code appears to treat them as two completely separate files, and the PR comments appear only in the absolute-path view of the file.

There are no symlinks or other obvious complicating factors in the path. Running code path/file or code $PWD/path/file from the integrated terminal open the relative-path view.

Extension version: 0.106.0
VS Code version: Code 1.98.0 (Universal) (6609ac3d66f4eade5cf376d1cb76f13985724bcb, 2025-03-04T21:06:18.612Z)
OS version: Darwin arm64 23.6.0
Modes:
Remote OS version: Linux x64 6.10.11-1rodete2-amd64

System Info

Item	Value
CPUs	Apple M1 Pro (10 x 2400)
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 webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	3, 2, 3
Memory (System)	32.00GB (3.19GB free)
Process Argv	--crash-reporter-id a2b1566c-976d-4a22-b919-31335ae2a712
Screen Reader	no
VM	0%

Item	Value
Remote	SSH: ct
OS	Linux x64 6.10.11-1rodete2-amd64
CPUs	AMD EPYC 7B13 (128 x 0)
Memory (System)	236.11GB (219.44GB free)
VM	0%

A/B Experiments

vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
2e7ec940:31000449
pythontbext0:30879054
cppperfnew:31000557
dwnewjupyter:31046869
nativerepl1:31139838
pythonrstrctxt:31112756
nativeloc2:31192216
iacca1:31171482
5fd0e150:31155592
dwcopilot:31170013
6074i472:31201624
dwoutputs:31242946
customenabled:31248079
5a9hg449:31230677
hdaa2157:31222309
copilot_t_ci:31222730
f5992895:31254866
jda6j935:31233686
pythoneinst12cf:31257680
4d2d8976:31256800
563cc122:31253270
31787653:31256342

[zygoloid]

Aha, it looks like this is happening because the extension fails to properly detect that the PR is checked out. The "GitHub Pull Request" sidebar button also does not appear when the extension is in the broken state.

To reproduce:

• Set up a github remote using SSH, with an SSH private key that has a passphrase.
• Check out a branch corresponding to a PR.
• Open a file from that branch, with the extension and with VS Code.

What happens:

• The extension presumably attempts to perform a git ssh operation and fails because the passphrase for the private key is not available.
• The extension opens a read-only view of the file (weirdly using an absolute path) because it doesn't think the PR is checked out.

What should happen:

• The extension determines that the PR is checked out and opens a read-write view of the file. This can be done using only public information, so ideally shouldn't require any use of the private key.
• Or possibly, the extension queries for the SSH passphrase rather than silently failing?