MSEdgeRedirect: one AutoIt script, five uninstall paths, and a release from last year

It filters Edge process arguments instead of owning the protocol handler

The design decision is in the second paragraph of the readme and it is the whole reason the tool exists in this shape. Rather than hooking into the microsoft-edge: handler, the tool filters and passes the command line arguments of Microsoft Edge processes into the default browser instead, and the stated reason is that this should provide resiliency against future changes. A protocol handler registration is a single point in the registry that anything can overwrite and that an update can restore; watching process launches is a different kind of intervention. A second mode is also available, an Image File Execution Options mode that operates similarly to the old EdgeDeflector, and additional modes are planned for future versions. The scope is stated just as narrowly as the mechanism: it only redirects links that attempt to open in MS Edge, and it will not affect results generated within other applications.

The whole tool is an AutoIt script you compile yourself

The compiling instructions are four steps: download and run the AutoIt Full Installation from the official site, get the source either by downloading a zip or cloning, right click MSEdgeRedirect.au3 in the MSEdgeRedirect directory and choose Compile Script (x64) or the x86 option if you have a 32 bit Windows install, and the result is MSEdgeRedirect.exe in the same directory. So the shipped binary is produced by the AutoIt compiler from a script you can read, and the primary language recorded for the repository is AutoIt. That is unusual for a utility of this kind and it is the reason the source can be inspected before it runs. Two script files sit at the root, MSEdgeRedirect.au3 and a wrapper variant, with an Includes directory and a .gitmodules file beside them.

The last release is over a year older than the last push

The release history and the commit history disagree in a way worth naming. The newest tag is 0.8.0.0, dated 2025-03-27, and its release title is a statement about the project's status rather than a description of it: Reports of my project's discontinuation are greatly exaggerated. The two before it are older patch releases, 0.7.5.3 on 2023-12-31 described as Discover and Hotfixes, and 0.7.5.2 on 2023-12-22 described as an Installer and Settings hotfix. The last push to the default branch was 2026-06-24, so the source has moved for well over a year without a tagged release, and the repository is not archived. The readme carries a beta warning in capitals saying changes are to be expected and performance to be improved, which is consistent with a project that ships a stable download and works on the rest.

The testing download is a workflow artifact pinned to a dev branch

Two download links are offered, a stable one pointing at the latest release asset for MSEdgeRedirect.exe and a testing one. The testing link is not a release at all: it goes through a nightly build service to a workflow named MSER and names a branch, 0.8.1.0-dev, from which a zip named mser.zip is fetched. So the current line of development is version 0.8.1 while the newest tagged release is 0.8.0.0, and the way to obtain that work is a build artifact from a continuous integration run rather than a published file. That is a reasonable pattern for a small utility, and it does mean there is no checksum, no signed installer and no release note for what you are downloading. Anyone who needs to verify what they are running has the compile-from-source path instead.

Removing it is documented four ways, including a script for a broken install

The uninstall section is split into normal installs and package manager installs, and the normal side splits again. A regular install is removed through Programs and Features. A corrupted one is handled by a separate PowerShell cleanup script fetched from the Assets directory of the repository. The package manager side gives the matching command for each of the three managers the tool is distributed through. Having a dedicated recovery path for a corrupted install is unusual for a utility this small and speaks to what the tool does to the system: a launcher filter and, in Image File Execution Options mode, a registry entry that points at a debugger, which is exactly the kind of configuration that can survive an attempted removal. A tool that is hard to uninstall cleanly is a reason to read the removal section before installing, not after.

Three package managers and a repository field for vulnerability reports

Distribution runs through Chocolatey, Scoop and winget, with the readme giving the install command for each, including adding the extras bucket before installing under Scoop. Chocolatey and Scoop also link a repology page for the project, and winget links its winget-pkgs manifest. That is a wide net for a single developer utility and it means the common case never touches the GitHub release page. The system requirements are correspondingly modest, with Windows 10 as the minimum operating system and a CPU capable of SSE3, moving up to the latest Windows 11 build and a 64 bit dual core or better as the recommendation. Memory is listed as 40MB free at minimum and 100MB free recommended, and storage as 5MB free minimum against 100MB free recommended. The gap between the minimum and recommended storage figures is twenty times, which is worth noting for anyone installing it on a locked down or provisioned machine. At the repository root there is a security.txt file, which is the standard location for vulnerability disclosure contact details, sitting next to CONTRIBUTING.md and the LICENSE. The license is LGPL-3.0, and the readme states the tool is free and open source software using that license with the full text in the LICENSE file.

The FAQ assumes Edge stays installed and Bing stays the search engine

Two entries in the FAQ settle most of the boundary cases. The first covers not appearing in the how do you want to open this menu, and the answer is to select the Featured Microsoft Edge, after which the tool still functions properly. The second covers whether it works with Edge uninstalled, and the answer is that it retains a needed component, is compatible with a third party Edge removal tool, and if Edge was removed by another method you reinstall Edge Stable and run that tool, after which installing MSEdgeRedirect is detected automatically. So the tool expects Edge to exist, with at least one component retained. The third entry bounds the search side: searches inside other applications still use Bing, and since version 0.5.0.0 you can select one of eight available search engines or set your own. Another entry gives a one step diagnostic: run microsoft-edge:https://google.com through the Windows and R keys, and if that is not properly redirected, file a bug report.

Editorial conclusion

MSEdgeRedirect suits a Windows user who keeps Edge installed for work but wants links to open somewhere else, and its main argument is durability rather than features: filtering process arguments instead of owning the protocol handler is less likely to be undone by a future Windows or Edge change. Three things to weigh first. The project labels itself beta and says performance is still to be improved, so treat it as something you may revisit. The last release is 0.8.0.0 from March 2025 while the source has moved since, so current changes come from the testing build, a workflow artifact rather than a tagged download, or from compiling the source yourself. And if you do not need extra features or want to disable web search entirely, the author points at two other projects that may fit better.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. rcmaehl/MSEdgeRedirect on GitHub
4. README
5. Releases