Browser canvas (WebView2) is blocked by Entra ID Conditional Access - needs AllowSingleSignOnUsingOSPrimaryAccount

### Short summary

Browser canvas (WebView2) is blocked by Entra ID Conditional Access - needs AllowSingleSignOnUsingOSPrimaryAccount

### Affected version or release

- Copilot app: `github.exe` 1.1.4 - Copilot CLI: 1.0.78-2 - WebView2 Runtime: 151.0.4129.59

### Installation context

_No response_

### What happened?

On Windows, the built-in **browser canvas** cannot be used to sign in to any corporate web app protected by a Microsoft Entra ID Conditional Access policy with a device-based grant control (*Require device to be marked as compliant* / *Require Hybrid Entra joined device*).

Signing in inside the browser canvas produces the standard Entra block page:

> **You can't get there from here**
> This application contains sensitive information and can only be accessed from: Devices or client applications that meet management compliance policy.

The same sign-in, same user, same machine, succeeds in Microsoft Edge.

**Root cause:** the browser canvas is an embedded WebView2 control. By default WebView2 does **not** share the Windows OS primary account / Primary Refresh Token (PRT) with the embedded browser process, so the sign-in never presents a device ID or device-compliance claim to Entra ID, and any device-based Conditional Access grant fails.

The host application must opt in by setting [`CoreWebView2EnvironmentOptions.AllowSingleSignOnUsingOSPrimaryAccount = true`](https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/winrt/microsoft_web_webview2_core/corewebview2environmentoptions) when creating the WebView2 environment. There is deliberately **no** end-user or IT-admin workaround: the property is not overridable via `WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS`, any Chromium/Edge command-line switch, registry, or Group Policy. Only the app that creates the environment can set it.

**I have empirically verified that this single property is the fix** - see the A/B test in Additional context below.

This makes the browser canvas unusable for a large class of enterprise users - including previewing their own app on `localhost` when that app authenticates against Entra ID.

### Steps to reproduce

1. Use a Windows device that is Entra joined or Hybrid Entra joined with a valid PRT (`dsregcmd /status` shows `AzureAdJoined : YES` and `AzureAdPrt : YES`).
2. Ensure the tenant has a Conditional Access policy targeting some web app with a grant control of *Require device to be marked as compliant* or *Require Hybrid Entra joined device*.
3. Open the browser canvas in the Copilot app and navigate to that web app (in our case an Angular SPA using `@azure/msal-angular` with the redirect flow).
4. Complete the Entra sign-in.
5. The "You can't get there from here" block page is shown instead of the app.
6. Open the same URL in Microsoft Edge on the same machine and sign in - it succeeds.

### Expected behavior

The browser canvas should be able to satisfy device-based Conditional Access policies on a compliant / Entra joined Windows device, so that enterprise users can preview and sign in to their own corporate web apps.

Concretely: set `AllowSingleSignOnUsingOSPrimaryAccount = true` on the `CoreWebView2EnvironmentOptions` used to create the browser canvas environment (ideally behind a user-facing setting, given it shares the OS account with the embedded browser). I have confirmed by direct A/B test that this property alone resolves the issue.

### Additional context

**A/B test confirming the fix**

I built a minimal WinForms WebView2 harness (.NET 10, `Microsoft.Web.WebView2` 1.0.4129.50 - matching the installed runtime 151.0.4129.59) that navigates to the affected corporate web app. The **only** difference between the two runs was the value of `AllowSingleSignOnUsingOSPrimaryAccount`. Each run used its own separate user data folder, so no cookies or token cache were shared between them.

```csharp
var opts = new CoreWebView2EnvironmentOptions
{
AllowSingleSignOnUsingOSPrimaryAccount = sso // false in run A, true in run B
};
var env = await CoreWebView2Environment.CreateAsync(null, userDataFolder, opts);
await webView.EnsureCoreWebView2Async(env);
```

| Run | `AllowSingleSignOnUsingOSPrimaryAccount` | Result |
| --- | --- | --- |
| A | `false` (the WebView2 default) | ❌ Entra "You can't get there from here" block page - reproduces the browser canvas bug exactly |
| B | `true` | ✅ Sign-in succeeds, app loads normally |

Same machine, same user, same URL, same WebView2 runtime, back to back. This isolates the property as both necessary and sufficient for this scenario.

**Diagnostics gathered on the affected machine**

`dsregcmd /status` - the device itself is fully healthy, so the block page's "connect your device" advice is a red herring:

```
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : YES
WorkplaceJoined : NO
AzureAdPrt : YES
AzureAdPrtExpiryTime :
```

Observed browser canvas WebView2 process (note the per-preview throwaway user data folder, so no credential state is shared or persisted):

```
msedgewebview2.exe --embedded-browser-webview=1 --webview-exe-name=github.exe --webview-exe-version=1.1.4
--user-data-dir="%TEMP%\github-app-browser-previews\github-app-browser-preview-XXXXXX\EBWebView"
```

**Note on implementation - this may not be a one-line change**

The app appears to be Tauri/wry based. As of the current `dev` branch, `wry`'s Windows `PlatformSpecificWebViewAttributes` exposes `additional_browser_args`, `browser_extensions_enabled`, `scroll_bar_style`, `profile_name` and `environment`, but **not** `allow_single_sign_on_using_os_primary_account`. So this likely needs either:

- an upstream `wry` addition (plus a Tauri config option), or
- constructing the `ICoreWebView2Environment` manually via `webview2-com` with the flag set, and passing it through wry's existing `environment` field.

**Security considerations - why this should not simply be switched on by default**

I want to be upfront that this is not a free change, and the WebView2 default of `false` is a deliberate security gate rather than an oversight. The concerns I can see:

- **It is an environment-wide grant, not a per-site one.** The browser canvas renders arbitrary web content, some of it navigated to by the agent rather than the user. Enabling OS primary account SSO means any page loaded in that environment sits in a context where the logged-in Windows identity can be used for silent SSO. Combined with prompt injection (agent is induced to navigate somewhere hostile), this widens the blast radius.
- **It is broader than just Entra.** Per the documentation the property also enables SSO with web sites using the Microsoft account associated with the Windows login, so it covers personal MSA as well as AAD.
- **It conflicts with the current throwaway-profile design.** The observed per-preview `%TEMP%` user data folders suggest a deliberate decision to keep no persistent credential state.
- **It is Windows-only**, so behaviour would diverge from macOS/Linux where WKWebView / WebKitGTK have no equivalent.
- **It can only be set at environment creation time**, so it cannot be toggled per navigation.

**Suggested mitigation:** ship it **default-off and opt-in**, as a user-level setting (e.g. "Allow the built-in browser to use my Windows work account for single sign-on"), ideally by creating a *separate* WebView2 environment used only for user-initiated navigation, leaving agent-driven previews on the current isolated, non-SSO environment. That preserves today's security posture for everyone who doesn't need this, while unblocking enterprise users who currently cannot use the browser canvas at all.

**Environment**

- OS: Windows 11 Enterprise 10.0.22631
- CPU architecture: x86_64 (AMD64)

**Workarounds available to users today**

None within the app. Affected users must fall back to Microsoft Edge (WebView2 cookies are not shared with Edge, so it is a separate sign-in), or ask their Entra administrator to weaken the Conditional Access grant - which is generally not acceptable for applications holding sensitive data.

Start with the Windows wry PlatformSpecificWebViewAttributes and the Tauri browser-canvas environment creation path; the issue notes that the existing environment field may accept a manually configured WebView2 environment. Check whether wry or Tauri exposes the setting, then verify the opt-in behavior with a WebView2 test using separate user-data folders and an Entra Conditional Access site.

Written by the indexing model from the issue text.