Extension Manager: rule driven control over which browser extensions run
a chrome extension manager where you can add rules
At a glance
- What is it?
- Extension Manager is a Chrome and Edge extension that enables and disables other extensions according to rules you write, matching on URL, scenario, operating system or time. It stores everything locally, exports and imports extension lists as share text, and has no Firefox build because the browser exposes no API for the job.
- Who is it for?
- Extension Manager earns its place on a browser where extension sprawl has become the problem, since rules that switch extensions by URL or time remove the need to remember which tool should be active where. It does not suit Firefox, where no API allows enabling and disabling an extension, and it does not suit anyone who wants to launch another extension or pin it to the toolbar, since the browser exposes no API for that either.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Extension Manager automates the decision of which extension stays enabled
Most people install a browser extension for one site and then leave it running everywhere. Extension Manager takes that decision away from habit and puts it in a rule. You define a condition and an action, and the extension manager applies it: enable an extension when a URL matches, disable it when a URL matches, enable it only while a URL matches, disable it only while a URL matches, or run a custom action of your own. There is also an option to refresh the page automatically after an extension is enabled or disabled.
The matching conditions are four kinds. A URL pattern, a scenario mode, the operating system, and a time window. The scenario mode is the interesting one, because it lets the same rule express intent rather than a literal address: the extension is active while you are in a work context and inactive otherwise, without you enumerating every work URL.
Alongside the rules, the project provides the ordinary management surface people expect: one click enable or disable, grouping with batch actions, search by extension name, description, alias or note, quick jumps to the settings page, the home page and the uninstall flow, list and grid views, custom aliases and notes, and a history of installs, updates, uninstalls, enables and disables.
The audience is therefore a user with many extensions and a browser that keeps them all on at once. It is a personal productivity tool, not a fleet management console.
Everything stays in the browser, and the dependency list explains how
The project states that the code is open source and that it collects no user privacy data. The dependency list supports that claim rather than contradicting it. There is no server SDK in it, no telemetry client, no analytics package. Storage is handled by dexie and localforage, which are local database and storage wrappers, and options are synchronised through webext-options-sync, which uses the browser's own extension storage and sync mechanism.
The UI stack is React 19 with antd 6 for components, styled-components for styling, react-router-dom for routing, and @dnd-kit plus @hello-pangea/dnd for drag and drop, which is what makes reordering and grouping extensions feel native. Immutable and lodash handle state and collection work, dayjs handles dates, nanoid generates identifiers, and lz-string compresses strings, which fits a project that exports lists of extensions as share text.
Two dependencies point at features that are easy to miss. pinyin-match handles search by pinyin, so a Chinese-speaking user can find an extension by typing its romanised name, and webext-polyfill-kinda smooths over browser API differences. The extension is built on lxieyang/chrome-extension-boilerplate-react, and the repository layout follows that template: src for the source, store-assets for listing images, utils for build scripts, test for the test files, plus webpack.config.js, tsconfig.json, eslint.config.mjs and a .babelrc.
A rule table with five action types, four match conditions and one big constraint
The action set is what separates this from a plain on and off switch. Five actions are listed: open after a match, close after a match, open only if matched, close only if matched, and a custom action. The first four are the useful ones, and the difference between them is where the action is evaluated. Open after a match means the rule fires and then the extension is enabled, so the browser may already have loaded the page without that extension. Open only if matched means the extension is enabled for the duration of the match and disabled when the match ends, which is the shape most people want for a page-specific helper.
The refresh option exists because of a real browser behaviour: enabling or disabling an extension does not retroactively change the page you are looking at, so a rule that turns a tool on for a specific site often needs a reload to take effect. The project makes that reload automatic rather than leaving you to press the button.
The constraint that shapes everything else is platform capability. The project has no Firefox version because Firefox does not provide an API for enabling and disabling extensions, which the documentation states plainly and traces to an issue in the tracker. The same section explains that launching another extension from inside the manager, or pinning another extension to the browser toolbar, is impossible because the browser offers no API for it, and that those operations have to be done by hand.
So the manager controls the enabled state of extensions and nothing else. It cannot open their popups, cannot move them, and cannot launch them.
Export and import turns a browser profile into a portable list
The export feature covers more than the extension list itself. Batch export produces extension information that can be shared as plain text, as JSON, or in a custom markdown format, and it can also record or share the set of extensions you have installed. The import side reads that share text or JSON back in, which the documentation positions as a way to simplify migration and as a way to install many extensions at once.
That is the part of this project with real value for a team. Copying a working extension stack from one machine to another is otherwise a manual checklist, and the markdown format exists so that a stack can live in a document, a wiki page or a chat message rather than in a settings export.
The format choice is what makes it shareable. A plain text format can be pasted anywhere; JSON is for machines and for round-tripping; markdown is for humans reading a repository or a wiki. Since the import path accepts the share text and the JSON form, the export format is also a decision about how much structure you want to keep.
One related feature closes the loop on installation history. The manager keeps records of extension installs, updates, uninstalls, and enable and disable events, so you can see when a tool arrived and when it was last switched on rather than guessing from the list order.
Chrome and Edge builds come from two separate build scripts
The project ships as two extensions, one for each store, and the manifest makes the difference visible in the build scripts.
"build": "node utils/build.chrome.js",
"build:edge": "node utils/build.edge.js",
"start": "node utils/webserver.js",
"test": "node --no-warnings --test test/*.test.mjs",The Chrome and Edge artefacts are produced by separate scripts under utils, which is the standard pattern for a browser extension that has to satisfy two different store review processes. The webserver script serves the development build locally, and the test script runs the Node test runner over the test directory with the mjs extension.
Installation does not go through a package manager for end users. The documented paths are the Chrome Web Store listing and the Edge Add-ons listing, both linked from the README, plus an offline route through crxsoso.com for anyone who cannot reach the Chrome store directly. The README also warns that Edge review is slower, so the Edge store version can lag behind the Chrome one, which is a practical detail for anyone pinning versions across both browsers.
For contributors, the repository is a Node project with a package-lock.json, so npm install followed by the build script is the normal loop. The runtime is plain JavaScript with React components, and the type definitions for the browser API come from @types/chrome.
The APP type extension behaviour is a deprecation, not a bug
One of the FAQ entries in the README deserves to be read as a limitation rather than a curiosity. APP type extensions are being deprecated, PWA applications do not sit inside the browser extension framework, and as a result some browser APP entries do not appear in the extension manager at all. Working APP type extensions are already rare.
The practical consequence is that if you turn on the option to show APP type extensions, you will likely see many entries that cannot be started. The documentation directs you to chrome://apps to inspect the details, which is the same place the browser keeps the legacy app page.
The reference for extension and app types is a Chromium source document, and the project links it directly, which is the right level of authority for the question.
This also shapes what the manager can promise. An extension that Chrome itself treats as an app is outside the extension framework, so there is no extension identity for the manager to enable, disable, search or report history for. The listing gaps and the non-starting entries are a direct consequence of the platform change, and no configuration inside the manager closes them.
Where Extension Manager is the wrong tool
The wrong-tool cases are mostly platform cases, and they are well defined. On Firefox there is nothing to install, because the API the whole product depends on does not exist there. If your browsing happens in Firefox, this project has no answer for you, and the README explains why rather than leaving you to guess.
Second, if your goal is to open a tool quickly rather than to control whether it is enabled, the manager does not help. Launching an extension or pinning it to the toolbar has to be done by hand, so a workflow built around keyboard shortcuts to open a popup is not improved by installing this.
Third, if you want to see or change extensions on a machine you do not control, such as a shared workstation or a family computer, this is the wrong shape of tool. The rules live in the browser profile of the person who installed the extension, so they travel with the profile rather than with the machine, and a local database in the browser is where the state lives.
On licensing, the project is AGPL-3.0. That licence is the significant term here. AGPL was written with network use in mind, and a modified version of this extension distributed to users over a browser store or a self-hosted update feed carries source availability obligations that MIT or Apache-2.0 would not. The documentation does not discuss licensing, so read the LICENSE file before you fork it, and note that the project is built on a React extension boilerplate whose own terms also apply to a fork.
Editorial conclusion
Extension Manager earns its place on a browser where extension sprawl has become the problem, since rules that switch extensions by URL or time remove the need to remember which tool should be active where. It does not suit Firefox, where no API allows enabling and disabling an extension, and it does not suit anyone who wants to launch another extension or pin it to the toolbar, since the browser exposes no API for that either. Before adopting, check the rules documentation at ext.jgrass.cc/docs/intro, confirm the Chrome or Edge store version matches the release you need, and verify that the extensions you plan to automate are not of the deprecated APP type, which chrome://apps can reveal.
Frequently asked questions
What conditions can Extension Manager match on?
The documented match conditions are URL, scenario mode, operating system and time. The available actions are open after a match, close after a match, open only if matched, close only if matched, and a custom action, with an option to refresh the page after enabling or disabling an extension.
Is there a Firefox version of Extension Manager?
No. The documentation states that Firefox does not provide an API for enabling and disabling extensions, which is the core function of the project, and points to the tracker issue for the detail.
How do I install Extension Manager?
Install it from the Chrome Web Store or the Edge Add-ons store, both linked from the project README. If the Chrome store is not reachable, an offline installation path through crxsoso.com is documented. The Edge store version can lag behind the Chrome one because Edge review is slower.
How do I share or migrate my extension list with Extension Manager?
Batch export writes extension information as share text, JSON or a custom markdown format, and the import side accepts the share text or the JSON back, which the documentation positions as a way to simplify migration and bulk installation.
Why does Extension Manager not collect user data?
The project states that the code is open source and collects no user privacy data. Its storage and options handling rely on local browser storage through dexie, localforage and webext-options-sync, with no telemetry or analytics dependency in the manifest.
Can Extension Manager start another extension or pin it to the toolbar?
No. The documentation states that the browser exposes no API for launching another extension or pinning it to the toolbar, so those operations have to be performed manually by the user.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/jasongrass-auto-extension-manager)Was this useful?