WSL/wslgit: primary repository Worktrees section is empty, but directly opened worktrees recognize it

[DanielLaberge]

Fork 2.21.0.0 does not list any additional Git worktrees when I open the primary repository from WSL2 through \\wsl.localhost\Ubuntu\... while using wslgit. Git reports the worktrees correctly, Fork can create one successfully, and the same worktrees can be opened directly with Ctrl+O. However, the primary repository’s Worktrees section remains empty.

I am currently evaluating Fork and otherwise really like the product. This is my only blocker to purchasing it, because worktrees are central to my workflow.

Environment

• Fork 2.21.0.0 for Windows (Develop update channel)
• Windows 11
• WSL2, Ubuntu
• Custom Git executable: C:\Repos\z.Tools\wslgit\bin\git.exe
• Primary repository path: \\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy
• Additional Git worktrees are stored outside the primary repository directory

Relevant repository layout

Primary repository:
\\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy

Additional worktrees used in this report:
\\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy-worktrees\test
\\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy_deployment-platform

Reproduction

1. Configure Fork to use C:\Repos\z.Tools\wslgit\bin\git.exe.

2. Press Ctrl+O in Fork and open the primary repository:

   \\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy
   

3. Expand Worktrees in the sidebar. The section is empty.

4. Use Fork’s New Worktree dialog to create a branch and worktree named test at:

   \\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy-worktrees\test
   

   Fork creates the worktree successfully, but the primary repository’s Worktrees section remains empty.

5. In PowerShell, run:

   C:\Repos\z.Tools\wslgit\bin\git.exe worktree list --porcelain

   Git reports both additional worktrees correctly:

   worktree /home/daniel/repos/ConstructBuy-worktrees/test
   HEAD 09873c7160a3299863f625695bd25085bf917dad
   branch refs/heads/test
   
   worktree /home/daniel/repos/ConstructBuy_deployment-platform
   HEAD 2653c57d161e5393d7946805e3ec030b113bdaab
   branch refs/heads/codex/deployment-platform-foundation
   

6. Press Ctrl+O again and explicitly open the other worktree directory:

   \\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy_deployment-platform
   

7. Fork opens that directory successfully. In this tab, the Worktrees section contains ConstructBuy, showing that Fork recognizes its relationship to the primary repository.

Expected

When the primary repository path is open, its Worktrees section should list the additional worktrees returned by git worktree list, including ConstructBuy_deployment-platform and test.

Actual

• The primary repository’s Worktrees section is empty, including after Fork itself successfully creates test.
• Git lists both test and ConstructBuy_deployment-platform correctly.
• Opening \\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy_deployment-platform separately with Ctrl+O works, and that tab’s Worktrees section shows ConstructBuy.
• The additional-worktree tab is titled ConstructBuy: ConstructBuy_deployment-platform (Ubuntu), while the primary-repository tab is titled only ConstructBuy and does not include (Ubuntu).
• fork.log contains no errors or warnings when Fork loads or refreshes the primary repository.

The result is asymmetric:

Open with Ctrl+O:
\\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy
  Worktrees
    [empty]

Open with Ctrl+O:
\\wsl.localhost\Ubuntu\home\daniel\repos\ConstructBuy_deployment-platform
  Worktrees
    ConstructBuy

Possibly related: #2746 reports other primary-worktree UI inconsistencies, but this report is specifically about asymmetric WSL/wslgit worktree discovery from the primary repository.

Related WSL context: #701, including this report that worktrees do not work with WSLGIT. The separate \\wsl$\... worktree-creation path bug is tracked in #2829 and is not required to reproduce this display problem.