AdGuard for Windows: a closed source blocker tracked on GitHub

The repository is a tracker, and the README says so first

The single most important line in the documentation is the disclaimer, and it is easy to skim past because it is buried in a blockquote near the top.

The README states that AdGuard for Windows is not an open source project, and that GitHub is used as an open bug tracker so users can see what developers are working on. It then points at the AdGuard team's other repositories and describes them as a lot of open source software, with a search link filtered by the open-source topic and sorted by stars.

So the repository description on the project page, which reads as an open bug tracker, is accurate, and the repository listing confirms it. The top level contains exactly two entries, .github and README.md. There is no source directory, no build system, no licence file, and no package manifest. The primary language field on the project record is listed as unknown, which is what you would expect for a repository with no code in it.

That combination is unusual enough to be worth stating plainly to anyone who found the repository by searching for open source ad blockers. You can read the tracker, you can file tickets, you can follow the release tags. You cannot read the code, you cannot build it, and there is nothing here to fork. The distinction matters more than it might seem, because an open tracker for a closed product is a genuine and useful thing, but it is a different thing from an open source project, and the marketing around some products blurs the line.

What the product claims, and how the claims are scoped

The product description in the README is short and is where the substantive claims live. AdGuard for Windows is described as the most advanced system-wide content blocker for Windows, offering all-round protection from all kinds of online ads, tracking and malvertising, and the text below the screenshots says it will not only block all types of ads in any browser and application, but also offer the highest level of online privacy protection.

The phrase that carries the technical weight is system-wide, and it is worth being precise about what that means, because it is the difference between this product and a browser extension. A browser extension filters requests inside one browser, in one profile. A system-wide blocker sits at the network layer of the operating system and filters traffic from any application that uses it, which is why the claim extends to applications and not just browser tabs. The repository includes a screenshot of an app management screen, which is consistent with a product that has to know which applications on the machine it is applying rules to.

The screenshots are from the 8.0 release line, with the main screen and the application management view, and the releases listed are v8.0.2 on 2026-10-01, v8.0.1 on 2026-09-09 and v8.0.0 on 2026-08-20. The last push to the repository was on 2026-10-14, so the tracker is being kept current even though nothing is being built in it.

The privacy claim is qualified elsewhere in the same file. The README points at the AdGuard privacy policy for Windows and summarises it: AdGuard sends only necessary, limited information, for example information required for a license check. That is a narrow, specific disclosure, and it is the one piece of the product's data behaviour that the documentation actually pins down. Whether that is sufficient depends on the tier you use and on what the filter lists themselves do, neither of which is described here.

Filter problems go to a different intake form, not to GitHub

The issue reporting instructions contain a routing rule that will save you a rejected ticket if you read it.

The documentation says GitHub can be used to report a bug or to submit a feature request, and to go to the issues page and click the New issue button. But there is a note attached to that instruction: for filter-related issues, meaning missed ads and false positives, the documentation asks you to use a separate reporting tool instead, and links to a forwarding URL on the AdGuard domain with action and app parameters that identify the product.

The reason is structural rather than bureaucratic. A missed ad is not a defect in the application, it is a gap in a filter list, and filter lists are maintained as separate data with their own update cadence and their own maintainers. Sending those reports to the application tracker mixes two different backlogs. The reporting tool presumably attaches the page URL, the elements that were not blocked, and the filter list state, none of which a GitHub issue form can capture.

This is the sort of detail that only appears in a tracker like this one, and it is genuinely useful to anyone who wants to report a problem properly. A tracker that is only used for generic bug reports and feature requests has a narrower purpose, and the routing note is what makes the difference between a report that gets acted on and one that gets closed as off topic.

Three other ways to contribute that are not code

The contribution section of the README names three paths other than filing a ticket, and all three are outside the repository.

The first is translation. The documentation asks anyone who wants to help with AdGuard translations to read their guide to translating their products first, which lives on the AdGuard knowledge base under the contributing section. Translations are the kind of contribution a closed source product can still accept, because the localisation strings are usually kept separate from the core code and the process around them is documented publicly.

The second is a general contribution page on the AdGuard website, described as a dedicated page for those who are willing to contribute, which is the funnel for everything that is not an issue report and not a translation.

The third is the beta testing programme. The README says you can submit an application to take part in the AdGuard for Windows beta-testing programme, with all necessary information on a dedicated page that takes a platform parameter for Windows. The release links at the top of the README are split into two badges, one pointing at the release list and one pointing at the pre-release list, which matches that structure: stable builds and beta builds are published side by side.

For a reader trying to understand the project, this list is informative in a way the source code would not have been. It tells you that the vendor's model is a closed application with an open feedback loop, where community input arrives as bug reports, localisation work, and early testing.

The alternative is a browser extension, and the trade is scope

The realistic alternative to a system-wide Windows blocker is a browser extension, and the difference in approach is not just marketing.

An extension installs into a browser and filters the requests that browser makes. It requires no driver, no network filter driver, no system-level interception, and it can be granted or revoked per browser profile. A system-wide blocker operates below the browser, catching traffic from every application on the machine, which is what makes it effective against in-app advertising in desktop clients, updaters, and telemetry from software that has no browser involved at all.

That extra reach is exactly what makes the system-wide approach heavier. It has to see traffic from processes the user did not intend to filter, it needs system level privileges in order to sit at that layer,. It is also the reason the product has a paid tier, since the value delivered is at the level of the whole machine rather than one browser.

There is a second difference in how problems get fixed. A filter list problem in an extension is still a filter list problem, but the filtering mechanism and the lists are often maintained by the same organisation, so the feedback path is shorter. Here, the routing split described in the tracker shows the two concerns are deliberately separated.

So the choice is not really between two implementations of the same idea. It is between blocking traffic from one application you control and blocking traffic from the whole machine. Which one is right depends on whether the unwanted requests come from a browser or from the applications themselves, and the documentation for this project does not discuss that trade at all.

No licence, no code, and a repository that will never become one

The project's record lists the licence as unknown, and there is no LICENSE file in the repository, which is the direct consequence of there being no code to license. There is nothing here to copy into your own product, nothing to audit for what the software does with your traffic, and nothing to build if the vendor stops shipping binaries.

That last point is the one to weigh for an organisation. AdGuard for Windows is distributed as a binary from the vendor's website, and the repository links to the release page and the download page on adguard.com rather than hosting anything itself. The releases in this tracker are release announcements with notes, not source tarballs. A team that needs to verify what a network filter does on their machines, or to keep the filter running after the vendor withdraws support, has no path through this repository.

The release cadence is visible from the tags alone. The 8.0 line started with v8.0.0 on 2026-08-20 and has moved through v8.0.1 on 2026-09-09 and v8.0.2 on 2026-10-01, which is a monthly patch rhythm for a mature product rather than a fast moving one. The tracker being pushed to on 2026-10-14 tells you the triage work is ongoing, which is the practical reason to keep the page in a watch list if you run the product.

The honest summary is that this repository is a window, not a foundation. It tells you what the team is doing, gives you a way to report a problem, and points at the downloads and the beta programme. It gives you nothing else, and the README is upfront about that in the first disclaimer.

Editorial conclusion

This repository suits a Windows user who wants to see what the AdGuard team is working on, file a defect against a specific release, or join the beta programme, and it is the place to look for release notes and download links for the 8.0 line. It does not suit a developer who wants to inspect, extend or redistribute the blocker, because the README states plainly that AdGuard for Windows is not an open source project, and the repository holds nothing but a README and a.github directory. Before you file anything, read the issue routing note, because filter problems such as missed ads and false positives are supposed to go through the separate reporting tool rather than a GitHub issue, and before you adopt the product itself, check the licence terms of the filter lists rather than assuming the open tracker implies open software.

Frequently asked questions

Official sources

1. AdguardTeam/AdguardForWindows on GitHub
2. Issues
3. Project website
4. README
5. Releases