Windows Sandbox Tools: installers, a startup script, and an SSH tunnel for a throwaway Windows

The premise is a disposable Windows with a bare userland

Windows Sandbox gives you a throwaway Windows environment that starts clean and is thrown away when you close it. That isolation is exactly what you want for opening a file you do not trust, testing an installer, or reproducing a bug on a system state you can destroy freely. It is also painfully bare, since the base image lacks package managers, the Microsoft Store, and anything resembling a usable shell workflow. ThioJoe's repository is a collection of scripts that fill those gaps, and the project description states the aim plainly as various useful scripts for use within Windows Sandbox. The audience is a Windows user who already knows what the sandbox is and has hit its limits, not someone looking for a general purpose virtualisation tool. Everything here is scoped to the lifetime of a single sandbox session.

The installer scripts add winget, VC runtimes, and the Store

Three installer scripts cover the missing pieces. `Install-Winget.ps1` fetches the necessary files and dependencies from Microsoft's winget-cli repository and installs it, which gives the sandbox a real package manager. `Install VC Redist.ps1` installs the latest Microsoft Visual C++ Redistributables, which the README notes are commonly required by other software, so anything you install through winget is likely to need them first. `Install-Microsoft-Store.ps1` installs the Microsoft Store via the Windows Update APIs, and here the README is emphatic about a design decision, stating that unlike other similar scripts this one does not use any third party APIs such as UUP Dump or RG-Adguard, and that all web requests go directly to Microsoft servers, even those fetching the download URLs in the first place. For a security tool, that provenance argument matters, since a script that touches unknown endpoints in a sandbox you use to inspect untrusted code is a risk in itself.

Installing store apps without the Store, and the XP limitation

The fourth installer goes further. `Install-Store-Apps.ps1` can search, download, and install apps from the Microsoft Store without the Microsoft Store needing to be installed, and it can also search the Microsoft Update Catalog. It uses the Windows Update APIs with no third party APIs, so again all requests go directly to Microsoft servers. The script can be run with parameters to auto install a specific app, or run without parameters to use it interactively, which is a nice touch for someone experimenting in a throwaway environment. There is one clear limitation stated in the README: apps with their own installer, identified by IDs starting with XP, cannot be fetched this way. So the script covers packaged store apps, and the classic installer based applications are still out of reach through this particular path.

Dark theme, light theme, and a wallpaper that only changes one way

The general scripts are small quality of life changes. `Set Theme Dark Mode.ps1` sets the Sandbox to the Dark theme and also changes to a dark wallpaper, and `Set Theme Light Mode.ps1` restores the Light theme. The README is honest about the asymmetry between them, noting that the light theme script does not currently change the wallpaper back. That is a fair summary of the level of polish here, and it is worth knowing before you assume the pair is a matched set. The third general script is the interesting one. `Start-Agent-Tunnel.ps1` sets up an instant, disposable SSH connection into the sandbox without needing to open any ports, and it also generates a connection instructions zip file you can hand straight to an agent. For a workflow where an AI assistant or a colleague needs shell access to the disposable machine, that removes the usual step of exposing a port.

Drag files in with a .wsb config instead of a mapped folder

The external tools section contains one script, `Create-WSB-Copy-Files.bat`. The idea is that you drag files onto it and it creates a .wsb configuration where the sandbox will launch with those files pre-copied into it, without needing to map a folder. The README notes it has configurable options, including whether to auto-launch a .ps1 script post-launch if there is one. This is a small but real ergonomic win, because the normal way to get a file into a sandbox is to declare a mapped host folder in the .wsb file, which means editing XML by hand every time you want a different payload. The repository ships a ready configuration in its Sandbox Configurations directory, so the pattern is to edit one file rather than author one from scratch each time.

SandboxStartup.ps1 is a set of registry tweaks, and it is personal

The startup script runs inside the sandbox at launch and, in the README's own words, does a bunch of random registry tweaks to set up the Sandbox based on the author's own preference. The list is specific. It enables the old context menu. It turns on Explorer settings for showing hidden files and file extensions. It adds Open PowerShell Here and Open CMD Here to the context menu, and adds .txt and .ps1 files to the context menu New list. It sets the PowerShell execution policy to allow running scripts and makes them runnable by double clicking. If you put Notepad or Notepad++ into the shared host folder, it adds context menu options to edit files with them and sets them as the default editor for .txt files. Finally it restarts Explorer to apply the changes and opens the shared host folder. The author is upfront that this reflects one person's setup, and a separate wiki page holds further optional tweaks, so treat the script as a starting point to be edited rather than a configuration to be applied unchanged.

Getting the startup script to run automatically

Because the script is written assuming it runs from within the sandbox, running it automatically means putting it in a mapped shared folder, and the README lays out the steps. You create a folder location outside the sandbox that you will map in, and it does not matter what it is called or where it goes, with something like `C:\Users\WhateverUsername\MySharedSandboxFolder` given as an example. The repository includes a configuration file, `MyDefaultSandbox.wsb`, already set up to map that folder to the location the script expects, so all you need to do is update the HostFolder setting to the path you chose:

    <HostFolder>C:\Users\WhateverUsername\MySharedSandboxFolder</HostFolder>

You then update any other options in the .wsb file to your liking, such as the amount of RAM, and launch the sandbox by double clicking `MyDefaultSandbox.wsb`. The folder is mapped to the Desktop as a folder called HostShared, and the script runs automatically. The README also notes that you can add other scripts and things to that shared folder to run manually.

Editorial conclusion

Windows Sandbox Tools fits a Windows user who analyses untrusted files, tests installers, or reproduces a bug in a disposable VM and who wants winget, store apps, and remote shell access in it without setting up a hypervisor or a VM image. It is the wrong tool if you need a persistent machine, since the sandbox is discarded on close, and it is the wrong tool for a Mac or Linux host, since the sandbox is a Windows feature. Before you build on it, read the startup script's registry changes line by line, because they are the author's personal preferences rather than a configurable baseline, and note that the store installer scripts reach Microsoft endpoints only, which is the feature that distinguishes them from similar third party approaches.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. ThioJoe/Windows-Sandbox-Tools on GitHub