Repository navigation
STEAM_COMPAT_LIBRARY_PATHS documentation doesn't match implementation #856
Description
Your system information
- Steam Runtime Version: 4.0
- Distribution (e.g. Ubuntu 18.04): CachyOS
- Have you checked for system updates?: Yes
- What compatibility tool are you using?: Steam Linux Runtime / Proton 5.13+
- What versions are listed in
steamapps/common/SteamLinuxRuntime/VERSIONS.txt?
#Name Version Runtime Runtime_Version Comment
depot 1.0.20260618.246542 # Overall version number
LD_LIBRARY_PATH 1.0.20260618.246542 scout 1.0.20260618.246542 # steam-runtime/
scripts 0.20260618.0 # from steam-runtime-tools
- What versions are listed in
steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?
#Name Version Runtime Runtime_Version Comment
depot 2.0.20260805.254767 # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64 0.20260805.0
scripts 0.20260805.0 # from steam-runtime-tools
soldier 2.0.20260805.254767 soldier 2.0.20260805.254767 # soldier_platform_2.0.20260805.254767/
- What versions are listed in
steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?
#Name Version Runtime Runtime_Version Comment
depot 3.0.20260805.254768 # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64 0.20260805.0
scripts 0.20260805.0 # from steam-runtime-tools
sniper 3.0.20260805.254768 sniper 3.0.20260805.254768 # sniper_platform_3.0.20260805.254768/
- What versions are listed in
steamapps/common/SteamLinuxRuntime_4/VERSIONS.txt?
#Name Version Runtime Runtime_Version Comment
depot 4.0.20260805.254769 # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64 0.20260805.0
scripts 0.20260805.0 # from steam-runtime-tools
steamrt4 4.0.20260805.254769 steamrt4 4.0.20260805.254769 # steamrt4_platform_4.0.20260805.254769/
Please describe your issue in as much detail as possible:
There seems to be a mismatch between what exact paths are expected relative to extra Steam Libraries for the STEAM_COMPAT_LIBRARY_PATHS environment variable:
-
SteamRT expects these paths to be set to
<path>/SteamLibrary, without thesteamappschild path. Here it joins the path with thesteamappsfolder when building SLR/compat tool search paths. -
Proton expects these paths to be set to
<path>/SteamLibrary/steamapps. Here it strips the last directory when building the mainlibraryfolders.vdf.
So, if you set STEAM_COMPAT_LIBRARY_PATHS and don't include the steamapps part, SteamRT will have the appropriate search paths, but Proton will generate a broken libraryfolders.vdf. In practice, this would break launcher programs made for Windows that use this file to locate where a Steam game is located. On the other hand, if you include steamapps, SteamRT will have incorrect search paths (though I couldn't get this to break anything in my testing).
The current behavior of Steam when running a program as a non-Steam app and selecting the SLR or Proton as a compat tool, at least on my system, aligns with the Proton behavior of including steamapps in the paths, which is why I'm reporting this as an SLR bug instead of a Proton bug.
This came up as a bug in the Linux launcher for me3, a FromSoftware mod loader. We followed docs/steam-compat-tool-interface.md, which seemed to indicate that we had to populate this env var with <path>/SteamLibrary, and this ended up breaking a mod that relied on parsing libraryfolders.vdf.
What I think should be done about this
docs/steam-compat-tool-interface.md should be updated to precisely state which of these two paths is expected, and the relevant Proton or SteamRT code mentioned above should be patched to conform. In my opinion, since Steam follows what Proton expects when launching non-Steam games, it's the one that should be considered "correct".
Steps for reproducing this issue:
N/A
Activity
smcv commentedon Sep 29, 2026
I believe
STEAM_COMPAT_LIBRARY_PATHSis meant to be set by Steam based on the stack of active compatibility tools (for example SLR 4 + Proton 11, which might be installed in two different Steam Library folders), and treated as read-only for everyone else; so I'm surprised that a mod tool found a need to overwrite it.The fact that it's set by Steam means that whatever Steam does when setting it, that should be assumed to be correct -
steam-compat-tool-interface.mdis trying to document what does in fact happen, rather than being a specification. From your testing that would seem to imply that each value in the colon-separated list does include the trailing/steamapps, as you say (and my own Steam logs confirm this). What I don't know is whether this is a behaviour change in the Steam Client, or whether it was always documented wrong.The main use that SLR makes of these paths is to make sure they get shared with the container environment, which would work equally well with or without the trailing
/steamapps, as long as nothing is trying to access content that is in the library but somehow outsidesteamapps(the only thing in my Steam Library matching that description is the filelibraryfolder.vdf).The use of these paths in
steam-runtime-launch-optionsis a developer/tinkerer easter egg (the same as all ofs-r-launch-options, really...) to make it easier to experiment with unsupported situations. We use this when testing new/proposed runtime versions, and looking at the$STEAM_COMPAT_LIBRARY_PATHSis just an easy way to find places where the developer is likely to have put their new/proposed runtime.smcv commentedon Sep 29, 2026
@TTimo, perhaps you could confirm this by referring to Steam code?
tremwil commentedon Sep 29, 2026
Would it? Unless I'm missing something,
launch-options.pyappends a trailingsteamapps/commonbefore adding to the search paths (see https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/bin/launch-options.py#L1660-1664), so if Steam setsSTEAM_COMPAT_LIBRARY_PATHS=/path/to/SteamLibrary/steamapps, it would add/path/to/SteamLibrary/steamapps/steamapps/commonto the search paths, which won't contain anything because it doesn't exist. This is why I was confused about which is correct initially; that bit of code indicates that we don't expect a trailingsteamapps, whereas the Proton code building thelibraryfolders.vdfand Steam does.smcv commentedon Sep 29, 2026
What you might be missing is that
launch-options.pyisn't load-bearing for normal use of Steam (it's far too fragile for that); and it searches various other locations, not just$STEAM_COMPAT_LIBRARY_PATHS, so on most developers' systems it'll successfully find runtimes even if it's misinterpreting$STEAM_COMPAT_LIBRARY_PATHS.The sharing that I'm talking about is in wrap-setup.c.
tremwil commentedon Sep 29, 2026
Ah I see, thanks!
smcv commentedon Oct 1, 2026
Fix proposed in https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/1070 (but it needs review, ideally from someone with access to Steam code).
@tremwil or @kisak-valve, perhaps you could retitle this issue to something like "STEAM_COMPAT_LIBRARY_PATHS documentation doesn't match implementation"?
[-]STEAM_COMPAT_LIBRARY_PATHS has different semantics for SLR and Proton[/-][+]STEAM_COMPAT_LIBRARY_PATHS documentation doesn't match implementation[/+]smcv commentedon Oct 13, 2026
The documentation in steam-runtime-tools has been updated.
For completeness: an updated
launch-options.pywill make its way into the Steam Client beta at some point, most likely as part of the next "big" beta update.