Cloning in VSCode sets absolute worktree path. It breaks git on WSL. How to prevent VSCode from doing this unnecessary behavior?
Opened this issue · 1 comments
Does this issue occur when all extensions are disabled?: Yes/No
Version: 1.105.1 (user setup)
Commit: 7d842fb
Date: 2025-10-14T22:33:36.618Z
Electron: 37.6.0
ElectronBuildId: 12502201
Chromium: 138.0.7204.251
Node.js: 22.19.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.19044
Steps to Reproduce:
- Use "Clone Git Repository..."
- Run WSL on the repo's local directory
- Run git
- See git fail with "cannot chdir to .. no such file or directory"
Logs show that git clone <remote url> c:\Users\.. is what's causing the absolute worktree value. Defining a destination directory sets the worktree variable in .git/config. However, the way the destination directory is written makes it inaccessible in WSL 1. It has to be in the form /mnt/c/Users/...
The workaround is this: Remove the worktree variable from .git/config. Doing so will make git work on WSL again for the local directory where the repo was cloned.
However, I wonder if there's a more elegant workaround for this, such as changing how VSCode runs git clone command, so it stops setting absolute worktree values?
Logs:
2025-11-07 11:50:47.975 [info] [main] Log level: Info
2025-11-07 11:50:47.975 [info] [main] Validating found git in: "C:\Program Files\Git\cmd\git.exe"
2025-11-07 11:50:47.975 [info] [main] Using git "2.27.0.windows.1" from "C:\Program Files\Git\cmd\git.exe"
2025-11-07 11:50:47.975 [info] [Model][doInitialScan] Initial repository scan started
2025-11-07 11:50:47.975 [info] [Model][doInitialScan] Initial repository scan completed - repositories (0), closed repositories (0), parent repositories (0), unsafe repositories (0)
2025-11-07 11:51:21.646 [info] > git clone https://github.com/redacted---/redacted---.git c:\Users\redacted---\redacted--- --progress [3432ms]
2025-11-07 11:51:21.646 [info] Cloning into 'c:\Users\redacted---\redacted---'...
remote: Enumerating objects: 118, done.
remote: Counting objects: 0% (1/118)