Credentials Aren’t Pulled from Host App

[BHare1985]

I am running GithubDesktopWSL on windows and it had me login to my github account and all that.
I use a new WSL image for all my development because AI works way better in linux/bash then trying to struggle with powershell.

However, when I go to commit, it says I need to set the username and email of the git account. I was confused by this because when I use normal GithubDesktop and point it to a \wsl.localhost\ it doesn't need any of that information (I assume because its using whats stored on windows and not WSL). I supply the username and email in WSL, and it commits successfully but then when I go to push it gives me trouble saying something about "terminal prompts disabled" and I found the quick fix as git config --global --add url."git@github.com:".insteadOf "https://github.com/" and they changed the error to not being authorized. I assume it will require me to setup my github account within WSL and doesnt just use the github information already in windows.

This may or may not be a bug based on your design, but it sure is painful to setup github auth on every WSL enviorment I need, whereas normal desktop doesnt require that, its just super slow.

[aleixrodriala]

Thanks for the detailed report — this is a real design gap, and #61 is the same root cause. What's happening:

• Commit identity: git runs natively inside your WSL distro, so it reads the distro's ~/.gitconfig, not anything from Windows. One-time fix per distro: git config --global user.name ... && git config --global user.email .... (Upstream Desktop over \\wsl.localhost runs Windows git, which is why it never asked — and also why it's so slow, which is the whole reason this fork exists.)
• Push/fetch auth: upstream Desktop authenticates HTTPS remotes through a Windows-side credential helper connected to the app. That helper can't run inside the distro, so the fork currently forwards no credentials — HTTPS operations fail with terminal prompts disabled, and after your insteadOf rewrite you were on SSH without a key registered, hence "not authorized".

Workarounds today: use SSH remotes with a key in WSL (ssh-keygen → add to GitHub → the fork picks up WSL keys natively), or point WSL git at Windows Git Credential Manager per Microsoft's guide if you have Git for Windows.

Planned fix: bridge the app's credential helper into the distro (WSL→Windows interop can invoke the app's trampoline helper, with WSLENV forwarding the session vars), so the account you signed into the app with just works for fetch/push — no per-distro setup. Keeping this issue open to track that.