Warp on Windows' installer offers to add the Warp installation dir to %PATH%. This is because that is where warp.exe is and we want users to be able to invoke the CLI. However, there is a problem with this. I see errors like this in our update logs in Sentry:

RestartManager found an application using one of our files: DeltaForceClient-Win64-Shipping.exe

"Delta Force" is not an anti-virus or anything that has anything to do with Warp. It's a video game. We have unrelated programs loading our vcruntime DLL. When we try to auto-update Warp, Inno Setup attempts to over-write vcruntime140.dll and that fails b/c something is using it.

This is happening b/c vcruntime140.dll is on the %PATH%, which is not just for executable resolution on Windows but also DLLs. We should therefore not be adding a dir to %PATH% with so much stuff in it just for giving access to the Warp CLI.

VSCode handles this by nesting its CLI entrypoint into a bin/ subdir within its installation dir. It adds $env:LOCALAPPDATA\Programs\Microsoft\VSCode\bin to %PATH% and users invoke $env:LOCALAPPDATA\Programs\Microsoft\VSCode\bin\code which is essentially a "trampoline script" which in turn calls the real executable which lives directly in $env:LOCALAPPDATA\Programs\Microsoft\VSCode\vscode.exe.

We have 2 options:

1. Do what VSCode does and add a bin/ subdir with a similar trampoline script.
2. Instead of bundling our own copy of vcruntime, we use the Microsoft Visual C++ Redistributable to install vcruntime into the system dirs where it is meant to be shared. However, this doesn't "fully" solve the problem as we still have our own bundled conpty.dll and OpenConsole.exe which might get used by other apps.

Linear: APP-3700