protonscr

[SteamRT3 Client] $PATH does not contain /usr/local/bin or ~/.local/bin

steamclosed
ValveSoftware/steam-for-linux#13367 · opened 2026-07-01 by Smujb · updated 2026-07-30 · 9 comments · github
SSmujb 2026-07-01 github

When using the SteamRT3 beta client, the $PATH variable only contains the Steam Runtime's bin directory, /bin and /usr/bin. This breaks the loading of custom scripts into /usr/local/bin or ~/.local/bin which are on the $PATH for most modern Linux OSes.

For example, scopebuddy recommends manual installation to /usr/local/bin. Placing the script there or in ~/.local/bin allows a user to make use of this tool for launching their Steam games using the launch command scopebuddy -- %command% or scb -- %command% in the current stable version of the Steam client. Enabling the beta however breaks this, as the scb/scopebuddy executable cannot be found on the cut-down $PATH.

This is particularly a problem for SteamOS itself and for other systems that have readonly /usr/. ~/.local/bin and in some cases /usr/local/bin are writeable on these systems which can allow for the installation of such tools. Additionally, even on regular package-based Linux systems, it is generally recommended not to place files directly in /usr/bin as this directory is supposed to be managed solely by the package management software.

Kkisak-valve maintainer 2026-07-01 github

Hello @Smujb, this is https://github.com/ValveSoftware/steam-runtime/blob/master/doc/steamlinuxruntime-known-issues.md#usrlocal / https://github.com/ValveSoftware/steam-runtime/issues/288 and is something that can't reasonably be resolved.

Sstellaberrant 2026-07-01 github

Hello @Smujb, this is https://github.com/ValveSoftware/steam-runtime/blob/master/doc/steamlinuxruntime-known-issues.md#usrlocal / ValveSoftware/steam-runtime#288 and is something that can't reasonably be resolved.

you can't be serious. this would break the steam controller functionality on every OS that is not STEAMOS out of the box as soon as the beta becomes stable, as well as scopebuddy ?! this is a terrible regression from the current steam stable

SSmujb 2026-07-01 github

This particular issue is unrelated to the Steam Controller, that is a separate issue with the beta. But yes, it does break a lot of existing community-made tooling around Steam, particularly on SteamOS itself.

SSmujb 2026-07-01 github

Literally just adding the following as a launch command makes the binary loading work: env PATH=$HOME/.local/bin:$PATH [binary in .local/bin] %command% (same goes for /usr/local/bin)

Are you sure there is no way to replicate this functionality?

e.g. if I have scopebuddy in ~/.local/bin then I can use the launch command env PATH=$HOME/.local/bin:$PATH scopebuddy --%command% and it works even on the SteamRT3 beta.

To me it makes sense to just preadd those locations to the $PATH when launching a game then, no?

Sstellaberrant 2026-07-01 · hidden on GitHub github
Image reminder that this is what the steam controller experience is like on any OS that is not SteamOS in desktop mode. it keeps asking for remote control permissions every time and that is never saved either. suppressing this prompt requires either something like extest (which would be impossible with the new beta) or just auto accepting the prompt all the time. I dont even want to think about what a terrible security risk that would be
Sstellaberrant 2026-07-01 github

and the custom scopebuddy (gamescope wrapper) script that is used in bazzite and other distros would no longer function either. please try working on a solution to this that is acceptable to everyone.

Sstellaberrant 2026-07-01 github

This particular issue is unrelated to the Steam Controller, that is a separate issue with the beta. But yes, it does break a lot of existing community-made tooling around Steam, particularly on SteamOS itself.

ok my bad, i misunderstood something there, but this would still be pretty bad as it'd severely restrict launch commands for regular users. e.g scopebuddy, lsfg, goverlay, …

Ssinni800 2026-07-30 github

I think what this would require is better tooling for launch commands. Add some options in the main steam configuration that lets us add environment variables, maybe?

Like, yes, sure, SteamRT3 due to it being some sort of container implementation, detaches from our own env and only pulls over certain required variables.

But some of them, we'd like to bring back, but per-game is incredibly cumbersome.

Examples would be like some PROTON_ variables we want to see in every game (use_ntsync, ...), LIBVA/VDPAU drivers (not sure if those ever become relevant in games though), global MangoHUD settings, MESA settings, etc pp.

For this, I would love a way to add an "env command" or something that is ran before each game to bring in environments, as managing a separate list in Steam might also be cumbersome (and harder to edit than just writing in a file).

SSmujb 2026-07-30 github

Yeah honestly a better implementation of launch commands in general would be even better.

Upstream links