Feat: Add InstallationPath registry entry

[Cocodrulo]

Description

Add an "InstallationPath" string value to the installer registry key (HKCU\SOFTWARE\Warp.dev{#MyAppName}) pointing to the installed executable ({app}{#MyAppExeName}). This records the install location for external tools and is marked with uninsdeletevalue so it will be removed on uninstall. Change applied to script/windows/windows-installer.iss.

Linked Issue

Suggestion: #8454

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Testing

The only thing you have to test is the installation

• I have manually tested my changes locally with ./script/run

Screenshots / Videos

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-NEW-FEATURE: Added the installation path into de Windows Registry
CHANGELOG-IMAGE: https://github.com/user-attachments/assets/ddb3d0bc-48d6-4a27-9df7-55e72e8b4a86

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @Cocodrulo on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

[oz-for-oss]

@Cocodrulo

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @warpdotdev/oss-maintainers.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[Cocodrulo]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[oz-for-oss]

Overview

This PR adds an InstallationPath string value under the existing per-user Warp installer registry key so external tools can discover the installed executable path, and configures the value for uninstall cleanup.

Concerns

• No blocking correctness or security concerns found in the changed installer registry entry.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[acarl005]

Hi @Cocodrulo thanks for the idea. We certainly want to integrate well into the ecosystem. First, I want to make sure I understand this specific proposal. Can you explain why this key is needed and why the one already added by our installer (Inno Setup) is insufficient?

Get-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\warp-terminal*" -Name "InstallLocation"

InstallLocation : C:\Users\dev\AppData\Local\Programs\Warp\
PSPath          : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Cu
                  rrentVersion\Uninstall\warp-terminal-stable_is1
PSParentPath    : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Cu
                  rrentVersion\Uninstall
PSChildName     : warp-terminal-stable_is1
PSDrive         : HKCU
PSProvider      : Microsoft.PowerShell.Core\Registry

[Cocodrulo]

Uninstall keys are only, or should be only, for uninstall/system management metadata. Other applications assume that if this data is available is in your own namespace not in windows one. It's more predictable. Also that registry path is not documented, in the docs "HKCU:\Software\Warp.dev\Warp" is the only one refered to.

I think is easier to other software to integrate warp terminal if the path is located in a predictable path. There are lots of apps that doesn't populate the uninstall path in windoe's registry so other apps don't event look there.

[acarl005]

"There are lots of apps that doesn't populate the uninstall path in windoe's registry so other apps don't event look there"

"Other applications assume that if this data is available is in your own namespace not in windows one"

Can you provide some examples of prominent apps that read other apps installation paths in the registry? I'd like to look into these.

Additionally, I'd like to see some examples of prominent Windows apps that write their installation path to the registry and which keys they use.

I'm consulting the official Microsoft documentation on this matter, and I've found this page. It recommends using HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths so that "applications can expose information about themselves necessary to enable certain scenarios." It appears there is a recommended registry key in the Windows namespace for this.

However, you said that, "other applications assume that if this data is available is in your own namespace not in windows one." So, I'm feeling a little conflicted. Seeing examples of popular Windows apps would help.

[Cocodrulo]

Windows Apps with paths on registry

• EpicGames:

• FiveM:

• Steam:

• Paradox:

• Microsoft OneDrive (Equipo\HKEY_CURRENT_USER\Software\Microsoft\OneDrive):

• Codeblocks:

• Python:

Applications with third party terminal

• Github Desktop: here you can find that shells like Git Bash or Cygwin has a Path registry in a different place than uninstall.

Other registry paths

I've seen other paths used for this is HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths

[acarl005]

Thank you for providing these examples. My main concern is integrating well with the dev tools ecosystem, e.g. that we work with GitHub Desktop.

Overall, I think we should do both a key under our own namespace and one under App Paths.

Having our own InstallationPath under our namespace will solve hacks like this

I think we also want one under HKA:Software\Microsoft\Windows\CurrentVersion\App Paths but that can be a separate PR. Would you like to add that one as well?

[Cocodrulo]

I can do it in this PR or another one, which one would you prefer?

[acarl005]

A separate one is better

[acarl005]

Thanks again @Cocodrulo for working with us! Hopefully GitHub Desktop can remove that hack soon.

[Cocodrulo]

Thanks again @Cocodrulo for working with us! Hopefully GitHub Desktop can remove that hack soon.

I'll do a PR there as well, I did the current hacky solution