Google Chrome Extensions: Install, Scope, and Audit Them

Installing an extension takes about four seconds. Everything expensive about extensions happens later: the one that is quietly reading every page, the one that stopped working in a profile nobody checks, the eleven that accumulated because each solved a problem for a week. On a machine that runs Gmail, Slack, a project tracker and two admin consoles all day, the list stops being a set of tools and starts being a surface that needs maintaining.

This is the maintenance view rather than the installation view. Where extensions actually live, how to narrow what they can reach, how to tell a healthy one from one that is about to disappear, and where the whole mechanism stops being the right answer.

Extensions live in a profile, not in an account

The single most useful fact is that an extension belongs to a Chrome profile. A profile is a storage area on the Mac holding its own cookies, history, passwords, settings and extension list. Install something while a work profile is open and it exists only there. The personal profile in the next window has never heard of it.

Signing in to Chrome with a Google account carries extensions across machines, so the same profile on a second computer ends up with the same list. That is synchronisation between devices for one account. It is not replication between profiles. Two profiles on the same Mac stay independent no matter how many devices are involved.

For anyone running separate profiles for separate identities, three consequences follow.

• Every extension worth having has to be installed once per profile, and configured once per profile.
• Narrowing an extension's permissions in one profile leaves the copy in the other profile at its default setting, which is usually the widest one.
• An audit is not one list. It is as many lists as there are profiles, and the forgotten profile is where the stale extension survives.

The practical response is to stop trying to keep profiles identical. Decide which profile is the working one, install there, and let the others stay thin. Parity across profiles is a maintenance cost with no benefit.

Where the install can simply refuse

Two situations block an install outright, and both look like a broken button rather than a rule.

Private browsing is the first. Chrome's own store documentation states that extensions cannot be added while browsing in Incognito mode or as a guest, because those sessions are temporary storage that is discarded on close. An extension already installed can be allowed to run there, but that is a per-extension setting that is off by default, which is why behaviour changes when the same page is opened in a private window.

A managed device is the second. On a Mac issued by an employer or a school, an administrator can block extensions by policy, and the same documentation notes this directly. Nothing in the local interface overrides it. When an install appears to succeed and then vanishes, checking whether the browser is managed saves more time than any amount of reinstalling.

Read the permission prompt as a scope, not a warning

The install dialog lists what an extension is asking for, and most people read it as a yes or no question. It is closer to a dial, because the widest setting can be turned down immediately after installing.

Open the extensions manager, open the details for one extension, and site access can be set to one of three levels.

Site access	When it runs	Suits
On click	Only on the current tab, only when selected	Occasional tools: capture, translate, colour picker
On specific sites	Automatically, on a named list	Helpers for one internal system
On all sites	Automatically, everywhere	Password managers, content blockers

Most extensions arrive at the widest level because that is what their listing requests. Moving the occasional ones down to on click costs a single click each time they are used and removes a standing ability to read whatever page is open. For a machine that spends its day inside a customer database and a mail client, that difference is worth the small friction.

One limit is documented and worth knowing. Changing these permissions only affects sites matching the extension's host permissions. Extensions that alter lower-level network access through VPN or proxy settings are not affected by the change. Anything operating at the network layer is not controlled by a per-site toggle, so it has to be trusted or removed rather than narrowed.

Install fewer by knowing what the browser already does

A good share of installed extensions duplicate something that shipped in the browser. Checking first is faster than uninstalling later.

• Tab groups, collapsible and named, are built in. A session grouped by hand needs no extension.
• Pinned tabs stay at the left of the strip and survive restarts.
• Muting a tab, searching open tabs from the address bar, and reopening a closed tab are all native.
• Memory saver releases resources from background tabs without a third-party manager.
• Reading list and bookmarks cover most of what a save-for-later extension offers.

None of this makes extensions unnecessary. It changes the question from what would be nice to have into what the browser genuinely cannot do, which produces a much shorter list and a much smaller permission surface.

The same test is worth applying to the web applications themselves. A surprising number of installed extensions duplicate a setting that already exists inside Gmail, Slack or a project tracker, added because the setting was hard to find rather than absent. Notification rules, keyboard shortcuts, density controls and saved views are the usual examples. Checking the service before checking the store removes a dependency without losing anything.

Trust is a judgement made before the install, not after

Chrome offers one signal at install time. With Safe Browsing enhanced protection enabled, the browser warns when an extension is not considered trusted, and trust here means the extension was built by a developer following the Chrome Web Store developer program policies. Google's documentation notes that a new developer generally takes a few months to reach that status.

That detail matters because it prevents the warning from being read as a verdict. A brand new extension from a careful developer will trigger it. Treating every warning as a refusal narrows the field to established publishers only, while ignoring the signal entirely removes the one check that happens before installation.

A more useful reading combines it with what is visible on the listing. How recently the extension was updated. Whether the publisher is a company with a site behind it or an anonymous account. Whether the permission request matches what the description claims the tool does. A screenshot utility asking to read data on all sites is not necessarily malicious, but it deserves an explanation, and a good listing gives one.

Why an extension can stop working without warning

Extensions are software maintained by someone else, on a platform that changes. Two failure modes account for nearly all of the reports.

The first is corruption. The manager shows an extension as damaged and offers to repair it. If repair does not hold, Chrome's documentation points at another program modifying the extension's files and recommends running anti-malware software before repairing again.

The second is platform requirements. Chrome and the Chrome Web Store require extensions to meet current requirements, and extensions that do not meet them can be disabled. The recent example is concrete and dated: Chrome 138 was the final version supporting the older Manifest V2 format, with those extensions disabled for all users from July 2025, and all remaining Manifest V2 extensions were removed from the Chrome Web Store on 31 August 2026. Anything still installed from that era stays installed but cannot update and cannot be reinstalled once removed.

Checking exposure takes a minute. Open the manager and look for an unsupported label. Open the store listing and look at when the extension was last updated. A tool that has not shipped an update in years is not a stable tool, however well it currently works.

Assign shortcuts to the ones that stay

For the two or three extensions used every day, the keyboard shortcuts page in the extensions manager assigns a key combination to each one, with a choice between working only inside Chrome or globally across the Mac. Global shortcuts are the ones that collide, so anything assigned there should be checked against system shortcuts and against the web apps in daily use. A collision produces behaviour that changes depending on which application happens to be in front, which is a genuinely unpleasant class of bug to diagnose later.

Audit on a schedule, not on a feeling

An extension list decays quietly. A short recurring check keeps it honest, and three questions settle almost every entry.

Has it been used in the last month. Does the browser already do this. Is the reason it was installed still true. Anything failing all three comes out. Anything set to run on all sites without needing to comes down a level.

Removal has one loose end that is easy to miss. Deleting an extension removes it and its local settings, but an extension that connected to an outside service may have left an authorisation on that service's side. Revoking it means opening the connected applications list in that service's account settings and removing it there too. Skipping that leaves a granted permission attached to an account long after the tool is gone from the Mac.

The boundary extensions cannot cross

After the list is short and the permissions are narrow, one problem remains untouched. An extension runs inside a profile, so it cannot separate sign-in state. Two accounts on the same service, both live at once, is a storage question rather than a feature question, and no extension resolves it. That is why searching for an extension to hold a second Slack workspace on a different email address, or a second Google identity, keeps returning tools that reorganise tabs instead.

There is a second boundary that is organisational rather than technical. Every extension is a dependency on a third party who may stop maintaining it, may sell it, or may fall out of step with the platform. Small conveniences are fine to hold that way. The centre of a working day is a different bet.

Where the daily routine is a fixed set of web applications and several identities, giving each one a permanent place removes both problems at once, which is the design behind a browser that keeps each web app in its own window. What that covers is set out in Features, the arrangement of several identities in Workspaces, and the built-in command line in Built-in terminal. Tools in the same category differ mostly in how far the isolation goes and what it costs, which is the comparison in Compared with Wavebox and Compared with Rambox. Which services can be held that way is listed in Supported apps, and costs are in Pricing.

What to change first

Open the extensions manager in the profile used for work and read the list as a permission surface rather than a toolbox. Turn every occasional tool down to on click, remove anything failing the three audit questions, and note which entries have not been updated in over a year. If what remains is a search for an extension that holds two accounts on the same service at the same time, that search will not end well, and the arrangement in SpaceDeck addresses that layer instead.