Browser app settings on a PC: the three places they live

A site opens in a window with no address bar, but every link inside it jumps back to a browser tab. Notifications arrive twice. The window opens under the wrong account. Each of these has a setting behind it, and the reason they are hard to fix is that the settings are not stored in one place. They are spread across three layers that were designed independently, and the browser preferences screen only owns one of them. Knowing which layer a symptom belongs to turns a long hunt into a short one.

Three layers, and the preferences screen owns only the first

The first layer is the browser as a whole. Which browser opens a link that arrives from Mail or Slack, which signed in profile a new window belongs to, and which extensions are loaded at all are decided here, once, for everything downstream.

The second layer is the individual web app. Once a site has been installed as an app, it carries settings of its own that exist nowhere in the main preferences screen. Whether it launches at login, what its icon and name are, and what permissions it holds are attached to that one app.

The third layer is macOS. Notification style, whether the icon stays in the Dock, whether it appears in the application switcher, and whether it is allowed to launch on startup are handled by the operating system, and it treats an installed web app the same way it treats any downloaded program.

The practical consequence is that a symptom points at a layer. Something that affects every site at once belongs to layer one. Something that affects one site and not the others belongs to layer two. Something about how the window behaves next to other programs, rather than what it displays, belongs to layer three. Guides usually cover a single layer and present it as the whole answer, which is why following one carefully still leaves the problem in place.

Layer one: the two settings that everything else inherits

The default browser is set in System Settings, under Desktop and Dock, and it decides where a link goes when it is clicked outside a browser. This is the setting behind the most common complaint about site based apps, which is that clicking a link inside the app window opens a tab somewhere else. The app did not do that. The system did, because the link left the app and came back through the default handler.

The second setting is the browser profile. Chrome keeps bookmarks, history, extensions and signed in accounts separately per profile, and an app installed from a page inherits the profile it was created in. Install a work dashboard while a personal profile is in front, and the app window opens signed in as the personal account, permanently, until it is removed and installed again from the right profile.

That inheritance is worth stating plainly, because it is not reversible from inside the app. There is no account switcher in an installed web app window. The account is fixed at creation time by whichever profile was active. Anyone who runs two Google accounts, or a client account alongside a company account, should decide the profile first and install second.

Extensions follow the same rule. An app created from a Chrome profile runs inside that profile, so an ad blocker or a password manager installed there is present in the app window. An app created by a separate wrapper, which uses its own storage, starts with nothing loaded. Neither behaviour is better. They answer different needs, and the choice is made once, at the moment the app is created.

The two menu items that look alike and are not

Chrome offers two commands that both produce an icon, in the same submenu, under the three dot menu and then Cast, save, and share. Create shortcut produces a launcher that opens the page as an ordinary tab. Install page as app produces a windowed application. Chrome 128 moved the standalone window behaviour to the second command, so instructions written before that change describe a checkbox that no longer exists, and following them yields a tab.

Google's help describes what the second command produces:

A web app is an app built for the web that you can access on any device. You can use web apps to have a website work as an app and access it on your computer or mobile devices through the launcher or home screen. Source: support.google.com

Safari takes a different route. In Safari the command is File and then Add to Dock, documented by Apple as available starting with macOS Sonoma 14, and it saves the page as a web app in the Applications folder inside the home folder.

The difference that matters afterward is which browser engine the window runs on and which login it holds. A Safari web app carries the Safari session. A Chrome installed app carries the session of the Chrome profile it came from. A window built by a dedicated site to app tool holds a session of its own, isolated from both, which is what makes it possible to have three windows for the same service under three different accounts at the same time.

Layer two: the settings that live inside the app window

Once an app exists, its own settings are not in the browser preferences screen. They are reached from inside the app window, through the three dot menu at the top right, then App info, then Settings. That is where the permissions granted to that one site are listed, separately from the same site opened in a tab.

The full list of installed apps sits at chrome://apps. Right clicking an entry there exposes two options that are hard to find anywhere else. Create shortcut places a launcher somewhere on the machine, and Start on login launches that app automatically when the user signs in to the computer. Unchecking the same item turns it off.

One more behaviour is worth expecting in advance. When a site changes the name or icon of its installed app, Chrome does not apply the change silently. A notice appears in the top right of the app window offering to update, ignore, or uninstall. Google's help frames a suspicious rename or an icon that suddenly resembles another app as a reason to remove the app rather than accept the update. That is a small piece of security surface most people never see, because they accept the prompt without reading it.

The pattern across all of these is that layer two settings are per app and invisible from the main browser interface. Anyone searching the preferences screen for them will not find them, which is exactly why the search feels endless.

Layer three: what macOS decides after the app exists

Notifications are the clearest case. A site can ask for permission inside the browser, and that permission is stored per site in layer one or two. Whether the resulting alert appears as a banner, appears as an alert that stays on screen, shows a badge, or is silenced during a Focus mode is decided in System Settings, under Notifications, per application. An installed web app appears in that list under its own name, which means it can be tuned separately from the browser that created it. A site left as a tab cannot be, because to macOS it is the browser.

The Dock is the second case. An installed app has a real icon, so it can be kept in the Dock, opened from Spotlight, and reached with Command and Tab. Apple documents opening apps from the Dock as the ordinary route for any application, and the operating system does not distinguish a wrapped site from anything else in that list.

Login items are the third. Chrome exposes Start on login at chrome://apps, and macOS exposes the same idea in System Settings under General and then Login Items. Setting it in one place is enough. Setting it in both produces two launches on startup, which is a common cause of the complaint that a window appears twice every morning.

There is a fourth case that only shows up on machines with more than one display or more than one desktop space. macOS remembers window position per application, not per tab, so a site left in a browser lands wherever the browser happens to be. The same site as an installed app remembers its own position and can be assigned to a specific space by right clicking its Dock icon and choosing Options. That is the difference behind the vague complaint that a site never opens where it should.

Symptom	Layer	Where the setting is
Links open in the wrong browser	System	System Settings, Desktop and Dock
App window is signed in as the wrong account	Browser	Profile chosen before installing
Extensions missing inside the app window	Browser	Profile the app was created from
App launches at startup unexpectedly	App or system	chrome://apps, or Login Items
Alerts too loud or too quiet	System	System Settings, Notifications
Icon or name changed without asking	App	Update prompt in the app window

The settings that cannot fix what people expect them to

Three problems are commonly taken to the settings screen and cannot be solved there.

Running the same service under two accounts at once is the first. No amount of configuration inside a single installed app produces a second session, because the session belongs to the profile or the container the app was built from. Two accounts require two containers, whether that means two Chrome profiles, or two apps built by a tool that keeps a separate store for each.

Making a site work offline is the second. Whether an installed app has offline behaviour is decided by the site, not by the reader. Chrome's documentation notes that some web apps include additional storage for offline browsing, notifications, file system access and icon badges. Some do not, and no setting adds it.

Silencing notifications for one site while keeping them for another site in the same browser is a partial case. Site permissions are per site, so the permission itself can be revoked individually. What cannot be split is the delivery style, because macOS applies banner, alert and Focus rules per application, and every tab in a browser shares that browser's entry. Splitting the delivery style requires the site to have its own application entry, which is another way of saying it has to be installed rather than left open.

Recovering the address bar is the third. An app window deliberately has no URL field, and that is the point of it. Anyone who needs the address bar for part of a workflow is better served keeping a tab for that part rather than fighting the window. A short list of what a purpose built tool controls at creation time is set out on the Features page, and it is a more useful place to look than any settings screen, because these choices are made when the app is built rather than afterward.

What to change first

Start at layer one, because everything else inherits it. Set the default browser, then decide which profile each service belongs to, and only then install anything, since the account and the extensions are fixed at that moment. If several services need separate logins that browser profiles cannot cleanly keep apart, build them as separate apps instead, which is what Kagemusha does from a catalogue of more than 300 ready made presets.