Chrome keeps signing me out: where the session goes

Chrome keeps signing you out, and the frustrating part is that it does not seem to follow a rule. Some mornings everything is still signed in. Some mornings Gmail, the project tracker and the bank are all asking for a password again, and the two-step code has to be found for each. Most advice on this starts by listing fixes to try, which is the wrong order, because there are five different causes with five different fixes and trying them in sequence teaches nothing about which one was at work. The useful starting point is what a sign-in physically is.

A sign-in is a cookie sitting in a profile

When a site is signed into, the site hands the browser a small piece of data and the browser keeps it. Every subsequent request carries it, which is how the site knows the visitor is the same person as five minutes ago. Nothing else is happening. There is no permanent relationship between a browser and an account.

Google's documentation states the consequence in one sentence, and it explains most cases of unexpected sign-outs on its own.

If you delete cookies, you may get signed out of sites that remember you. Source: support.google.com

The second half of the picture is where that cookie is kept. It is kept in a Chrome profile, not in Chrome. Profiles each hold their own bookmarks, history, passwords, and other settings, and each holds its own cookies. Two profiles on the same machine are, from a website's point of view, two different visitors on two different computers.

A sign-out is therefore never mysterious in principle. Either the cookie was thrown away, or the request came from a place the cookie is not. Every case below is one of those two things.

The five things that throw a session away

What it looks like	Likely cause	Where to look
Everything signs out at once, repeatedly	Cookies and site data are being deleted, by hand or by something scheduled	Whatever clears browsing data, including cleanup utilities outside Chrome
One particular site signs out, others are fine	That site relies on third-party cookies that are being blocked	Third-party cookie settings and the exceptions list
Nothing is ever signed in from the start	The window is Incognito or Guest	The profile menu at the top right
Sites are signed in, but as the wrong person	The window belongs to a different profile	The profile icon and the profile name shown there
Every Google site signs out together	Chrome itself was signed out of	The profile menu, and whether the account is still present

Cookies are being deleted

This is the most common cause and the least often suspected, because the deletion is usually not a deliberate act each time. It is a setting that was turned on once, or a cleanup tool running on a schedule, or a habit of clearing browsing data when a page misbehaves. The symptom is characteristic: everything goes at once, and it goes at a consistent moment, such as after a restart or after a cleanup tool runs.

The test is simple. Sign in to two unrelated sites, close and reopen Chrome, and see whether both are still signed in. If both are gone together, nothing is wrong with either site, and the search should move to whatever is emptying the cookie jar.

Third-party cookies are blocked and the site needed them

Chrome allows third-party cookies to be blocked, and the documentation is specific about the effect: if third-party cookies are blocked, all third-party cookies from other sites are blocked unless the site is allowed on an exceptions list. Plenty of business tools sign a person in through a separate identity provider, which means the sign-in involves a domain other than the one in the address bar.

The signature of this cause is that it affects some sites and not others, and that it affects the same sites every time. The remedy does not require turning the protection off wholesale. Chrome maintains a list of sites allowed to use third-party cookies, and the documentation notes that sites on that list can use third-party cookies in both regular and Incognito browsing modes. Adding the handful of tools that need it is a narrower change than switching the setting back for everything.

The window was never a normal window

Incognito and Guest both end their sessions deliberately. In Incognito, cookies and site data are kept temporarily so pages work, and removed when the session ends. Third-party cookies are blocked there by default, which is a second reason a work tool may refuse to stay signed in. Guest goes further: browsing history, cookies, and site data are deleted when the guest window closes.

This sounds too obvious to be a real cause, and it is a real cause, because a window opened days ago in Incognito looks like any other window. The profile menu at the top right settles it in one glance.

The request came from a different profile

A profile is a separate cookie jar, so a site signed in under one profile is not signed in under another. On a machine with a personal profile and a work profile, opening a link from a mail client or a chat application hands the link to whichever profile Chrome happens to open, and the result is a sign-in prompt that seems to come out of nowhere for a site that was working a minute ago.

The tell is that the site is not merely asking for a password but asking as if it has never met the visitor, and that it works normally in the other window.

Chrome was signed out of, which signs out of Google everywhere

For Google's own services there is an extra connection, and the documentation states it directly: to sign out of a Google Account on all websites, sign out of Chrome. That is a single action with a very wide effect. Anyone who signs out of Chrome to tidy something up should expect Gmail, Calendar, Drive and YouTube to go with it in that profile.

Signing in to Chrome is not the same as signing in to a site

A large share of the confusion around this comes from two different sign-ins sharing a word. Signing in to a website gives that website a cookie. Signing in to Chrome connects the browser itself to a Google Account so that bookmarks, passwords, and more are available across devices, and so that Google services can be signed in to automatically.

The documentation is clear that the second one is a choice rather than a consequence of the first. When signing in to a Google Account through a service such as Gmail, there may be a prompt asking whether Chrome should be signed in as well, and signing in to Chrome is optional.

The practical consequence is that the two can end up out of step. If Gmail was signed out of on the web, or if the account has fallen into an error state, the documented action is to remove the account from Chrome and add it again rather than to keep retrying the sign-in on the site. Repeated sign-outs affecting only Google properties, in a profile that is otherwise healthy, usually sit here.

When the real cause is the number of accounts

There is a case that none of the fixes above resolves, and it accounts for a lot of the reports that sound like a Chrome fault. Someone runs two or three accounts on the same service, on one machine, in one profile. The service permits account switching, and the browser has one cookie jar per profile, so the accounts take turns occupying it. Signing in to the second account pushes the first one out, and the experience is of a browser that keeps signing a person out at random, when what is actually happening is two sessions competing for one slot.

Chrome's answer is a profile per account. Each profile keeps its own bookmarks, history, passwords, and other settings, so each holds its own session and none of them displaces another. The cost is stated plainly in the documentation and is not reversible, so it is worth reading before experimenting: after a profile is removed from Chrome, that profile's bookmarks, history, passwords, and other settings are erased from the computer.

The second cost is not documented anywhere because it is not technical. Three profiles means three Chrome windows that look identical, each with its own set of tabs, and every link that arrives from outside the browser landing in whichever one Chrome chooses. Keeping several accounts signed in simultaneously without maintaining a window per account is the problem the Workspaces arrangement is built around, and which services can be kept in separate panes this way is worth checking against a list of supported apps before rearranging anything.

Why the cost is not the password

The reason this particular annoyance outweighs its apparent size is that a sign-in is rarely just a password any more. A site that has lost its cookie usually asks for the password, then a second factor, then sometimes a device confirmation. A saved password fills the first field instantly and does nothing for the rest. Multiply that by the number of tools a working day touches and the tax is paid in attention rather than in minutes, since each interruption arrives in the middle of something else.

The same loss takes other things with it. Cookies do not only carry sign-ins. They carry the small state a site keeps about a visitor: which view was selected, which notice was dismissed, which language was chosen, which of several workspaces was last open. Deleting cookies to solve one stuck page resets all of that across every site in the profile. That is why clearing browsing data is a poor reflex for a misbehaving page, and why Chrome offers a per-site route instead. Clearing data for the one site that is stuck leaves every other session intact.

Anything installed that manages cookies deserves the same scrutiny as a Chrome setting. An extension with permission to read and change site data can remove cookies, and so can a general-purpose cleanup application running outside the browser on a schedule. Both produce the signature of broad, simultaneous sign-outs at a predictable moment, and neither shows up while looking through Chrome's own settings. If the two-site test points at wholesale cookie deletion and nothing in Chrome's settings accounts for it, the cause is almost always outside Chrome.

There is one more source worth ruling out because it is quick to check and produces confusing results: a clock that is wrong. Cookies carry expiry times, and certificate validation depends on the current date. A machine whose clock has drifted well away from the correct time can cause sessions to be treated as expired the moment they are created, which looks exactly like a browser that refuses to stay signed in. Confirming that the date and time are set automatically takes a moment and removes a whole category of guessing.

Working through it in order

Rather than trying fixes, establish which of the two possibilities is in play.

First, determine whether the loss is broad or narrow. Sign in to two unrelated sites, quit Chrome, reopen it. Both gone points at cookie deletion. One gone points at that site's use of third-party cookies.

Second, determine whether the window is what it appears to be. Open the profile menu and read it. Guest offers Close guest, a normal window shows a profile name, and Incognito is marked.

Third, if the loss is confined to Google services, treat it as a Chrome sign-in matter rather than a cookie matter, and remove and re-add the account rather than retrying on the site.

Fourth, if everything checks out and sessions still displace one another, count the accounts in use on the affected service. Two accounts in one profile is not a fault to be fixed but an arrangement to be changed.

What to change first

Run the two-site test before changing any setting, because it separates cookie deletion from a single site's requirements in under a minute and nothing else does. If the answer turns out to be several accounts competing for one cookie jar, the change worth making is structural rather than a setting, and a browser that gives each account and each web app its own persistent session, as SpaceDeck does, removes the competition instead of managing it.