Found in the v0.8.0 pre-release review. Pre-existing in the WSL feature (#65/#121) rather than a regression, but WSL sessions ship for the first time in v0.8.0, so this is its debut.
What happens
GitService decides it is looking at a WSL repo by parsing the \wsl$\<distro>\… UNC out of the working folder (RunGitCoreAsync), which gives it the distro and nothing else. It then runs:
wsl.exe -d <distro> -e sh -lc 'printf …; exec "$0" "$@"' git -C <path> …
There is no -u. ShellSession.BuildWslArgs passes -u <WslUser> when the session has one; the git path cannot, because WslUser never reaches GitService.
Why it matters
For a session with WslUser set, git runs as the distro's default user against a tree owned by someone else. Git's safe.directory / dubious-ownership check then refuses the repo, and the symptom is the sidebar showing no branch at all — indistinguishable from "not a repo".
The same omission means the PATH restored by the login shell is the default user's profile, not the session user's. That partially undercuts the reason -e sh -lc exists (see the "Never interpolate a value into a command line" section of CLAUDE.md).
Fix sketch
WslUser has to be threaded from the session to the git call. The public surface is folder-only today:
GetGitInfoAsync(string folderPath)
GetRepoRootAsync(string folderPath)
ListWorktreesAsync(string folderPath)
ListBranchesAsync(string folderPath)
CreateWorktreeAsync(string repoRoot, …)
An optional string? wslUser = null on each, passed down to RunGitInWslAsync and emitted as -u <user> before -e, is the smallest change. Callers in SessionViewModel.RefreshGitInfoAsync and the worktree dialog have the ShellSession to hand.
Deliberately not done during release hardening: it widens five signatures across several call sites, and the failure mode is a degraded display rather than anything unsafe.
Acceptance
Found in the v0.8.0 pre-release review. Pre-existing in the WSL feature (#65/#121) rather than a regression, but WSL sessions ship for the first time in v0.8.0, so this is its debut.
What happens
GitServicedecides it is looking at a WSL repo by parsing the\wsl$\<distro>\…UNC out of the working folder (RunGitCoreAsync), which gives it the distro and nothing else. It then runs:There is no
-u.ShellSession.BuildWslArgspasses-u <WslUser>when the session has one; the git path cannot, becauseWslUsernever reachesGitService.Why it matters
For a session with
WslUserset, git runs as the distro's default user against a tree owned by someone else. Git'ssafe.directory/ dubious-ownership check then refuses the repo, and the symptom is the sidebar showing no branch at all — indistinguishable from "not a repo".The same omission means the PATH restored by the login shell is the default user's profile, not the session user's. That partially undercuts the reason
-e sh -lcexists (see the "Never interpolate a value into a command line" section of CLAUDE.md).Fix sketch
WslUserhas to be threaded from the session to the git call. The public surface is folder-only today:An optional
string? wslUser = nullon each, passed down toRunGitInWslAsyncand emitted as-u <user>before-e, is the smallest change. Callers inSessionViewModel.RefreshGitInfoAsyncand the worktree dialog have theShellSessionto hand.Deliberately not done during release hardening: it widens five signatures across several call sites, and the failure mode is a degraded display rather than anything unsafe.
Acceptance
wsl.exe … -u <WslUser>when the session defines oneBuildWslGitCommandLineargv test, like the existing injection suite