Inconsistent "Screenshots and screen recording" privacy permissions for Signed MSIX via Windows Graphics Capture

Question

Hello,

We are developing a Windows productivity application deployed as a code-signed MSIX package. Our app utilizes the Windows.Graphics.Capture namespace to allow users to capture selective active application windows.

The Issue: Since the rollout of the "Screenshots and screen recording" privacy hub (Windows 11 23H2/24H2), we are seeing inconsistent permission states. Even though our AppXManifest.xml declares the necessary capabilities, the toggle in Settings > Privacy & security > Screenshots and screen recording defaults to "Off" for some users or, more critically, reverts to "Off" spontaneously after Windows Updates or app package updates.

Technical Environment:

• Deployment: MSIX (Signed)

APIs used: GraphicsCaptureItem, GraphicsCaptureSession

Target: Enterprise-managed Windows 11 environments.

Questions for the Product Team - or whoever knows-:

Manifest Declaration: Is there a specific restricted capability (e.g., uap:Capability Name="screenRecording") or a desktop6 extension required in the MSIX manifest to proactively register the app in the "Let apps take screenshots" list with a default "On" state?

Enterprise Management (GPO/CSP): What is the specific CSP or GPO path to allow a specific Package Family Name (PFN) to bypass this manual toggle? We need to provide our enterprise customers with a way to whitelist our app via Intune/Group Policy.

Persistence: Why does the ConsentStore (CapabilityAccessManager) appear to lose the user's "On" preference during an MSIX version increment?

Deep Linking: What is the direct ms-settings URI to take a user directly to the "Screenshots and screen recording" sub-page to minimize UX friction?

We have searched the official Microsoft Learn documentation but find very little regarding the programmatic management of this specific new privacy sub-category.

Answer 1

For enterprise-managed Windows 11 devices, screenshots and screen recording permissions for Windows apps using Windows.Graphics.Capture are controlled by the App Privacy policy “Let Windows apps take screenshots of various windows or displays.” This is exposed via Group Policy and MDM (Policy CSP – Privacy) and works per Package Family Name (PFN).

Answers aligned to the questions:

1. Manifest declaration / capability The provided context does not define a special MSIX capability such as screenRecording or a desktop6 extension that would automatically register the app with a default “On” state in the “Screenshots and screen recording” privacy page. Control is instead exposed via policy:

• Policy name: LetAppsAccessGraphicsCaptureProgrammatic
• Friendly name: Let Windows apps take screenshots of various windows or displays
• Group Policy path: Computer Configuration > Windows Components > App Privacy
• Registry key: Software\Policies\Microsoft\Windows\AppPrivacy

2. Enterprise management (GPO / CSP) for a specific PFN For enterprise environments (Intune/MDM or on-prem GPO), use the Privacy CSP nodes that map to this policy and accept PFNs as values:

• Default / user-control behavior:
  • ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessGraphicsCaptureProgrammatic_UserInControlOfTheseApps
  • Behavior: “User is in control” – users can manage the toggle in Settings > Privacy.
• Force allow specific apps (whitelist by PFN):
  • ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessGraphicsCaptureProgrammatic_ForceAllowTheseApps
  • Behavior: Apps listed (by PFN) are always allowed to take screenshots of windows or displays; users cannot change this.
• Force deny specific apps:
  • ./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsAccessGraphicsCaptureProgrammatic_ForceDenyTheseApps
  • Behavior: Apps listed (by PFN) are always blocked; users cannot change this.

All three nodes:

• Scope: Device
• Editions: Pro, Enterprise, Education, IoT Enterprise / IoT Enterprise LTSC
• OS: Windows 11, version 21H2 [10.0.22000] and later
• Format: chr (string), Allowed values: list (delimiter ;)

To whitelist a specific app via Intune/MDM, configure LetAppsAccessGraphicsCaptureProgrammatic_ForceAllowTheseApps with a semicolon-separated list of PFNs (for example, YourCompany.YourApp_1234567890abc;AnotherApp_PFN...). A per-app setting here overrides the default.

If the app is open when the policy is applied, the app (or device) must be restarted for the policy to take effect.

3. Persistence of user consent across updates The context describes the policy behavior but does not document the internal behavior of ConsentStore or CapabilityAccessManager across MSIX version increments. What is documented is that policy-based configuration is authoritative and overrides user choice:

• If “Force Allow” or “Force Deny” is configured for a PFN, the user cannot change it in Settings.
• If the policy is disabled or not configured, users control the setting via Settings > Privacy.

For reliable persistence in enterprise environments, use the CSP/GPO “Force Allow” list for the PFN instead of relying on user consent alone. This avoids loss of effective permission when Windows or the app is updated.

4. Deep linking to the “Screenshots and screen recording” page The context does not provide a ms-settings: URI for deep linking directly to the “Screenshots and screen recording” sub-page, so no documented URI can be given here.

Summary for enterprise rollout:

• Use the PFN-based MDM/GPO policy LetAppsAccessGraphicsCaptureProgrammatic_ForceAllowTheseApps to guarantee that the app can always use Windows.Graphics.Capture without users needing to toggle anything.
• Configure this via Intune (Privacy CSP) or on-prem Group Policy under Computer Configuration > Windows Components > App Privacy.
• Do not rely solely on manifest capabilities or user consent if deterministic behavior is required after OS or app updates.

---

References:

• Policy CSP - Privacy