Sidekickブラウザ not working: what to check, in order

Sign in loops on one service. A sidebar app that loads to a blank pane. Notifications that stop arriving without anything having changed. When Sidekickブラウザ starts behaving like this, the settings screen is the wrong first stop. A browser in this category is three layers stacked together: Chromium underneath, the product's own application layer on top of it, and the web service running inside that. The repair is completely different depending on which layer failed, and opening preferences first tends to start at the layer that is hardest to fix. The order below works from the outside in.

Check the product's status before touching any setting

Sometimes the cause is not on the machine at all. This category has a history of acquisitions and shutdowns, and Sidekick is one of them. Perplexity acquired the team in May 2025, and the product sunset on August 3, 2025. The official domain now returns a permanent redirect to a different product.

Discontinued products in this category produce a recognisable set of symptoms:

• a notice appears at launch that did not appear before
• sync of settings or sign in state never completes
• in app links to help or pricing land on a different site
• the extension list fails to load

Any of those four means local settings will not fix it. None of them means the cause sits in another layer, so move on to the next step. Reversing that order is how afternoons disappear.

The check itself takes seconds. Open the official domain and compare the address after loading against what was typed. A different domain means the product has become something else. Deeper paths redirecting the same way means the original documentation is no longer reachable, so any specification quoted in a review cannot be verified.

Worth noting: an installed copy usually still launches after a shutdown. Launching is not the same as being safe to keep using. With the underlying engine no longer updated, rendering faults and refused connections accumulate over time. A sense that problems got worse recently rather than suddenly is consistent with being partway through that process.

One test that separates the service from the app

The next question is whether the failure belongs to the web service or to the application hosting it. A single action answers it.

Copy the address of the screen that is failing and open the same address in a plain browser. Safari, or anything not normally in use. If the same failure appears there, it belongs to the service, and no amount of work on the browser changes it. If the plain browser behaves correctly, the cause sits in the application layer.

Running this first halves the search space. For a service side failure, the status page is the shortest path and every browser setting reverted along the way was wasted effort.

Two cautions apply. The plain browser will ask for a fresh sign in, so the second factor needs to be at hand. And on some services, signing in elsewhere ends the original session, which is disruptive in the middle of a working day. Both are manageable once anticipated.

Sign in failures

Once the application layer is implicated, sign in is the most common failure by a wide margin. The login screen reappears in a loop, a button does nothing, or a warning about the browser not being secure blocks the flow entirely.

For Google accounts, the conditions under which sign in is refused are published:

Don't support JavaScript or have JavaScript turned off. Have unsecure or unsupported extensions added. Are being controlled through software automation rather than a human. Are embedded in a different application. Source: support.google.com

The last condition is the one this category runs into. Signing in from a view embedded inside another application can be refused outright. Two responses work: use whatever route the product offers for completing sign in through an external browser, or keep that one service in the standard browser and leave the rest where they are. Both beat another pass through preferences.

The extension condition on that list is worth testing too. Disable every extension at once and attempt sign in a single time. If it succeeds, re-enable them one at a time until the culprit appears.

There is a separate cause behind repeating login screens. In products that isolate cookies per container, a container that is not permitted to store cookies loses the session immediately after sign in and returns to the start. If the behaviour began after privacy settings were tightened, that is the likely source, and adding the one service as an exception confirms it in a single attempt.

Blank panes and loads that never finish

When sign in succeeds but the pane stays blank, the cause sits somewhere else again. Something the service needs in order to draw itself is not loading, and three places account for most of it.

Blocking comes first. Products that ship with ad and tracker blocking enabled sometimes catch resources the service itself depends on. Disable blocking for that one service, reload, and see whether the screen appears.

Stored data comes second. In products that keep cookies and storage per container, that container's data can usually be cleared on its own. Clearing everything signs out of everything, so the scope has to be narrowed to the affected container before running it.

The clock comes third. A system time that has drifted far enough causes certificate validation to fail, and the result is a page that never appears. Confirming that date and time are set automatically in macOS takes a few seconds, which earns it a place in the sequence despite being the rarest of the three.

Notifications have three layers of their own

Notifications confuse people because three independent switches all have to be on, and any one of them being off produces identical silence. Work from the outside in.

The outermost is macOS notification settings, which are per application and include how alerts are displayed. A Focus mode that is active suppresses alerts even when permission is granted, so check that first.

Next is the browser's own per site permission. In products where each container holds its own settings, one container can have the permission revoked while another still has it. The same service in a different place is treated as a different site.

Innermost is the service's own configuration, such as Slack notification preferences or mail filtering rules. Checking in that order is the shortest route.

One structural point: if the application is quit rather than left running, web notifications do not arrive at all. Whether the app stays resident and whether it launches at login are worth confirming at the same time.

A related complaint is not silence but ambiguity, where alerts arrive and it is impossible to tell which account they belong to. That is placement rather than malfunction. Two accounts on one service inside a single container produce identical alerts, and no setting fixes it. Splitting them across containers does. How that unit is structured is described under Workspaces, and what stays isolated between them is under Features.

Finally, on a managed device, an administrator policy can suppress notifications regardless of local configuration. When all three personal layers check out and nothing arrives, that is the question to ask.

When the app will not launch, or quits on its own

A launch failure looks alarming and is usually one of a small number of things. Checking them in order avoids a reinstall that solves nothing.

Start with whether the process is already running. An application that appears dead sometimes has a window on another desktop or minimised out of view, and a second launch attempt does nothing visible. The application switcher answers that in a second.

Next, check macOS version compatibility. After a system upgrade, an application that has not shipped an update in a long time can fail to start at all. This is the point at which an unmaintained application layer stops being a theoretical risk and becomes the actual fault.

Third, look at the profile data rather than the application. A corrupted profile directory causes repeated crashes shortly after launch, and most products in this category can start with a fresh profile to test the theory. Do this only after confirming that a way back to the original data exists, because the original profile holds every signed in session.

Fourth, consider security software. Endpoint protection on a managed machine can block an application that is unsigned or signed with a certificate that has since expired, and the message shown to the user is often unrelated to the real cause. On a work machine this belongs early in the list rather than last.

If all four come back clean and crashes continue, the remaining variable is the underlying engine. Nothing on the machine fixes that, and the question becomes whether to keep working around it.

Slowness, expressed as numbers

Slow is not actionable until it becomes a measurement. Open Activity Monitor and read memory and CPU for the application. Alongside that, count the resident services and the open tabs.

• a high resident count means dropping anything opened only monthly
• one service alone consuming resources usually points at that service's own page
• everything being slow can mean the engine underneath has stopped receiving updates

Only the third case is beyond settings. Check the date of the most recent release, and if it is a year or more old, the decision is whether that state is acceptable rather than how to tune it.

While counting, note how many of the resident services were actually touched today. If that is under half the total, the weight is coming from placement rather than from the product, and reopening an occasional service on demand costs less than it seems.

Decide in advance when to stop repairing

Time disappears into troubleshooting when there is no stopping rule. Two conditions are enough. The product is discontinued, and the failure lands on daily, central work. When both hold, switch from repairing to migrating.

Writing the rule down before starting matters more than the exact threshold, because the decision gets much harder once several hours have already been spent on it.

When only one holds, working around the symptom is defensible. Moving the one service that refuses to sign in into the standard browser, and leaving everything else alone, is a legitimate outcome.

What to change first

Copy the address of the failing screen and open it in a plain browser before anything else. If it fails there too, it belongs to the service and the browser deserves no attention today. If it works, run the sign in and notification checks above in order, and if the stopping rule has been met, move the unit of separation from tabs to windows, which is what SpaceDeck is built to do.