How to run multiple Slack instances on Windows, macOS, and Linux

If you work with several clients, you live in several Slacks. Slack's own answer is the workspace switcher in the sidebar: one window, one process, all your workspaces stacked vertically. For plenty of people that's enough. This post is for when it isn't, and what you want is separate Slack apps: one window per client, separately signed in, separately notifying, each placeable on its own virtual desktop or monitor. The trick is the same on every OS; the launcher plumbing differs, so Windows, macOS, and Linux each get their recipe below.

Why the built-in switcher falls short

The switcher shares one window and one identity list. That has three practical consequences:

1. One context at a time. You can't see client A's incident channel and client B's standup thread side by side; every glance is a switch.
2. One notification stream. Everything lands in the same corner with the same icon. Muting a client for the afternoon means clicking through per-workspace settings, not closing a window.
3. One sign-in set. Workspaces added to the sidebar live in the same profile. Separate accounts with separate emails work, but they're all unlocked together, always.

A second full instance solves all three mechanically: it's a different process with a different window, different notifications, and a different set of sign-ins.

The trick: one profile directory per instance

Slack is an Electron app, and every Chromium-based app keeps its state (sign-ins, cache, settings) in a user data directory. The --user-data-dir flag relocates it. Two launches with two directories are two independent Slacks that know nothing about each other:

slack --user-data-dir=<some-directory>/client-a
slack --user-data-dir=<some-directory>/client-b

This also defeats the single-instance behavior. Normally, launching Slack while it's running just focuses the existing window, because the app takes a lock inside its profile directory. Different profile, different lock, so both processes stay alive side by side.

The directories are created on first launch; each instance walks you through its own sign-in once and remembers it. The same flag works for anything Chromium-based: browsers, Discord, Teams, or a second isolated profile of any of them; the mechanism (and its shared gotchas) has its own write-up.

Two caveats worth knowing before you make five of these. Each instance is a full Electron app, a few hundred MB of RAM apiece, so "one per client" scales further than "one per channel". And all instances run the same installed binary, so updates apply once; only the profiles are separate.

Windows

The standard per-user install puts the real executable at %LOCALAPPDATA%\slack\slack.exe. If Slack came from the Microsoft Store (an MSIX package) that path doesn't exist; use its app-execution alias %LOCALAPPDATA%\Microsoft\WindowsApps\slack.exe instead, which passes arguments through the same way. Launch the executable directly with the flag (the Start Menu tile won't carry arguments through):

%LOCALAPPDATA%\slack\slack.exe --user-data-dir=%APPDATA%\SlackProfiles\client-a

To make it a daily driver, create one Desktop shortcut per client with the flag baked into the target:

Target: C:\Users\me\AppData\Local\slack\slack.exe
        --user-data-dir=C:\Users\me\AppData\Roaming\SlackProfiles\client-a

Each shortcut can also carry a global hotkey (the Shortcut key field in its properties), and each instance gets its own taskbar presence and notification identity. If you want the instances arranged further, one virtual desktop per client with a jump hotkey, the companion post One hotkey per client: virtual desktops and workspaces on Windows covers that layer.

macOS

open -a Slack focuses the running copy, so force a new instance with -n and pass the flag through --args:

open -na Slack --args \
  --user-data-dir="$HOME/Library/Application Support/SlackProfiles/client-a"

Each instance shows up as its own Dock icon while running. For one-keystroke access, wrap each client in a shell alias:

alias slack-client-a='open -na Slack --args \
  --user-data-dir="$HOME/Library/Application Support/SlackProfiles/client-a"'

or, if you want something clickable in the Dock, save a two-line Automator "Application" (or a Shortcuts app entry) that runs the same command, one per client.

Linux

The flag is identical; only the binary location depends on how Slack was installed. The deb puts it at /usr/bin/slack, the snap at /snap/bin/slack, and Flatpak goes through flatpak run:

/usr/bin/slack --user-data-dir="$HOME/.config/SlackProfiles/client-a"
flatpak run com.slack.Slack --user-data-dir="$HOME/.config/SlackProfiles/client-a"

For a launcher entry per client, drop a .desktop file in ~/.local/share/applications/. Exec lines don't expand ~ or $HOME, so either write the absolute path or wrap the command in sh -c:

[Desktop Entry]
Type=Application
Name=Slack (Client A)
Icon=slack
Exec=sh -c 'exec /usr/bin/slack --user-data-dir="$HOME/.config/SlackProfiles/client-a" --class=slack-client-a'
StartupWMClass=slack-client-a

The --class / StartupWMClass pair is optional but worth it under Xorg (and XWayland): it gives each instance its own window class, so GNOME and KDE docks group each client under its own icon instead of piling every Slack window onto one.

The sign-in gotcha: deep links go to the default instance

The first sign-in of a new profile hits the one rough edge. Slack's login finishes in the browser and redirects to a slack:// deep link, and the OS routes protocol links to the single registered handler: your default instance. So the sign-in you started in the client-a Slack completes in the default one.

The fix is to deliver the link to the right instance yourself, once per profile. A launch with the profile's directory plus the URL forwards it through the same single-instance mechanism that normally focuses the window, and the sign-in lands in the right Slack:

slack --user-data-dir=<profile-dir> "slack://<the-deep-link>"

Getting hold of the link is the fiddly part. If the browser page still shows a copyable link ("click here if nothing happens"), right-click and copy it. Slack's current sign-in page often fires the deep link without ever rendering one; then the reliable route is to own the handler instead: register a small router of your own for the slack:// scheme (a per-user RegisteredApplications + Capabilities entry, selected once under Settings > Apps > Default apps), and have it pass each link to the instance you pick. That choice outranks even a Store-installed Slack's own claim on the scheme, because the protected default-app choice is written through the supported path. Sessions persist per profile, so sign-ins stay a once-per-client ritual, not a daily one.

Or let your agent set it up

The plumbing above is fiddly and OS-specific — exactly the kind of thing to hand to the coding agent already open in your terminal. Paste this and edit the client list:

Copy this prompt to your coding agent

Set up separate Slack instances on this machine, one per client, each with its
own --user-data-dir profile so they sign in and notify independently. Detect my
OS and how Slack is installed (find the real binary), then create a per-client
launcher the way that OS wants it: Desktop shortcuts on Windows, shell aliases
or an Automator/Shortcuts app on macOS, .desktop files on Linux (with a
distinct StartupWMClass each). If sign-in deep links land in the wrong
instance, wire the slack:// handler workaround too. My clients are: client-a,
client-b, client-c. Show me each launcher before you create it.

The agent handles the binary-location and launcher-syntax differences the sections above spell out by hand; you just name the clients and review each launcher.

Signed in once, separate forever

However you wire the launchers, the result is the same: each profile directory signs in once, keeps its own notification settings, and stays put across restarts and updates. One Slack per client, each behaving like the only Slack on the machine.

On Windows, the whole arrangement can be declared as config: the windows role turns each profile into a hotkeyed workspace on its own virtual desktop and ships the Virtual Desktop Router that handles the deep links described above.