Slack Won’t Launch on Ubuntu? It’s Wayland, Not Your Install

If your Slack desktop app suddenly stopped opening on Ubuntu — you click the icon and nothing happens: no window, no error, no crash dialog — this one is for you. I lost an afternoon to it, reinstalled Slack twice, and the real culprit had nothing to do with Slack. It was Wayland.

Here is the short version first, then the full diagnosis so you can confirm it is the same problem.

TL;DR — the fix

Slack’s snap is an Electron app, and on a native Wayland session with newer kernels it crashes the instant it tries to open its window. The fix is to force it through XWayland by adding --ozone-platform=x11 to its launcher. Create a user-level override so a snap update can't wipe it:

mkdir -p ~/.local/share/applications
cp /var/lib/snapd/desktop/applications/slack_slack.desktop ~/.local/share/applications/

Then edit ~/.local/share/applications/slack_slack.desktop and change the Exec= line to:

Exec=/snap/bin/slack --ozone-platform=x11 %U

Refresh the desktop database and launch Slack from your app menu:

update-desktop-database ~/.local/share/applications

That is the whole fix. The rest of this post explains how to be sure this is your problem.

The symptom

You click Slack. Nothing opens. Run it from a terminal and it is even more confusing — it exits cleanly with status 0 and prints nothing:

$ slack
$ echo $?
0

No error, no window, exit code 0. It looks like Slack started and quietly decided to stop.

Why reinstalling does not help

The natural reaction is to remove and reinstall the snap. I did — twice. It does not help, because nothing is corrupt. There are actually two effects stacked on top of each other:

• The app reaches early startup, then the process dies the moment it touches the Wayland display.
• It dies after writing its single-instance lock file. So the next time you launch, Slack sees that stale lock, assumes an instance is already running, hands off to a process that no longer exists, and exits 0 — which is the “absolutely nothing happens” behavior.

If launches silently no-op, clear the stale lock:

rm -f ~/snap/slack/current/.config/Slack/Singleton*

The real cause: Wayland + Electron

My setup was Ubuntu 24.04, but running a newer 6.x kernel, with a Wayland session:

$ echo $XDG_SESSION_TYPE
wayland

Slack’s logs (~/snap/slack/current/.config/Slack/logs/default/browser.log) showed it booting normally right up to the point where it queries the system, then the log simply stopped — no fatal error, no stack trace. That abrupt stop, with no crash dump, is the fingerprint of Electron falling over on the native Wayland Ozone backend.

Get Ozan Başkan’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The proof: every way I tried to launch it died, except when I forced the X11 backend. Forcing XWayland made it start instantly and stay up — sandbox and all. The deciding factor was purely Wayland vs. XWayland.

Why — ozone-platform=x11 works

Electron uses a rendering abstraction called Ozone, which can target Wayland directly or run through XWayland (the X11 compatibility layer). The native Wayland path is what crashes here; --ozone-platform=x11 tells Electron to render through XWayland instead, which is rock solid. You lose nothing meaningful — XWayland is the same compatibility layer countless apps already use under a Wayland session.

Bonus: it is not just Slack

This is an Electron problem, not a Slack problem. If other Electron apps misbehave on the same machine, the same flag fixes them. On my system VS Code was already quietly launching itself with --ozone-platform=x11 — which is the clue that put me on the right track.

One thing that is not the fix

While debugging I tried relaxing AppArmor’s unprivileged user namespace restriction (kernel.apparmor_restrict_unprivileged_userns). That looked relevant because Chromium's sandbox uses user namespaces, but it turned out to be a red herring — the Slack snap runs its renderer with --no-sandbox anyway and relies on snap confinement. Do not bother changing that sysctl; the launcher flag is the real fix.

Wrap-up

If Slack (or any Electron app) silently refuses to open on an Ubuntu Wayland session: it is almost certainly the native Wayland backend crashing. Force XWayland with --ozone-platform=x11 in a user-level .desktop override, clear any stale singleton lock, and you are back in business — with about 30 seconds of work and zero reinstalls.