Windows Sandbox: How to verify effective .wsb settings, mapped folders and read-only permissions?

There is no documented, supported read-only command, API, or UI that returns the complete effective security configuration—including all folder mappings and write modes—for one running Windows Sandbox session; the strongest supported approach is to preserve the .wsb, collect applicable policy results, identify the session, and clearly treat these as configuration evidence rather than runtime attestation.

1. What can be established

The .wsb file documents the requested configuration:

• Networking, ClipboardRedirection, and AudioInput accept Enable, Disable, or Default.
• Each MappedFolder records HostFolder, optional SandboxFolder, and ReadOnly.
• <ReadOnly>true</ReadOnly> enforces read-only access from the container; if omitted, it defaults to false.
• Mapped folders are established before the logon command runs. ^1^

Preserve and hash the exact file before launch:

$wsb = 'C:\Sandbox\Evidence.wsb'
Get-Item $wsb | Select-Object FullName, Length, LastWriteTimeUtc
Get-FileHash $wsb -Algorithm SHA256
Get-Content $wsb -Raw

The hash proves the contents of that preserved file. It does not prove that the file created a particular session unless an authoritative launch record links that file or its contents to the session.

A defensively configured two-folder file would contain explicit values rather than Default:

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <AudioInput>Disable</AudioInput>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Input1</HostFolder>
      <SandboxFolder>C:\Input1</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
    <MappedFolder>
      <HostFolder>C:\Input2</HostFolder>
      <SandboxFolder>C:\Input2</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

2. Policy evidence and precedence

For Group Policy, generate Resultant Set of Policy evidence from an elevated command prompt:

gpresult /scope computer /h C:\Temp\Sandbox-GP.html

gpresult reports the resulting Group Policy settings enforced on the computer, including overlapping policy resolution. ^2^

Inspect the report for Computer Configuration → Windows Components → Windows Sandbox, particularly:

• Allow networking in Windows Sandbox
• Allow clipboard sharing with Windows Sandbox
• Allow audio input in Windows Sandbox
• Allow mapping folders into Windows Sandbox

These policies are device-scoped. Networking, clipboard, and audio-input policy changes require restarting Windows Sandbox; therefore, policy captured after launch is not necessarily proof of that session’s launch-time state. ^3^

If the device is MDM-managed, the supported UI evidence is:

Settings → Accounts → Access work or school → select the account → Info → Create report

The resulting MDMDiagHtmlReport.html is a snapshot of MDM configurations and policies. It proves reported device-management state, not the effective configuration of a particular Sandbox session. ^4^

If MDMWinsOverGP is configured as 1, Policy CSP settings with equivalent Group Policy settings cause the corresponding GP setting to be blocked. The diagnostic report identifies blocked GP settings. Without that mechanism, configuring the same setting through both channels can create a race with no guaranteed winner. ^5^

A launch can also report “The following settings are enforced by your IT administrator” when a .wsb setting conflicts with Group Policy. That message demonstrates policy enforcement, but it is not a complete effective-state report. ^6^

3. Session identification and runtime limitations

On the Store version, confirm the package and CLI versions:

Get-AppxPackage -Name WindowsSandbox | Select-Object Name, Version
wsb --version
wsb list

wsb list provides each current user’s Sandbox ID, status, and uptime. It does not return the effective .wsb, policy decisions, mappings, or permissions. A Sandbox started through wsb start returns an ID, which provides stronger launch correlation:

wsb start --config "<Configuration><Networking>Disable</Networking></Configuration>"
wsb list

Even that ID is only corroborating evidence: the documented CLI does not attest that the requested configuration became the complete effective runtime configuration. ^7^

The Store version also permits clipboard, audio/video, and folder-sharing changes during runtime through the … menu. Consequently, the original .wsb alone cannot establish the session’s later state. The newer Store version requires Windows 11 24H2 with the documented update prerequisites. ^8^

There is no documented supported enumeration that proves:

• Every active host source and guest destination.
• Every mapping’s effective write mode.
• That no runtime-added mapping exists.
• The current effective networking, clipboard, or microphone state.
• An immutable link between a .wsb file and an already-running session.

4. AllowWriteToMappedFolders documentation issue

The authoritative CSP URI is documented as:

./Device/Vendor/MSFT/Policy/Config/WindowsSandbox/AllowWriteToMappedFolders

It is device-scoped, uses integer values 0 = not allowed and 1 = allowed/default, depends on AllowMappedFolders=1, and applies to Windows 11 24H2 build 26100 or later. ^3^

Its interaction with .wsb is restrictive:

• ReadOnly=true requests and enforces read-only access for that mapping.
• When mapped folders are allowed but writing is disabled by policy, Sandbox receives read-only access regardless of a writable mapping request.
• Disabling AllowMappedFolders prevents mappings entirely.

However, the current AllowWriteToMappedFolders section duplicates the AllowMappedFolders Group Policy mapping—name, friendly name, and registry value—and therefore does not provide an unambiguous public registry value for the write-specific policy. Do not treat the displayed AllowMappedFolders registry value as authoritative evidence for AllowWriteToMappedFolders.

Submit documentation feedback from the Feedback control on the Policy CSP page, identifying the duplicated mapping. For a binding production answer, open a Microsoft Support case and include:

• winver screenshot or OS build details;
• Sandbox package and wsb --version output;
• the installed WindowsSandbox.admx version;
• preserved .wsb and SHA-256 hash;
• gpresult output;
• the relevant MDM policy report sections;
• Sandbox ID, launch time, and exact launch command.

That escalation is necessary if evidence must constitute Microsoft-supported attestation rather than a documented chain of configuration intent and policy state.

References

1. Use and configure Windows Sandbox
2. gpresult
3. Policy CSP - WindowsSandbox
4. Collect MDM logs
5. Policy CSP - ControlPolicyConflict
6. Troubleshoot Windows Sandbox
7. Windows Sandbox command line | Microsoft Learn
8. Windows Sandbox versions