Bug: "Failed to open PR" — ShellExecuteW returns os error 1223 when opening external links on Windows

[jonathanpeppers]

Short summary

Clicking a PR link in the GitHub Copilot desktop app sometimes fails with
"Failed to open PR — Couldn't open the pull request. The operation was canceled
by the user. (os error 1223)" even though no UAC/SmartScreen prompt was shown
and the default browser launches fine for other links.

Affected version

GitHub Copilot desktop app v0.2.23 (Windows installer build), github.exe
ProductName "GitHub Copilot", CompanyName "GitHub Inc.".

Environment

• Windows 11
• Default HTTPS handler: MSEdgeHTM → msedge.exe (working, unelevated)
• App and Edge both running unelevated (no integrity mismatch)
• No relevant Edge/SmartScreen policies blocking https URLs
• No custom github:// / x-github-client:// protocol handlers registered

What happened

Clicking a PR link in the app shows a toast:

Failed to open PR
Couldn't open the pull request.
The operation was canceled by the user. (os error 1223)

The link is a plain https://github.com/... URL, so UAC is not a plausible
cause. Error 1223 is ERROR_CANCELLED from ShellExecuteW.

Log excerpt

From %USERPROFILE%\.copilot\logs\github-app.<pid>.log:

21:34:45.672  INFO  github_app::workspace::handlers: archived workspace workspace_id=…
21:34:48.974  ERROR frontend: [WebSocket] Server error: Failed to get session state: request cancelled
21:34:48.974  ERROR frontend: The operation was canceled by the user. (os error 1223)  (x3, same µs)
21:34:52.567  DEBUG set_app_activity / unsubscribe_resource workspace-view-full-…
21:34:53.974  ERROR frontend: The operation was canceled by the user. (os error 1223)  (x7, same µs)

Two observations:

1. Each click produces N identical log lines at the same microsecond (3
   then 7). That's the frontend logging the same single rejection from multiple
   subscribers, not multiple ShellExecute calls — but it's noisy and suggests
   a useEffect / event-subscription duplication on the open-PR handler.
2. Both failures occur immediately after a workspace teardown (archived workspace / unsubscribe_resource). The "request cancelled" WebSocket
   error fires at the same millisecond as the first 1223. This looks like a
   race between WebView teardown and the call to
   invoke('plugin:opener|open_url', …) — tauri-plugin-opener calls
   ShellExecuteW, which is sensitive to the calling thread's activation
   state and returns 1223 when activation is being cancelled.

Steps to reproduce

1. Have an active session/workspace open for a PR.
2. Archive or navigate away from the workspace.
3. Immediately click a different PR link in the sidebar/inbox.
4. Observe "Failed to open PR" toast and 1223 in the log.

Not 100% deterministic — appears timing-dependent on the teardown race.

Expected behavior

The link opens in the default browser, as it does on subsequent clicks.

Suggested fix

• Debounce / de-duplicate the open-PR click handler on the frontend so only
  one invoke('plugin:opener|open_url', …) runs per click.
• On Windows, treat ERROR_CANCELLED (1223) from tauri-plugin-opener as a
  retryable transient (single retry after ~50 ms) rather than surfacing it as
  a hard failure, since UAC genuinely isn't involved for https URLs.
• Consider falling back to Start-Process / cmd /c start on 1223.

Additional context

App identifier: com.github.githubapp. Rust namespace: github_app. Plugin:
tauri-plugin-opener. Screenshot of the toast available on request.