Separating work and personal browsing not working: what to check, in order

The setup worked for months. Work in one browser, personal in the other, and nothing crossed. Then a link from a work calendar invitation opened a client console under a personal account, a chat notification arrived with no indication of which side sent it, and a service that had been signed in on both sides started demanding a fresh login every morning. Three unrelated causes, one impression that the whole arrangement has broken. The steps that circulate for each of them are not interchangeable, and some of them delete data that was never involved. Sorting the symptom takes two minutes and determines whether anything needs changing at all.

A click passes through four handoffs

Nothing about a work and personal split is enforced in one place. A link clicked in a mail client becomes a rendered page only after passing through four separate decisions, each owned by a different piece of software.

The first is the operating system. macOS holds a single default web browser setting under System Settings in Desktop and Dock, and every link from every application goes to that one choice. Nothing in the link says which identity it belongs to.

The second is the browser application. Having received the link, it decides which window to use, and the rule is the most recently used window rather than anything about the link itself.

The third is the profile that owns that window. Whichever profile happens to be in front is the one that will load the page and send its cookies.

The fourth is the service. It reads the cookies it receives, finds a session, and renders the account attached to it. If the session belongs to the personal account, the service is behaving correctly.

Failures cluster at the joins rather than inside any one component. A crossing that gets reported as a broken profile is usually a correct outcome of a handoff nobody configured. Knowing which handoff produced the symptom is what separates a one second fix from an afternoon of unnecessary repair.

Sort the symptom before changing anything

The table places the reports that come up most often. Finding the right row first removes most of the candidate fixes.

Symptom	Where it originates	First place to look
Work links open under the personal account	Handoff one and three	The default browser setting, then which window was last in front
Links suddenly open in a browser that was not being used	Handoff one	The default browser setting, after an update or a new install
One service signs the other account out repeatedly	Handoff four	Whether both accounts share one cookie store
Notifications give no clue which side they came from	Outside the browser	Notification settings, and whether both sides are one application
Saved passwords offer the wrong identity every time	Outside the browser	The password manager, which is not profile aware
A specific extension refuses to install on the work side	Administrator policy	chrome://policy
A Focus mode silences both sides together	Outside the browser	Focus filters by application, not by profile

Four of these seven rows have nothing to do with the browser split and cannot be fixed inside it. That proportion is typical. Time spent reconfiguring profiles to solve a password manager behaviour is time spent on the wrong layer.

Check in the order that is cheapest to undo

Ordering by likelihood is guesswork. Ordering by what a wrong guess costs is not, because the cost of each step is known before it is taken.

First, the default browser setting. It takes five seconds to open System Settings and read which browser holds the role. Browser updates and new installations both prompt to change it, and an absent minded confirmation months ago explains a large share of sudden crossings. Nothing is lost by checking.

Second, which window is in front. Most browsers show the profile name and a colour under the avatar in the toolbar. Where the identity was simply misread, there was never a fault to repair. This is the single most common outcome of a careful check.

Third, sign in state. Missing bookmarks or a suddenly empty side usually means a profile signed out rather than data destroyed. Signing back into the same account restores what the account was holding. Rebuilding instead of checking destroys the copy that was about to return.

Fourth, whether one cookie store is holding two accounts of one service. Repeated sign in prompts under those conditions are documented behaviour, not a defect. One store holds one session per site, so the two accounts take turns.

Fifth, administrator policy. Typing chrome://policy into the address bar lists what an employer or client organisation is enforcing on that profile. Greyed out settings and extensions that will not install usually appear there. Nothing local changes them, and the value of the check is knowing precisely what to ask for.

Only after those five does anything justify deleting a profile, and the reason to keep it last is stated plainly in the documentation:

After you remove a profile from Chrome, the profile's bookmarks, history, passwords, and other settings are erased from the computer. Source: support.google.com

For a profile that was never signed in, there is no copy anywhere else. Most incidents that ended in a deleted profile were resolvable at step one or two.

Why the wrong window keeps coming forward

Step two above resolves a surprising number of cases, and the reason it fails so often is worth understanding, because it decides which of the two split styles is easier to live with.

The application switcher moves between applications, not windows. When both sides are profiles inside one browser, the switcher has one entry for the browser and cannot reach a specific side at all. Cycling windows within the front application steps through them in the order macOS maintains, which shifts as windows are used and is therefore not a route a person can aim with. When the two sides are separate applications, the switcher does reach each one directly, and that single difference is the strongest practical argument for splitting by application rather than by profile.

The Dock behaves the same way. One application means one icon, and the icon carries no identity. Clicking it raises whichever window was most recently in front, which is the same rule that sent the link to the wrong place in the first place. A Dock icon cannot be made to open a specific profile from inside the browser's own settings.

The Window menu is the one reliable target inside a single application, because it lists every open window by title and the profile name usually appears there. It is slow, but it is unambiguous, and it is the right tool when a mistake would be expensive.

Assigning each side to its own desktop is the free mitigation that holds up best. Right clicking a Dock icon and using the Options menu pins an application to a specific desktop, after which the keyboard shortcut for moving between desktops becomes a direct route to each side. This works only for the application level split. Two profiles of one browser cannot be pinned to different desktops, because the pin applies to the application.

Symptoms that live outside the browser entirely

Four behaviours get filed as split failures and none of them can be fixed by any browser setting. Recognising them early prevents a long search in the wrong place.

Password managers do not know about profiles. A vault holds credentials for a domain. Opening a login page on the work side offers every stored identity for that domain, including personal ones, because the extension sees the site and not the profile. The available responses are separate vaults, separate password manager accounts per side, or accepting that the suggestion list contains both and choosing carefully. Some managers support multiple accounts in one extension, which narrows the list without eliminating it.

Focus modes filter by application. An evening Focus that silences the personal browser works cleanly when the personal side is a different application. It cannot work when both sides are profiles inside one application, because macOS sees one application and has no concept of profiles. This limit is frequently mistaken for a misconfigured Focus and rewarded with hours of tuning.

Handoff and Continuity route links across devices. A link picked up on an iPhone and continued on the Mac arrives through the Continuity path and lands in the default browser regardless of which side was intended. Anyone splitting by application and also using Handoff will see crossings that no Mac side setting explains.

Service side session policy sets the login interval. Administrative consoles and financial portals expire sessions on their own schedule, and a password change invalidates active sessions everywhere at once. When several sides all demand a fresh login the same morning, a server event explains it better than a simultaneous local fault, and clearing local data in response removes working state without touching the cause.

Count the crossings before changing tools

A symptom that returns every few weeks after correct repairs is being generated by the arrangement rather than surviving the fix. The number worth having before deciding anything is how often the boundary is actually crossed in a working day.

Counting for one day is enough. Every time a window has to be found, a profile switched, or a link reopened somewhere else, it is a crossing. Two blocks a day, morning on one side and afternoon on the other, means the current arrangement is fine and the incidents are rare accidents. Twenty or more crossings means switching has become a task in its own right, and the mis clicks are not carelessness but arithmetic.

The second number is how many services appear on both sides with different accounts. One mail provider, one chat tool, and one cloud suite used with two accounts each is the pattern that produces the sign in prompts, and it is the pattern that profile switching handles worst, because each switch costs a window.

When both numbers are high, the target for change is the layout. Giving every service a fixed window removes the routing question rather than answering it, because there is only one place a given account can appear and nothing has to be recalled before clicking. What gets held separately per window is described on Features, and the arrangement itself on Workspaces. Two things survive any such change and are worth being clear about: administrator policy applies wherever a managed account signs in, and service side session expiry belongs to the service.

What to change first

Check the default browser setting and the frontmost window before touching anything else, since together they account for most crossings and neither costs anything to inspect. If the same symptom keeps returning after correct repairs, count the crossings for a day, and if the number is high the next thing to evaluate is a fixed place per service, described on SpaceDeck with the behavioural details set out in the FAQ.