Sidekickブラウザ: the setup order that holds up

Most people searching for how to set up Sidekick the browser want to know which buttons to press. That part has expired. The product was sunset on August 3, 2025, and its official address now returns a permanent redirect to a different company's product, so no installer and no settings screen remain to describe. What survives is more useful anyway: the order in which this kind of browser has to be configured. Get the order wrong and the work gets redone, whichever product ends up being used.

Check that the product still ships before reading any guide

The first step in setting up anything in this category is not a setting. It is a check. Open the vendor's site, confirm the download page resolves, look at the version date, and see whether the documentation has been touched recently. If the address redirects or the download link is dead, no configuration guide is worth reading.

For Sidekick specifically, a request to meetsidekick.com returns HTTP 301 to a different product. The team joined Perplexity in May 2025 and the browser stopped a few months later. Old installers still circulate on third party download sites, and they will run, but a browser that no longer receives updates also stops receiving security patches. That makes it a poor host for a work Gmail and a password manager.

Two minutes on this check saves an afternoon. It is the same two minutes worth spending on every candidate before installing any of them.

What a sunset changes for someone still running it

A discontinued browser does not stop launching on the day it is announced. That is what makes this situation slow to notice. The window opens, the logins are still there, and nothing on screen says anything has changed. The change is underneath.

Browsers in this category are built on Chromium, and Chromium ships security fixes on a continuous cycle. A product that has stopped shipping stops pulling those fixes in, so the gap between the installed engine and the current one widens every few weeks. A browser is the one application that renders untrusted code from strangers all day, which is why that gap matters more here than it would in a text editor.

There are two practical consequences worth checking rather than assuming. Extensions installed from the Chrome Web Store keep working until they require a newer engine or drop support for the older extension format, at which point they fail without much explanation. And sites that depend on recent browser features start rendering incorrectly before they stop working outright, which shows up as a login loop or a button that does nothing.

The order to handle it in is the same order used for a fresh setup, run in reverse. Export first, while the product still opens: bookmarks to HTML, passwords to CSV, and a written list of which accounts sat in which container. Then move the accounts that carry the most risk, meaning anything with payment details, employer credentials or client data. Personal accounts can follow at a slower pace.

Keep the old install until the replacement has run for a week. Nothing about a sunset requires deleting it that day, and having it available makes recovering a forgotten login trivial.

The order that most setups get wrong

The common failure is installing first and thinking second. The first screen usually says something like "pick the apps you use", and it is easy to tap through Gmail, Slack and Notion in sequence. The interface is designed to make that easy, which is exactly why it causes trouble later.

Registering an app fixes which container it belongs to, and a container is the unit that separates logins. Moving an app to a different container afterwards means signing in again, which means going through two factor authentication again. Doing that for ten apps after realising the layout is wrong is an hour that did not need spending.

There is a second consequence that is easier to miss. Judging a free tier by how many app slots are left produces the wrong answer, because the constraint is rarely app slots. It is identities. A setup can be comfortably inside a ten app allowance and still require a paid plan, and finding that out after the trial ends is a poor sequence.

The reverse also holds. Counting identities before installing anything eliminates roughly half the candidates from a pricing page alone, without downloading anything. Installing and configuring a product to evaluate it costs far more than thirty minutes each, so the candidates that can be ruled out on paper should be ruled out on paper.

The working order is: count identities, cut containers, then add apps. Done that way, every login happens once.

Step one: count identities, not services

Open a plain text file and list every login that needs to stay signed in through a normal working day. Count email addresses and account names, not product names. The same service appearing on several lines is correct and is the entire point of the exercise.

A typical list runs: company Gmail, personal Gmail, a client issued Google Workspace, internal Slack, client Slack, personal Notion, team Notion, plus single entries for a calendar, a tracker and an expenses tool. That is ten lines from six services, and the gap between those two numbers is where most free tier misjudgements come from.

Mark each line twice while writing it. First, work or personal. Second, whether an interruption from it is genuinely wanted. Those two marks get used directly in step two and step four, so making them now avoids reopening the question later.

One detour is worth heading off here. Private or incognito windows look like a free solution to the second account problem, and they are not built for it. Chrome describes the purpose of the mode as browsing the web more privately, which means the session is designed to disappear when the window closes. A tool intended to forget is a poor container for something that needs to stay signed in for months. Private windows remain useful for a one time check in a second account, and unusable as a daily arrangement.

Step two: decide the containers before installing anything

Look at the list and group the lines. The axis is context, not category.

• One container for the employer: company Gmail, internal Slack, team Notion.
• One container per client, holding whatever credentials that client issued, so switching clients is a single action.
• One container for personal use, fully separate from anything work related.

Two questions decide the edge cases. The first is whether the credentials involved came from the same organisation, because credentials issued by one party belong together regardless of which service they unlock. The second is whether the two things ever need to be visible at the same moment. An invoice tool that gets opened while looking at a client's project belongs in that client's container, not in a separate finance container that forces a switch mid task.

Grouping by category instead produces a container called "all email", which defeats the purpose. Grouping by context means the switch lines up with how the day is already divided, so changing context is one keystroke instead of six tab hunts.

The mechanism underneath is cookie isolation rather than window management, which is what makes two accounts of one service coexist without either logging the other out. The Workspaces page explains that separation in terms of the mechanism rather than the feature name, which is the level at which these products should be compared.

Once the container count is fixed, put it against each candidate's free tier. Needing four containers when a product offers two for free is a paid decision on day one, and now it is a known one rather than a surprise in week three.

Step three: separate residents from traffic

With containers decided, fill them. The only rule that matters here is to keep permanent residents and passing pages apart.

Residents go on the fixed surface, whatever the product calls it. Mail, chat, calendar and the project tracker qualify, because they are open from morning to night. A fixed position is what removes the act of searching, and it is what makes a keyboard shortcut worth learning.

Traffic stays in ordinary tabs. Research, a document opened once, a link from a colleague. Mixing the two puts residents at the mercy of whatever is being read right now, and a resident that moves is not a resident.

Order the residents by frequency, highest at the top. Most products in this category assign number keys down the rail in order, so putting the app opened thirty times a day in the first slot and the weekly one further down means the shortcuts get learned without effort. Reordering later is possible and costs relearning, so it is cheaper to decide now.

Set a personal ceiling on resident count as well. A product may allow twenty, but recall by position tops out around eight for most people. Past that the rail becomes something to scan, which is the situation the tab strip was already providing for free. Anything that does not earn a permanent slot belongs in traffic.

Which services can be pinned at all varies by product, so checking a list such as supported apps before committing saves finding out mid setup that a critical tool is not covered.

Step four: route notifications last

Notifications come after the layout, not before. Configured first, they cannot be conditional on a container that does not exist yet, which is precisely the condition most people want: personal alerts silenced during working hours.

Two passes are needed. The first is inside each service, turning off the categories that never justify an interruption. The second is in the browser, deciding which containers may raise anything at all.

The second mark made in step one pays off here. A ten line identity list usually reduces to about three lines that deserve to interrupt. The rest can be checked when there is a reason to check them, which is a different activity from being pulled into them.

Badges deserve an explicit decision too. A permanent unread count in the corner of the screen pulls attention at moments nothing was being asked. Turning the numbers off and choosing when to open each app is what converts a tidy layout into recovered concentration. Whether a given product exposes these controls separately is worth checking on a feature list such as features before assuming it does.

Step five: confirm the exit before investing in the entrance

The last step is the one most often skipped, and it is the cheapest insurance available. Before building anything elaborate, confirm what can be taken out.

• Bookmarks exported as an HTML file.
• Passwords exported as CSV.
• The container and app layout exported as a file another machine can read.

The first two are standard on anything built on Chromium. The third is rare, and its absence means the layout exists only inside that product. That is why the identity list from step one should be kept rather than deleted once setup finishes. It is the only portable copy of the design, and it doubles as the rebuild instructions for whatever comes next.

There is one more thing worth doing on the day the setup is finished, and it takes five minutes. Write down what the arrangement is supposed to achieve, in one line per container. Something like "client work stays signed in and does not appear during personal hours" is enough. Six months later, when an app has crept into the wrong container and nobody remembers why the split existed, that line is what makes the correction obvious instead of arbitrary.

Then plan a single review. Put a reminder a month out to check three things: whether any container has collected apps that belong elsewhere, whether any resident has stopped earning its slot, and whether any notification permission granted during setup is still justified. Layouts drift because work drifts, and a monthly correction takes a few minutes while an annual one turns into a rebuild.

Anyone whose day includes a command line should check one more row before settling in. Consolidating nine web apps still leaves a tenth window if the terminal lives outside the browser, and that switch survives every other improvement. Whether a product addresses it at all is visible from a page like built-in terminal.

What to change first

Write the identity list before installing anything, then group it into containers on paper and check that count against each candidate's free tier. Products that cannot hold the list are eliminated without a download. For whatever survives, including SpaceDeck, confirm the export options exist before spending an evening on the layout.