Desktop app 1.1.27+ on Windows: bundled git cannot be spawned (Access is denied, 0x80070005), breaking all project registration #5094

Describe the bug

Starting with desktop app 1.1.27, the app can no longer spawn its own bundled git binary on Windows. Every startup logs:

WARN task_spawn{task="log_git_version"}: github_app_git_native::git: Failed to spawn git --version at startup
  binary=C:\Users\<user>\AppData\Local\github-copilot-git-2.53.0-4\cmd\git.exe
  embedded_git_in_use=true bundled_version="2.53.0-4"
  error=Access is denied. (0x80070005)

Because git is unusable, everything downstream breaks:

• create_project fails with Access is denied. (0x80070005) for any repository path
• the projects list comes back empty
• workspace health checks fail

The app is effectively unable to register or open any project.

Separately, and possibly related: on upgrading to 1.1.28 my projects table in ~/.copilot/data.db was emptied — all 8 projects vanished. They are still present in the data.db.pre-update-backup-* files, so the data survived, but the live DB lost them.

Affected version

Desktop app 1.1.27 and 1.1.28 (1.1.26 is unaffected). Bundled CLI GitHub Copilot CLI 1.0.95-2.

Steps to reproduce the behavior

1. Install desktop app 1.1.27 or 1.1.28 on Windows.
2. Start the app and try to add any project (local C:\ path or a WSL UNC path — both fail identically).
3. Registration fails with Access is denied. (0x80070005).
4. In ~/.copilot/logs/github-app.*.log, observe Failed to spawn git --version at startup ... error=Access is denied. (0x80070005) on every run.

Expected behavior

The app spawns its bundled git successfully and project registration works, as it does on 1.1.26.

Additional context

Version correlation across 21 app runs in my logs — the split is clean:

The regression appears in 1.1.27. In 1.1.28 the emitting module changed from github_app::git to github_app_git_native::git, but the failure is identical.

What I ruled out:

• Not the binary. git.exe at that exact path runs fine from a shell — git version 2.53.0.windows.4.
• Not file permissions. ACLs on the binary are clean (SYSTEM, Administrators, and my user all FullControl).
• Not security software. No corresponding block events in Defender, AppLocker, or CodeIntegrity logs.
• Not WSL or path format. I first hit this on a WSL UNC path, but a plain local C:\ repo fails identically. Tried \\wsl.localhost\..., \\wsl$\..., a mapped drive letter, and the extended-length \\?\UNC\... form — all the same.
• Not the working directory. Spawning git.exe with its working directory set to an unavailable UNC path still succeeds outside the app.
• Not configuration drift. Comparing the resolved git env log line between a working 1.1.26 run and a failing 1.1.28 run, the two are byte-for-byte identical — same binary path, same PATH, embedded_skipped_reason=None. Only the app version differs.

Curious detail that may help narrow it down: a PowerShell session spawned by the app (github.exe → copilot.exe → powershell.exe) can execute that same git.exe without any problem. So the app's own process tree is permitted to run it; only the spawn from github.exe itself is denied. That points at how the spawn is performed in 1.1.27+ rather than at any OS-level permission on the file.

Environment

• Windows 11, 10.0.26200.0, AMD64
• Bundled git 2.53.0-4 at %LOCALAPPDATA%\github-copilot-git-2.53.0-4\cmd\git.exe
• Shell: PowerShell 5.1

Workaround: downgrading to 1.1.26 restores normal behavior.