Rename auto-updater component to "Warp Auto Updater" to avoid being mistaken for malware

[oz-for-x]

🤖 Filed automatically by @ozdotdev on behalf of @petradonka.
Source: https://x.com/petradonka/status/2068982684458557786

Summary

A user reported that Warp's auto-updater component/process has a name that can be mistaken for a malicious actor. They suggest renaming it to something clear and trustworthy such as "Warp Auto Updater".

Reported behavior

You should guys should consider renaming this to "Warp Auto Updater" - i thought this was a malicious actor at first

The current name is ambiguous enough that a user initially believed it was malware before realizing it belonged to Warp.

Proposed change

Rename the auto-updater component/process to a clearly Warp-branded, self-explanatory name (e.g. "Warp Auto Updater") so users can readily identify it as a legitimate part of Warp.

Impact

Reduces confusion and false malware suspicion, improving user trust.

Source

Reported via X / community feedback.

[oz-for-oss]

@oz-for-x[bot]

Here's what I found while triaging this issue:

Thanks for surfacing this. The request is actionable as a trust/clarity improvement, but Warp's updater naming is platform-specific, so the exact surface where the ambiguous name appears will determine the right packaging or metadata change.

I have a few follow-up questions before I can narrow this down:

1. Could you attach a screenshot or short recording of where the updater name appeared?
2. Which OS and Warp channel/version were you using when you saw it?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that feature request to make Warp's auto-update component name clearly Warp-branded so users do not mistake it for malware, but the report lacks the OS/surface where the ambiguous name appears..

Triage summary

This is an enhancement request for updater naming/branding: the reporter saw a Warp auto-update component with a name that looked suspicious enough to be mistaken for malware and suggested a clearer name such as Warp Auto Updater.

Current evidence

• The report is credible as user feedback, but it does not include the OS, Warp version/channel, the exact string shown, or the surface that displayed it.
• Code inspection shows the update flow is platform-specific rather than controlled by one shared display-name constant: macOS applies staged app-bundle updates, Windows launches the signed Inno Setup installer in /update=1 mode, and Linux uses AppImage/package-manager update paths.
• The likely fix area is updater packaging or platform metadata, but the exact file depends on whether the confusing name was shown by macOS, Windows, Linux, a process monitor, an antivirus/EDR alert, or an installer/update prompt.

Likely related files

• app/src/autoupdate/mod.rs
• app/src/autoupdate/mac.rs
• app/src/autoupdate/windows.rs
• app/src/autoupdate/linux.rs
• script/windows/windows-installer.iss
• script/windows/bundle.ps1
• script/macos/bundle
• script/linux/bundle_appimage
• script/linux/bundle_deb
• script/linux/bundle_rpm
• app/build.rs

Duplicate check

I checked open issues across the repository and recent closed issues. I found related updater requests such as #11058 and #10622, but they concern disabling updates or supporting a specific install location, not renaming an updater component to avoid malware confusion, so this does not meet the duplicate threshold.

Follow-up needed

A screenshot or the exact surface/name is needed before maintainers can route this to the correct updater packaging path.

Question reasoning

1. Could you attach a screenshot or short recording of where the updater name appeared? — The report is about a user-visible naming/suspicion issue, and the visual surface will identify whether the name is coming from an OS prompt, process monitor, antivirus/EDR alert, or installer UI.
2. Which OS and Warp channel/version were you using when you saw it? — Warp's updater implementation and packaging metadata differ across macOS, Windows, Linux, and release channels, so this is needed to route the issue to the correct platform path.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz