Windows sandbox setup no longer freezes the UI and reports specific failure reasons with timeouts.
What's wrong with this entry?
The Windows sandbox-runtime wrapper no longer blocks on synchronous subprocess calls, and its failures now surface as specific codes instead of generic errors.
- Every subcommand can run asynchronously through a promise-based spawn with a timeout: 15 s default, 120 s for install, 60 s for trust-ca.
- Failures throw a WindowsSandboxError carrying codes including spawn_failed, srt_win_timeout, install_timeout, install_wfp_failed, install_user_failed and install_config_conflict.
- Status, user and wfp probes gained async variants that run in parallel via Promise.allSettled.
- The sandbox dependency check invoked from /sandbox is now awaited through checkDependenciesAsync instead of blocking synchronously.
- Windows sandbox paths only.
srt-win install timed out \u2014 the UAC prompt may still be open.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.236
macOS sandbox re-applies read and delete denials inside writable folders
Both mention sandbox
-
v2.1.236
Sandbox proxy no longer writes to sockets that have gone away
Both mention sandbox
-
v2.1.236
IPv6 hosts through the proxy
Both mention sandbox