Chromeのプロファイル not working: what to check, in order

A Chrome profile that is misbehaving is rarely one fault. Repeated sign-in prompts, links landing under the wrong identity, bookmarks that vanished, and settings that revert after a restart all present the same way on screen, and all four have unrelated causes. The expensive mistake is to start applying repair steps found for one of them to a machine experiencing another, because some of those steps delete data that was never the problem. Sorting the symptom into the right layer takes a couple of minutes and decides everything that comes after it.

Five layers hide behind one word

The word profile spans five separate systems. Discussions about profile problems go in circles because the participants are describing different layers.

Windows and links. Which window macOS hands a link to, and which window is in front when it arrives.

Sessions. Which cookie store holds the login for a given site.

Account and sync. Whether the profile is signed into a Google Account, and what that account is storing.

Files. The profile directory on the Mac and the files inside it.

Policy. Settings pushed by an administrator at an employer or a client organisation.

The same complaint maps to different layers depending on circumstances. Extensions that disappeared could mean the wrong window is in focus, or a sign-out, or an administrator removing an item from an allowlist. Each of those has a different fix, and only the fourth layer carries any risk of permanent loss. Anything that touches the files layer belongs at the end of the process, never at the start.

Three questions place almost any symptom in a layer. When did it begin. Does it happen in another profile. Does it happen on another machine. If another profile shows the same behaviour, the cause is not inside the original profile. If another machine shows it too, the cause is not in the files on this one.

Sort the symptom before touching anything

The table below places the common reports. Finding the right row first cuts the number of things worth trying by more than half.

Symptom	Layer to suspect	First place to look
Links from mail or chat open under the wrong identity	Windows and links	The window that was last in front
Signing into one account on a service drops the other	Sessions	Whether both accounts share one profile
Bookmarks or saved passwords disappeared	Account and sync	Whether the profile is still signed in
The profile picker appears on every launch	Files and settings	The show on startup option
An extension refuses to install	Policy	chrome://policy
Settings revert after a restart	Files	Whether the profile directory is writable

Most incidents that end with a recreated profile were row one. The identity was never wrong in storage. A link simply arrived in whichever window happened to be in front, and the repair destroyed a working profile to fix a routing behaviour that profiles do not control.

Check in the order that risks the least

The checking order should follow potential loss, not probability. Probability is a guess. Loss is a fact known in advance.

The first check is which profile owns the front window. The name under the avatar and the colour band at the top of the window answer it in a second. When the identity was simply misread, nothing needs repair at all.

The second check is sign-in state. Missing bookmarks and missing passwords frequently mean a profile signed out of Chrome rather than data destroyed. Google describes the behaviour directly:

When you sign in to Chrome, you can save your info in your Google Account. When you sign out of Chrome, your info is kept safe in your Google Account and removed from the device. Source: support.google.com

Removed from the device is not the same as gone. Signing back into the same account restores it. Skipping this check and rebuilding the profile instead destroys the copy that was about to come back.

The third check is policy. Typing chrome://policy into the address bar lists everything an administrator is currently enforcing. Extensions that will not install, sync that cannot be turned on, and password saving that stays disabled usually appear there. Greyed out controls in settings are the visible symptom of this layer. Nothing done locally will change them, and the useful output of this check is knowing precisely what to ask an administrator for.

The fourth check is sessions. Two accounts on one service inside one profile will evict each other, because a profile holds a single cookie store per site. Repeated sign-in prompts under those conditions are the documented behaviour rather than a fault.

Only after those four does anything justify touching the files. Deleting a profile removes its bookmarks, history, and saved passwords from the computer. On a profile that was never signed in, there is no copy anywhere else.

Startup behaviour is a setting, not a fault

Two reports arrive constantly and neither is a defect. The picker appearing at every launch, and the picker refusing to appear when it is wanted, are both governed by one checkbox in the profile management screen labelled show on startup. With it on, every launch asks. With it off, the most recently used profile opens directly.

Which setting is correct depends on the cost of a mistake. Where a wrong identity in a client console has consequences, being asked every morning is cheap insurance. Where the first profile of the day is always the same one, the prompt is a repeated confirmation of something already known.

A related report concerns the Dock. Chrome is one application, so its Dock icon carries no identity. What opens is determined by the window arrangement at the last quit, not by a preference. Getting a specific profile to open first requires a separate launcher for that profile, which is created outside Chrome's own settings screen rather than inside them.

Slow launches can also relate to profile count, because restoring the windows of several profiles at once stacks the loading. Reducing the number of windows restored and observing whether the delay changes is a reasonable diagnostic, and it costs nothing.

Create a blank profile as a control

When the layer still will not resolve, the fastest instrument is a fresh profile used as a control group. Add a profile, do not sign it into any account, install nothing, and reproduce the action that fails.

The outcome splits the search space cleanly. If the blank profile shows the same behaviour, the cause is not the contents of the original profile. It is Chrome itself, macOS, or the site. If the blank profile behaves correctly, the cause is something the original profile accumulated: an extension, a stale cookie, or a file in its directory.

Skipping this step usually leads into disabling extensions one at a time. That process is slow, and it often ends ambiguously, with the symptom gone and no certainty about which change was responsible. Establishing the control first determines whether that process is worth starting at all.

Delete the blank profile once the question is answered. Nothing was signed in and nothing was saved, so there is no loss. Leaving it behind adds an unlabelled entry to the picker, which quietly increases the chance of the mis-click that started this in the first place.

Symptoms that are not profile problems at all

A portion of what gets filed under profile trouble originates outside the browser entirely, and no amount of profile work will move it.

Session length is set by the service, not by Chrome. Administrative consoles and banking portals commonly expire a session after a short idle period, and a password change or a security event can invalidate every active session across all devices at once. When several profiles all demand a fresh login on the same morning, a server side event is a better explanation than five simultaneous local faults.

Single sign-on adds a second case. A login flow that bounces through an identity provider depends on cookies set on a domain other than the one in the address bar. Where those cookies are restricted by a content blocker, a privacy extension, or a site setting, the flow returns to the start and looks exactly like a broken profile. The test is the blank control profile described above, because it carries no extensions and no site settings.

Time is a third. A Mac with a clock that has drifted far enough will fail certificate validation and token checks, producing sign-in loops and security warnings that have nothing to do with stored data. Confirming that the date and time are set automatically takes a moment and rules out an entire class of confusing behaviour.

The reason to separate these cases early is that they are the ones where repair steps do actual harm. Clearing cookies, resetting settings, or rebuilding a directory in response to a service side expiry removes working data and leaves the symptom untouched, because the cause was never on the machine. When a symptom appears simultaneously across multiple profiles, or across a phone as well as the Mac, treat it as external until something proves otherwise.

Recurrence points at the layout, not the repair

A symptom that returns every few weeks will not be solved by refining the repair. Recurrence means something in the daily arrangement produces it on a schedule.

Three arrangements generate most of it. Two accounts on one service inside a single profile produce sign-in prompts that look random but are not. A profile count that has outgrown its visual signals, with similar colours and names too long to scan, makes mis-identification a matter of probability. High crossing frequency, where contexts alternate many times an hour, turns switching into a task in its own right and makes mis-clicks routine.

When the pattern is one of these, the target for change is the layout rather than the incident. Making each service occupy a fixed location, instead of making each identity a card in a picker, removes the routing and session symptoms structurally. The window model for that approach is described on Workspaces, and how it differs from a standard browser on Features.

Two layers survive any such change and it is worth being clear about them. Policy applies wherever a managed account signs in, regardless of the tool. Account and sync behaviour belongs to Google rather than to the browser arrangement. Expecting a different layout to resolve those leads to disappointment.

What to change first

Identify the layer before changing anything, then check in the order that risks the least data. If the same symptom keeps returning after correct repairs, the arrangement is producing it, and the next thing to evaluate is a fixed place per service, as described on SpaceDeck, with supported services listed under Supported apps and behavioural details in the FAQ.