App-V packaged Visual Studio Code fails on Windows 11 24H2 and 25H2: the --no-sandbox fix with trade-offs

We are in the process of migrating away from App-V to App Volumes over the next year. However, until the migration from Altiris to Workspace ONE UEM and App Volumes Manager is fully completed, we are keeping a number of App-V packages alive.

In our testing, Visual Studio Code packaged with Microsoft App-V stopped launching on Windows 11 24H2 and 25H2, while the same package continued to work on 23H2. Testing newer Visual Studio Code versions did not solve the problem. However, launching Visual Studio Code with the --no-sandbox switch worked immediately.

The Fix

The practical workaround is simple:

Code.exe --no-sandbox

This strongly suggests that the failure is related to Electron's sandboxed startup path on newer Windows builds, rather than a normal packaging mistake or a problem limited to one specific Visual Studio Code version.

Security Consequences

That said, this workaround has a theoretical security cost.

Visual Studio Code is built on Electron, and Electron normally uses Chromium sandboxing to isolate renderer and helper processes. When --no-sandbox is used, that layer is disabled. In plain terms, the application still runs with the same Windows user rights as before, but some of the internal process isolation is removed.

The sandbox normally ensures that even if malicious code runs inside a renderer process, it cannot escape to the main process or underlying system without exploiting additional vulnerabilities. Chromium's sandbox uses restricted tokens, job objects, and integrity levels to run renderer processes with lower privileges. This means that if a renderer is compromised—for example, through malicious JavaScript or a vulnerable extension—the damage is contained. The compromised process cannot directly access the main process, other tabs, or system resources.

With --no-sandbox, all processes run at the same privilege level as the main application. An exploit in a renderer process gains direct access to the same resources as the entire application, without needing to break through the sandbox boundary first.

It is important not to overstate what this means. Using --no-sandbox does not suddenly give the application administrator rights, and it does not automatically allow writes to protected system locations. Windows permissions still apply. App-V also still virtualizes parts of the application environment.

However, App-V isolation is not the same thing as Electron sandboxing. App-V can redirect or isolate parts of file and registry access, but it does not replace the security boundary that Chromium/Electron sandboxing is designed to provide. So while the workaround makes the application usable again, it also reduces one layer of defense.

Risk Assessment

In a tightly controlled enterprise environment, this may be an acceptable temporary workaround. The risk is lower if Visual Studio Code is used mainly for trusted local files, approved extensions, and internal repositories. The risk is higher if users work with untrusted content, external extensions, embedded webviews, or anything else that increases exposure to Electron's browser-based attack surface.

So the short version is this: the workaround works, but it should be treated as a workaround, not as a clean fix. If you deploy it, document it clearly, restrict exposure where possible, and continue testing for a proper long-term solution.