Arcの代わり not working: what to check, in order
The new setup worked for four days. Then a Slack notification failed to arrive, a Google account signed itself out overnight, and a video call refused to see the microphone. Each of those has an obvious first suspect, and the obvious first suspect is wrong often enough to waste an afternoon. Browser problems in a multi-account setup are layered: the web service, the session, the extensions, the operating system permissions, and the machine itself all produce symptoms that look identical from the outside. The fix is not a better guess. It is a fixed order, running cheapest and most eliminating checks first, so that each step removes a whole layer rather than one theory.
Check zero: find out whether the browser is involved at all
Two minutes, and it removes the largest category of false leads.
Open the failing site in a different browser on the same Mac. Every Mac has Safari, so there is always a second opinion available. Then open it in a private or guest window of the tool that is failing.
Three outcomes, three different investigations.
It fails everywhere, including Safari. The browser is not the problem. The service is having an incident, the account has lost a permission, or something upstream changed. Checking the service's own status page before touching any settings saves the entire rest of this list.
It works in Safari and in a private window, but fails in the normal window. The problem is local state: a cookie, a cached credential, an extension, or a setting attached to that specific profile or workspace. That is the most common outcome, and the next two sections cover it.
It works in the normal window but fails in a private window. This usually means something the site requires is blocked in private mode, which is expected behavior rather than a fault.
Recording which of the three happened is the whole point of this step. Skipping it is how people end up reinstalling an application to fix a server side outage.
Check one: the session, not the application
Most failures in a multi-account setup are session failures wearing a costume.
Signed out overnight
Sessions expire on a schedule set by the service, not by the browser, and administrator policy on a work account can shorten that schedule considerably. A tool that isolates each app or profile has a separate cookie jar per container, so signing in again inside the right container fixes it. Signing in inside the wrong one produces the confusing state where the same service is signed in twice with different accounts and the link that was clicked opens under whichever one is default.
A single sign-on loop
The portal bounces back to the login page, repeatedly. Two causes account for most of these. Third party cookies are blocked, and the identity provider needs them to complete the handoff. Or two sessions for the same provider exist in the same container, and the redirect lands on the wrong one. Allowing cookies for the identity provider domain specifically, rather than turning off protection globally, fixes the first. Clearing that container's cookies for the provider and signing in once fixes the second. Google documents its own cookie and sign-in settings in the Chrome help pages, which is the right reference for anything on a Chromium base.
A service that says the browser is not supported
Some services check the user agent string and display a banner. The banner is often cosmetic, but on calls and screen sharing it can be real. Note whether the banner blocks the feature or just nags.
The general rule for this layer: if the symptom is authentication shaped, do not clear everything. Clear only the container where the problem occurs, and only for the domain involved. Clearing everything destroys the evidence and signs out every other account at the same time.
Check two: extensions, one at a time
Extensions are the second largest cause and the easiest to test conclusively.
Disable all of them, reload, and see whether the symptom goes. If it does, re-enable them in two halves, then halve the failing half again. Four rounds finds the culprit among sixteen extensions, which is faster than reasoning about which one seems suspicious.
Three categories cause most of it. Content blockers interfere with single sign-on redirects and with embedded video, since both load from domains that look like tracking. Privacy extensions that partition storage can break session persistence in exactly the way described above. Corporate extensions installed by policy sometimes conflict with a browser that is not on the approved list.
One detail that trips people specifically in this category of tools: extensions can be installed per profile or per workspace. An extension that is disabled in one container and enabled in another produces a symptom that appears in one window and not the other, which looks like a browser bug and is not. Checking the extension list from inside the failing window, not from the main settings page, is the version of this check that actually answers the question.
Check three: notifications, which have three separate switches
Missing notifications are the most reported complaint after a move, and the reason is structural. Three independent permissions must all be granted, and they live in three different places.
The first is macOS. System Settings has a Notifications section listing every application, and a browser that was installed recently may never have been granted permission, or may have been granted it and then silenced by a Focus mode. Apple documents notification and Focus behavior in its support material, and this is worth checking before anything inside the browser.
The second is the browser's own per-site permission. Each site asks once. A prompt dismissed in a hurry on day one leaves the site permanently denied, and the site will not ask again. This is per container, so granting it for a work Slack does not grant it for a personal one.
The third is the service's own setting. Slack in particular has per workspace and per channel notification preferences, plus a separate setting for what happens when the desktop app is not running, and its own documentation at slack.com/help covers how those interact.
There is also a fourth, quieter condition. Web notifications generally require the page to be loaded, so a service that has been put to sleep to save memory may not deliver anything until it is opened. Tools that hibernate idle apps often have a per app exception for exactly this reason. Anyone who moved to a tool with hibernation and then lost notifications should look here first.
Camera and microphone are a separate grant
The same structure catches people on their first video call in a new tool, and it is worth handling before a meeting rather than during one. macOS grants camera, microphone and screen recording per application, so a browser installed last week holds none of those grants even though the previous browser held all three. The website then asks for its own permission on top, which is a second prompt, and screen sharing needs the operating system grant specifically or the share appears as a blank rectangle to everyone else.
The fastest way through it is to join a test call in the new tool on a quiet afternoon, share a window deliberately, and accept every prompt that appears. Anything still missing after that is in System Settings under Privacy and Security, where each of the three has its own list of approved applications.
Check four: the engine version the site actually sees
This check is short but it explains a specific class of failures that nothing else explains.
A browser built on Chromium ships a particular Chromium version. Web services test against current releases, and some enterprise tools enforce a minimum. If a downstream build is several versions behind, a site can work perfectly for months and then start failing after the service updates, with no change on the machine at all.
Find the version in the About screen and compare it against the current stable release. The Chromium project publishes its release process at chromium.org, which makes it possible to see roughly how far behind a given build sits. A gap of one release is normal. A gap of many, in a product that is no longer receiving feature work, is a fact worth knowing, and it is the same fact that determines whether a browser that has stopped active development can stay in the workflow. Arc's own front page states that it receives Chromium updates only, and points people needing active security patches elsewhere, which is the clearest possible version of this information coming from the vendor itself.
The reason this check sits fourth rather than first is that it is slow to act on. Its outcome is usually a decision rather than a setting.
Check five: the machine, not the software
If the symptom is slowness, beachballs, fans, or tabs reloading themselves, the investigation is different.
Open Activity Monitor and sort by memory. Count the browser processes. In a multi-account setup each container is separate, so ten services means ten sets of processes, and the total climbs faster than tab count suggests. When physical memory runs out, macOS swaps to disk, and the first symptom is usually the browser discarding background tabs and reloading them on click.
Two concrete moves help before considering a different tool. Turn on whatever the tool calls sleeping or hibernating for apps that are not in use, with exceptions for the two or three that must deliver notifications. Second, count how many services are actually open versus how many are needed today, since an account left signed in for a project that ended last quarter costs memory every day.
If the machine has 8 GB and fifteen services are open, this is not a defect in any product. It is a capacity limit, and no amount of settings work removes it.
Triage table
| Symptom | First thing to check | Usual cause |
|---|---|---|
| Signed out of one account only | That container's cookies | Session expiry or policy on that account |
| Sign-in loops back to login | Third party cookie setting for the identity provider | Blocked cookies or two sessions in one container |
| Notifications missing for one service | The three permission layers, then hibernation | A dismissed prompt, or the app asleep |
| Video call cannot see camera or mic | macOS privacy permissions for the browser | Permission never granted to the new application |
| Site says browser unsupported | Engine version in the About screen | Downstream build behind current stable |
| Everything slow, tabs reloading | Activity Monitor memory pressure | More containers open than the machine holds |
The value of the table is not the causes. It is the middle column, which keeps the first action from being a reinstall.
What to change first
Run check zero on the current symptom before changing any setting, because it costs two minutes and decides which of the other checks is even relevant. If the recurring problem turns out to be accounts bleeding into each other rather than any single bug, the fix is structural rather than a setting, and per app separation of the kind SpaceDeck uses is one way to get it, with the Supported apps list showing which services already work that way.
Frequently asked questions
Why does one Google account keep signing out while the other stays signed in?
Sessions expire per account, on a schedule the service and any workplace administrator control, so two accounts on the same machine can behave differently. In a tool that isolates each app or profile, each container holds its own cookies, so the fix is signing in again inside the container where the failure happened rather than clearing everything.
Notifications worked on day one and stopped later. What changed?
Check whether the service was put to sleep by a memory saving feature, since web notifications generally need the page loaded. After that, check the macOS notification permission and any Focus mode, then the per site permission inside that container. One of those three usually explains it.
Is it worth clearing all cookies and starting fresh?
Rarely, and not as a first move. Clearing everything signs out every account at once, destroys the evidence that would have identified the cause, and costs an afternoon of signing back in. Clearing one container for one domain achieves the same repair with none of that cost.
A site says the browser is unsupported. Can that be ignored?
Sometimes. Many of those banners only check the user agent string and the site works normally. It cannot be ignored when the affected feature is screen sharing, a call, or a payment flow, since those are the parts most likely to depend on recent engine behavior. Checking the engine version in the About screen shows how far behind the build actually is.