Using Chrome extensions inside WebCatalog apps

This search covers two completely different questions, and the answers point in opposite directions. One is whether a Chrome extension such as uBlock Origin or 1Password can be installed inside an app that WebCatalog generated. The other is about the WebCatalog extension that lives in the Chrome Web Store, which is a separate product with a separate purpose. Sorting out which one is being asked takes a paragraph and saves an afternoon.

Two products, one name

The Chrome Web Store listing published by WebCatalog is a new tab replacement, not a bridge between Chrome and the desktop apps.

WebCatalog lets you customize your new tab with beautiful wallpapers and organize your web apps with folders and pages. Source: chromewebstore.google.com

It is a launcher for browser tabs. It puts the same catalog of services on the new tab page, adds wallpapers and widgets, and syncs that arrangement with the account. Nothing about it changes what runs inside the desktop apps, and installing it does not give those apps any capability they lacked.

The second question is the one that usually matters. The desktop apps are separate windows drawn by an engine that WebCatalog ships itself, and the practical answer there is that Chrome Web Store extensions cannot be installed into them. That is not a setting buried in a menu. It is a consequence of how the apps are built, which is worth understanding before looking for a workaround that does not exist.

Why the extensions do not follow

A Chrome extension is installed into a Chrome profile. It exists inside that profile's storage, is granted permissions there, and runs against the pages that profile loads. Anything that wants to use the extension has to be that browser, reading that profile.

WebCatalog apps are not that browser. They run on a bundled Chromium engine, packaged with the application rather than borrowed from whatever is installed on the Mac. The upside is that the apps work on a machine with no Chrome on it at all, and are not disturbed when a browser is removed or replaced. The cost is that there is no profile to inherit from, so the extension list is empty and there is no store to install from inside the window.

This has been asked for repeatedly. Feature requests titled around Chrome extension support appear on the project's public issue tracker from 2018 and again in 2020, and that repository was archived in 2022 without the feature landing. The current published feature list does not mention extension support either, which is the more reliable signal: the plan comparison runs to more than twenty rows and none of them is about extensions.

What that comparison does list is a built in ads and tracker blocker, available on the Pro and Business plans and not on the free Basic plan. Read that as the vendor's answer to one specific extension rather than to extensions in general.

The three extensions people actually miss

Most people are not asking for extensions in the abstract. They are asking about one of three, and each fails differently.

A password manager

This is the one that changes daily behaviour. Without the browser extension present, there is no in page fill, so signing in becomes copy and paste from the desktop app. Autofill features that work by talking to a recognised browser process can also fail to identify a wrapped window, and 1Password's own community forum carries reports of exactly that with WebCatalog apps. For a service signed into once a month this is a shrug. For a tool that logs out every week it is the reason the app gets deleted.

An ad or content blocker

This is the one with a real substitute. The built in blocker on the paid plans handles the common case, and for anyone whose blocker was only ever there to remove advertising, the swap is close to even. What does not survive is a custom filter list, an element hiding rule written for one badly behaved internal page, or anything else that depends on the specific blocker rather than blocking in general.

A translator or a clipper

Translation extensions, note clippers, screenshot annotators and similar single purpose tools simply are not there. The fallback is opening the same page in a normal browser window when the tool is needed, which is the exact context switch a dedicated window was meant to remove. If that happens several times a day, the wrapper is costing more than it saves for that particular site.

Routes that keep extensions available

The extension requirement narrows the field quickly, and three options survive it on a Mac.

Route	Extensions inside the app	Separate sign in per app	Cost
WebCatalog	Not available, built in blocker on paid plans	Yes, profiles	Free for 2 apps, then 5 USD per user per month
Chrome, install page as app	Yes, from the Chrome profile it was made in	No, shares that profile	Free
Safari, Add to Dock	Safari extensions only, toggled per app	Yes	Free
Wrapper built on an installed browser	Yes, from the Chrome Web Store, per app	Yes	Usually a one time purchase

Chrome's own route is the fastest way to keep extensions, because the app is the profile: whatever is installed there is present in the window. The trade is that sign ins are shared with that profile, so it cannot separate two accounts on the same service.

Safari's route on macOS Sonoma 14 and later supports Safari extensions, and they can be enabled or disabled for each web app individually, which is a genuinely useful level of control. The catch is the store. A Chrome extension has to have a Safari version, and many do not.

The fourth route is the one built for exactly this conflict. A tool that generates apps from the browser already installed, rather than shipping its own engine, keeps the Chrome Web Store in reach because the engine is Chrome, or Brave, or Edge. Extensions install as usual and can be turned on per app, while each app still gets its own profile, so two accounts on the same service stay apart. Features sets out what those apps carry, and Supported services shows how much of the setup is preset rather than manual.

What the bundled engine buys in exchange

Framing this as a missing feature makes the trade look one sided, and it is not. Shipping an engine rather than borrowing one solves problems that the other routes have to keep solving.

The first is stability across browser updates. Chrome updates every few weeks, and wrappers that point at an installed browser have to survive that: the binary moves, the version changes, and anything holding a hard path to it breaks. A bundled engine never has that problem, because nothing outside the application can move underneath it.

The second is a machine that has no Chrome. Locked down work laptops, a fresh install, a user who has settled on Safari and does not want a second browser on disk. An app carrying its own engine runs on all of those without a prerequisite.

The third is consistency across operating systems. The same app, rendered by the same engine, behaves the same on a Mac and on a Windows machine. For a team that is split across both, that is worth more than an extension, because the alternative is maintaining two sets of instructions for the same six services.

The price for all three is paid in disk, in memory, and in the extension list being empty. Ten wrapped apps means ten sets of browser processes rather than ten windows of one browser, which is felt on 8 GB of RAM and rarely noticed on 16 GB or more. Whether that is a good deal depends entirely on which of the three problems above is real for a given setup.

When keeping the site in the browser is the better answer

Not every daily site deserves a window, and the extension question is a useful filter for deciding which ones do not.

A site that needs three extensions to be usable is telling you something. If a page only works with a specific blocker rule, a clipper and a translator running together, wrapping it moves the work rather than removing it. Those sites belong in the browser, pinned, with the extensions they depend on.

A site visited a few times a week is the same story for a different reason. The benefit of a separate window comes from repetition: a fixed position in the Dock, a keyboard shortcut that always lands in the same place, notifications that can be muted without muting a browser. Something opened on Thursdays never builds that habit, and each wrapped app is one more thing to maintain when a login expires or a URL moves.

What is left after both filters is usually short. The services that are open all day, the ones that must stay signed in as a specific identity, and the ones needed while something else is on screen. Three to six is the normal answer. Running that list against the extension requirement decides the tool in a single pass, because the sites that survive the filter are precisely the ones where losing a password manager would hurt most.

A five minute test before committing

Nobody should decide this from a feature table alone. The test is short.

Pick the single service that is opened most often. Create it as an app in whichever tool is being evaluated, using the free tier. Then do three things in that window: sign in the way it would happen on a Monday morning, run whatever the daily task actually is for ten minutes, and try the one extension that matters most.

The first step exposes the password manager problem immediately. The second exposes memory behaviour and any layout differences caused by the engine. The third settles the question this article is about, without a subscription and without moving a whole workflow first. If the extension is present and the login is normal, the rest of the comparison is about organisation and price. If the login is a copy and paste ritual, that fact outweighs every other row.

Two more checks are worth adding for a work machine. Confirm that external links open in the normal browser rather than spawning windows inside the app, and confirm that notifications appear under the app's own name so they can be muted separately. Both are settings in most tools, and both are easier to fix on day one than after twenty apps exist. The published FAQ of any candidate usually answers them faster than the manual.

What to change first

Decide the extension question before anything else, because it eliminates whole categories of tool in one step. If a password manager or a specific blocker has to be inside the window, look at routes built on the browser already installed, and Kagemusha is one of them. If nothing depends on an extension, the built in blocker and the organisation features are a fair trade.