Home / Guides / Why open -n doesn't give you a second account

Why open -n doesn't give you a second account

Published Aug 8, 2026 · Updated Sep 6, 2026

man open says -n opens a new instance even if one is already running. That's a promise about process spawning, not about accounts — and the gap between the two is where this goes wrong.

What -n actually promises

From man open: -n “Open a new instance of the application(s) even if one is already open.” That's the whole contract — it tells LaunchServices to spawn a fresh process rather than send an “activate” message to a process that's already running. It says nothing about accounts, sessions, or data. Those aren't LaunchServices' problem; they're the app's.

Run open -n -a "AppName" and one of two things happens, depending entirely on how that specific app is written.

Failure mode 1: the app refuses to start a second process at all

Plenty of Mac apps actively defend against multiple instances. The most common mechanism, especially in Electron apps, is app.requestSingleInstanceLock() — called once at startup, in the app's main process. Whichever process grabs the lock first keeps running; every process that starts afterward loses the race, forwards its command-line arguments to the winner over an internal IPC channel, and exits immediately. From the user's side, -n appears to do nothing at all — no new window, no error, no obvious sign a second process ever launched, because one briefly did, and then quit.

Native (non-Electron) apps often do the same thing through simpler means — a lock file in a temp directory, or a check in the app delegate's reopen handler — but the outcome is identical: the second process notices it isn't first, and yields.

Failure mode 2: it starts, but it's not a second account

For apps that don't lock, -n does exactly what the man page says: a second process, genuinely running alongside the first. What it is not is a second login, and the reason is specific: -n only changes how the process is spawned. It does nothing to where that process looks for its data. Both processes still read from the exact same ~/Library/Application Support/<AppName> (or sandboxed container), so they load the same session token from the same file on the same first launch. You get two windows onto one signed-in account, not two accounts — sign out in either window and both go with it, because there was only ever one saved session to sign out of.

If the app happens to expose a data-directory flag

Some apps — most reliably ones built on Chromium or Electron — accept a --user-data-dir argument that does control where they read and write their profile. Pointed at a fresh, empty directory, that genuinely produces an independent second login, run manually from Terminal:

open -n -a "Google Chrome" --args --user-data-dir="$HOME/second-profile"

This is real and it works — but it's per-app (not every app exposes an equivalent flag, and the exact name varies), it has to be typed correctly every time unless you wrap it in a script, and it doesn't give you a normal, double-clickable Dock icon for that second profile. It's the manual version of what an app-duplication tool automates: a stable, permanent second data directory, wrapped in something you can actually click.

Questions