Why Chrome opens a new window instead of the one you had open
Short answer: every way of reaching a Chrome profile from outside Chrome
— a Dock shortcut, an Automator app, open -na, a URL handler — is a launch
request, and Chrome answers a launch request by creating a new window. Chrome exposes no
command, flag or API meaning "focus the window this profile already has". Returning to an
existing window has to be done through macOS itself, by finding that window and focusing it.
On this page
What people expect versus what happens
The setup is always the same. You keep two or three Chrome profiles — Personal, Work, maybe a client. You build a Dock shortcut for each, usually with Automator running something like this:
open -na "Google Chrome" --args --profile-directory="Profile 1"You expect it to behave like every other Dock icon on your Mac: click it, and the thing you were doing comes forward. Instead you get a brand new empty window, on top of the four you already had. Click it again tomorrow, get a fifth. The shortcut is technically doing what you asked and is still useless.
Why the -n flag is not the culprit
The usual first theory is that -n ("open a new instance") is to blame, so
people drop it:
open -a "Google Chrome" --args --profile-directory="Profile 1"Now something worse happens. If Chrome is not running, it starts with that profile. If Chrome is running, the arguments are quietly discarded — macOS just activates the existing Chrome, showing whatever window was last in front, which is very often the wrong profile entirely. So you have swapped "always a new window" for "sometimes the wrong profile, unpredictably". Neither is what you wanted.
What Chrome actually does with a profile argument
Chrome runs one browser process that owns all your profiles. When something asks it to
open --profile-directory="Profile 1", that request lands in Chrome's startup
path — the same code that runs when you launch the browser from cold. That code's job is to
present the profile, and the only way it knows how to present a profile is to
create a browser window for it.
There is no branch in there that says "if this profile already has a window, raise it instead". Chrome does not consider the possibility, because from its point of view you asked it to open something and it opened it.
This is also why none of the workarounds people trade online hold up. AppleScript can ask
Chrome to make new window, which is the same problem by another route. Chrome's
AppleScript dictionary lets you enumerate windows, but gives you no reliable way to tell
which profile a window belongs to, and no way to bring a specific one to the front — Chrome's
scripting support has been minimal for years and per-profile awareness was never part of
it.
Why macOS cannot help either
The natural next thought is that macOS should handle this — the Dock is supposed to be where you switch between things. But the Dock switches between applications, and as far as macOS is concerned, all of your profiles are the same application: Google Chrome, one bundle identifier, one entry in the Dock.
Window-level switching is where it gets genuinely difficult. To bring back a particular profile's window, something must:
- enumerate every window Chrome currently has open;
- work out which profile each one belongs to — Chrome does not label them in any way an outside program can read directly;
- focus that specific window rather than the application as a whole.
The first and third need macOS Accessibility permission, the only interface the system offers for inspecting and controlling another app's windows. The second has no official answer at all, so it has to be inferred: which profile was launching when a window appeared, and the profile name Chrome appends to the window title.
What does work
Once you accept that the answer cannot come from Chrome, the shape of a real fix becomes clear. Something has to sit outside Chrome, keep a running map of window → profile, and when you click a profile's icon, focus the matching window rather than asking Chrome to open anything.
That is exactly what Okie Dockie does. Each profile gets a Dock icon; clicking it raises the window that profile already has; clicking again cycles to its next window; and a new window is launched only when the profile genuinely has none open. The profiles themselves are untouched — same logins, same extensions, same history.
If you want the full comparison of the approaches, including Epichrome and hand-built Automator launchers, we covered all four here.
Get every Chrome profile into your Dock
Okie Dockie builds a real Dock icon for each Chrome profile you use, badged with that profile's own picture. Click one and you land back in the window it already had open.
Everything except Chrome profile icons is free forever, and the profile icons come with a 7-day free trial that starts on its own — no sign-up, no card. macOS 13+, Apple Silicon and Intel.
Frequently asked questions
Is there a Chrome flag that focuses an existing profile window?
No. Chrome has no command-line flag, URL scheme or AppleScript command that focuses the window an already-running profile has open. Every route into a profile from outside Chrome is handled by the startup path, which creates a new window.
Does open -a instead of open -na fix it?
No. Without -n, macOS activates the running Chrome and discards your profile argument, so you get whichever window was last in front — often the wrong profile. With -n you reliably get the right profile but always in a new window.
Can AppleScript switch to a specific Chrome profile window?
Not reliably. Chrome’s AppleScript dictionary can list windows but exposes no profile property, so a script cannot tell which window belongs to which profile, and cannot raise one by profile.
Why does Windows manage this and macOS does not?
Chrome on Windows writes a per-profile shortcut with its own taskbar identity, so Windows treats each profile as a separate pinned item. That feature was never built for macOS, where all profiles share one application bundle and therefore one Dock icon.
Why does fixing this need Accessibility permission?
Because finding and focusing another application’s individual windows is only possible through the macOS Accessibility API. There is no other interface for it, which is why every window manager on the Mac asks for the same permission.
Was this guide helpful?
Thank you — that tells me what to write next.