複数のGmailを切り替える not working: what to check, in order
Three Google accounts in one browser work fine until the day they stop. A bookmark that pointed at a work inbox for a year opens a personal one. A document link from a client returns a permission screen even though the account it was shared with is signed in. A window that was logged in this morning asks for a password again at lunch. Each of these has a different cause, and the temptation is to apply the same blunt fix to all of them, which is to sign out of everything and start again.
That fix works often enough to feel like knowledge. It also erases the evidence, resets the ordering that caused the problem, and occasionally locks someone out of a work mailbox for an afternoon. What follows is the order that costs the least: read first, sort second, change last.
The address bar answers the first question
Open Gmail with more than one account signed in and the address carries a number: mail.google.com/mail/u/0, then /u/1, then /u/2. That number is not an account identifier. It is a position in the list of accounts currently signed in to this browser, counted from zero.
The consequence is the one that surprises people. Sign out of the account sitting at position one and everything behind it shifts forward. A bookmark saved against /u/2 now opens what used to be /u/3. Nothing was reconfigured and no setting changed. The list simply got shorter.
So the first test costs one edit and no risk. Change the number in the address bar by hand and reload. If the expected inbox appears, the account is signed in and healthy, and the fault lives in whatever stored that link: a bookmark, a saved shortcut, a message pinned in a chat channel. The repair is to stop storing numbered addresses, not to touch the accounts.
If editing the number lands on the account chooser instead, that account is not in the current list at all. That is a different problem and it belongs further down this page.
Two failures that look identical and are not
The wrong inbox opening and a permission screen appearing tend to get described in the same words, usually some version of "it opened the wrong account". They come from opposite directions.
The wrong inbox is a routing problem. The link had no account context, so the browser handed it to whichever session was first in the list. The account that should have received it is present and working.
A permission screen is an authorisation problem. The link reached a session, that session asked Google for a resource, and Google answered that this particular account has no access. The file may have been shared with a different address entirely, or the sharing may have been limited to an organisation the signed-in account does not belong to.
The test that separates them takes ten seconds. Copy the link, open a private window, and paste it. A private window has no signed-in session, so Google will ask which account to use. Choose the one that should have access. If the resource opens, the sharing is fine and the original failure was routing. If the same permission screen appears, the sharing itself is the problem and no amount of browser configuration will fix it.
The default account is a fallback, not a preference
Google resolves ambiguity by picking one account, and the rule behind the pick is documented:
Your default account is the one you signed in with first. Source: support.google.com
The same help page is unusually direct about what this means in practice. It states that when several accounts are signed in at once, Google can sometimes not tell which account is in use, gives opening a new browser window as an example of that ambiguity, and notes that settings from the default account may then be applied, naming Web and App Activity and Ads Personalization specifically. It extends the point to country-specific services such as the Play store, where the default account's country can decide what content appears.
Read that as a rule rather than as an edge case. Every link that arrives from outside the browser is ambiguous by definition. A URL in a calendar invitation, a shortcut in the Dock, a result opened from Spotlight, a document address pasted into a chat client: none of them carry a session index. All of them land on the default account. Someone who opens twenty such links a day and keeps the wrong account in first position is not experiencing a fault. The system is doing exactly what it documents.
Signing out is a repair, not a diagnostic
Changing which account is default currently requires signing out of everything and signing back in, starting with the account that should hold first position. That is a real repair and it is sometimes the right one. It is also the step that should happen last, for two reasons.
The first is evidence. Once the list is rebuilt, the state that produced the symptom is gone, so a recurrence next month cannot be compared against anything.
The second is access. Google places a warning ahead of its own sign-out instructions, advising that backup verification methods should be set up before signing out in case signing back in goes wrong. Two step verification pointed at a phone number that changed last year is the usual way this goes from an annoyance to a lost afternoon. Check the recovery methods on every account before touching the sign-out button, not after.
When the rebuild does happen, one part of it gets skipped often enough to mention. Old accounts linger on the sign-in page even after signing out, and removing them is a separate action performed from the account page. That work is per browser. The help page says plainly that the steps need repeating in any other browser where sign-in happened, so a Safari session from two years ago still holds its own stale list.
Session loss usually has an ordinary cause
Being signed out repeatedly feels like an account problem and rarely is. Three ordinary causes cover most of it.
The first is a browser set to clear cookies and site data on exit. Every quit becomes a sign-out. The setting is easy to enable by accident while tightening privacy options.
The second is an extension. Privacy and content blocking extensions clear site data on a schedule, and Google's sign-in cookies are frequently in scope. A private window is the control here, since extensions are usually disabled in it by default. If the problem disappears in a private window, disable every extension, confirm the symptom is gone, then re-enable them one at a time. The one that brings it back is the answer.
The third is organisational. A work or school account may carry a session length set by an administrator, and when that limit expires the sign-out is correct behaviour. Nothing changed locally can extend it. The clue is selectivity: personal accounts stay signed in, the work account does not, and the interval is suspiciously regular.
One reading error is common enough to flag. A symptom that disappears in a private window gets treated as proof that the browser is broken, when a private window changes two conditions at once: extensions are off and site data is not retained. That result narrows the field but names nothing. Repeating the test in a normal window with every extension disabled changes one condition instead of two, and only then does the outcome identify a cause.
Extensions deserve one clarification because they cause a separate confusion. An extension belongs to the browser profile, not to a Google account. Switching accounts inside one window does not change which extensions are loaded. If an extension appears to work for one account and not another, the setting to inspect is that extension's own per site permissions.
The phone runs its own rules
Fixing the Mac and expecting the phone to follow wastes an evening. The Gmail mobile app manages accounts through its own mechanism. It does not share the desktop's session list and it does not inherit the desktop's default account. Google's help page states the position directly, noting that on mobile devices the default account varies depending on the device operating system and the app being used.
Two further behaviours now differ by entry point rather than by preference. Adding or syncing a third-party email account is no longer available in Gmail on the web, while the same capability continues in the mobile app. Someone hunting on a Mac for a setting a colleague described from a phone may be looking for something that is no longer there.
Where each symptom actually lives
| Symptom | Where it lives | First thing to check |
|---|---|---|
| A bookmark opens the wrong inbox | Session index in the URL | Edit the number by hand |
| Shared link returns a permission screen | Sharing, or the default account | Open the link in a private window |
| Signed out after every quit | Cookie on exit setting | Browser privacy settings |
| Signed out at regular intervals | Administrator session length | Ask the administrator |
| Notification gives no account | macOS notifies per application | Nothing to configure |
| Extension works in one account only | Extension site permissions | That extension's settings |
| Mac and phone disagree | Two independent systems | Set each device separately |
The fifth row is the one with no repair, and it is worth saying plainly. macOS attaches notifications to applications. Several accounts inside one browser produce one icon, one name, and one badge number covering all of them. No preference inside the browser changes that, because the boundary the operating system can see is the application, not the tab. Approaches that give an account its own window exist because that is the only place the distinction can be expressed, and Workspaces sets out what that looks like in practice.
What recurrence is telling you
A symptom that returns within a week was not really fixed. Index shifts, default account confusion and shared cookies are properties of keeping several accounts in one storage area, so repairing them one at a time is maintenance rather than repair. Counting the repairs is the useful measurement: when the time spent on them exceeds the work of separating the accounts, the boundary is in the wrong place.
Separation has stages. Browser profiles split the stored data, which ends index shifts and cookie collisions at no cost. Binding an account to a window goes further, since links and notifications then resolve to the window rather than to a position in a list. The trade offs between products that do this are mostly about supported services and free tier limits rather than the idea itself, which is why Compared with Shift reads as a feature table.
What to change first
Start with the cheapest test on this page: edit the session number in the address bar and see whether the account is actually healthy. If it is, stop treating this as an account fault and fix what stores the link. If the same symptoms return every week regardless, the repair to make is structural rather than local, and SpaceDeck describes the version of that boundary where each account keeps its own window.
Frequently asked questions
Why does the number in the Gmail address change on its own?
The number is a position in the list of accounts currently signed in to the browser, counted from zero, not a permanent account identifier. Signing out of an account shifts every account behind it forward by one. Bookmarks saved against a specific number will then open a different inbox, even though nothing about the accounts changed.
Can the default Google account be changed without signing out of everything?
Not currently. The default is the account signed in first, so changing it means signing out of all accounts and signing back in with the intended one at the front. Before doing that, confirm that recovery and two step verification methods are current on every account, since the sign-out is the point where an out of date phone number becomes a lockout.
How do you tell a routing problem from a sharing problem?
Open the failing link in a private window, which has no signed-in session, and choose the correct account when prompted. If the resource opens, the sharing is fine and the original failure was the browser sending the link to the wrong session. If the same permission screen appears, the file was shared with a different address and no browser setting will help.
Why does the Mac stay signed in but the work account keep dropping?
That pattern points at an administrator setting rather than anything local. Work and school accounts can carry a session length defined by the organisation, and when it expires the sign-out is expected behaviour. The giveaway is that personal accounts are unaffected and the interval repeats predictably.
Do fixes applied on the Mac carry over to the phone?
They do not. The Gmail mobile app keeps its own account list and its own default, and Google's documentation notes that the default on mobile depends on the device operating system and the app in use. Any arrangement worth having needs setting up once on each device.