Your system information

• Steam client version (build number or date): 1773426488
• Distribution (e.g. Ubuntu): Fedora 43 KDE Plasma
• Desktop: KDE Plasma 6 (Wayland) / GNOME (Wayland)
• Reproducible: consistently on any modern Wayland desktop with multiple Steam instances running

Use Case

Running multiple Steam instances simultaneously via separate HOME directories is a well-established pattern for users who maintain multiple Steam accounts (e.g., one for regular games, one for a dedicated library of visual novels, a work/personal split, family-shared machines with per-user accounts on the same Linux user, etc.).

A typical dual-instance setup looks like this on Linux:

# Main instance
steam

# Second instance with an isolated Steam config/login
HOME=~/.steam-vn steam

Both instances run cleanly — they don't interfere with each other, each has its own login, library, and downloads. Per the documented HOME-isolation approach, this works reliably and has for years.

Please describe your issue in as much detail as possible:

When both instances are running, modern Linux desktops (KDE Plasma 6, GNOME on Wayland, etc.) cannot visually distinguish the two Steam windows in the taskbar or app switcher. Both instances set the Wayland app_id to steam (hardcoded in the Steam client binary), so compositors treat them as identical applications. The result is:

• Both windows collapse into a single taskbar entry.
• Custom .desktop launchers for the second instance (with their own Icon= and StartupWMClass=) cannot be associated with the second instance's windows, because the Wayland app_id doesn't match the .desktop filename.
• Users lose the ability to pin separate launchers with distinct icons for each instance.

On X11 this was partially workable via WM_CLASS tricks, but the Steam client doesn't expose a CLI flag to change it either — the X11 class is also hardcoded to Steam / steam.

Requested feature

A CLI flag on the steam command that sets the Wayland app_id (and the X11 WM_CLASS, for consistency) to a user-provided string. Suggested names:

• --name <string> (matches Firefox's existing flag)
• --app-id <string> (matches emerging Wayland conventions)
• --class <string> (matches the X11 tradition and Chromium's flag)

Example intended usage:

# Main instance — default app_id "steam", matches steam.desktop
steam

# Second instance — custom app_id matches steam-alt.desktop
HOME=~/.steam-alt steam --name steam-alt

With a second .desktop file named steam-alt.desktop in ~/.local/share/applications/, setting:

Exec=env HOME=~/.steam-alt steam --name steam-alt
StartupWMClass=steam-alt
Icon=/path/to/custom-icon.png

…the second instance's windows would be correctly associated with that launcher, getting their own pinned icon and taskbar grouping.

Prior art

This pattern is well-supported in other applications that users commonly run in multi-instance configurations:

• Firefox: --class <string> (X11) / --name <string> (Wayland)
• Chromium / Chrome: --class <string>

A CLI flag on Steam matching this convention would enable per-instance customization for the growing number of users running Steam under Wayland with multiple accounts.

Benefit

Improves integration with modern Linux desktops (KDE Plasma 6, GNOME Wayland) for a legitimate, common use case. Does not require changes to Steam's core behavior — only exposes a flag that passes through to the underlying window-creation code.