Please provide the logs requested in the issue template, especially the line with a lot of \0 in it from console_log.txt, which indicates what command-line Steam is actually launching.

I was unable to reproduce the symptom described with Proton 5.0, which is an example of an official compat tool that is too old to be using require_tool_appid. Steam logs this in console_log.txt:

[2026-08-17 18:27:20] steam-runtime-launch-client\0--alongside-steam\0--forward-fd=193\0--\0/home/user/.local/share/Steam/steamrt64/pv-runtime/steam-runtime-steamrt/bin/steam-runtime-supervisor\0--terminate-when-signaled\0--env-fd=193\0--\0/bin/sh\0-c\0/home/user/.local/share/Steam/steamrt64/steam-launch-wrapper -- /home/user/.local/share/Steam/steamrt64/reaper SteamLaunch AppId=312990 -- '/home/user/SteamLibrary/steamapps/common/Proton 5.0'/proton waitforexitandrun '/home/user/SteamLibrary/steamapps/common/Broforce The Expendables Missions/Expendabros.exe'\0^M

indicating that steam-launch-wrapper, reaper and proton are being run outside the steamrt3c container.

I'm seeing something similar after SteamRT3 on beta today. I might be wrong, but I don't think python3 is the problem here. It looks more like a path issue.

System: CachyOS, Steam beta 1792110651, proton-cachyos 11.0-20261005 native build, from the distro package at /usr/share/steam/compatibilitytools.d/proton-cachyos-native/.

Failing launch. Exits in under a second. Steam logs nothing after this line, no error at all:

the \0 line from console_log.txt

[2026-10-15 20:05:00] steam-runtime-launch-client\0--alongside-steam\0--forward-fd=139\0--\0/home/user/.local/share/Steam/steamrt64/pv-runtime/steam-runtime-steamrt/bin/steam-runtime-supervisor\0--terminate-when-signaled\0--edit-env-fd=139\0--\0/bin/sh\0-c\0STEAM_COMPAT_DATA_PATH=/w/games/steam/steamapps/compatdata/4024179835 VKD3D_CONFIG=no_subgroups,single_queue VKD3D_FEATURE_LEVEL=12_0  /home/user/.local/share/Steam/steamrt64/steam-launch-wrapper -- /home/user/.local/share/Steam/steamrt64/reaper SteamLaunch AppId=4024179835 -- '/run/host/usr/share/steam/compatibilitytools.d/proton-cachyos-native'/proton waitforexitandrun  "/w/games/steam/steamapps/compatdata/4024179835/pfx/drive_c/Program Files (x86)/Battle.net/Battle.net.exe"\0

From what I can tell, proton does run outside the steamrt3c container, like you mentioned, but the path Steam passes looks like it was resolved from inside the container (where the host's /usr shows up as /run/host/usr). Running that same reaper command by hand under strace on the host:

[pid 235722] execve("/run/host/usr/share/steam/compatibilitytools.d/proton-cachyos-native/proton", ["/run/host/usr/share/steam/compat"..., "waitforexitandrun", "/bin/true"], 0xffed4854 /* 85 vars */) = -1 ENOENT (No such file or directory)
[pid 235722] +++ exited with 0 +++

So the exec fails before python gets involved. Reaper also exits 0 without printing anything, which is probably why the failure is completely silent.

Workaround: I made ~/.local/share/Steam/compatibilitytools.d/proton-cachyos-native-home/ with symlinks to every file in the /usr/share tool except compatibilitytool.vdf, plus my own vdf with a new internal name. The exact same proton build launches fine from there:

[2026-10-15 19:53:30] steam-runtime-launch-client\0--alongside-steam\0--forward-fd=192\0--\0/home/user/.local/share/Steam/steamrt64/pv-runtime/steam-runtime-steamrt/bin/steam-runtime-supervisor\0--terminate-when-signaled\0--edit-env-fd=192\0--\0/bin/sh\0-c\0PROTON_LOG=1 STEAM_COMPAT_DATA_PATH=/w/games/steam/steamapps/compatdata/4024179835 VKD3D_CONFIG=no_subgroups,single_queue VKD3D_FEATURE_LEVEL=12_0  /home/user/.local/share/Steam/steamrt64/steam-launch-wrapper -- /home/user/.local/share/Steam/steamrt64/reaper SteamLaunch AppId=4024179835 -- '/home/user/.local/share/Steam/compatibilitytools.d/proton-cachyos-native-home'/proton waitforexitandrun  "/w/games/steam/steamapps/compatdata/4024179835/pfx/drive_c/Program Files (x86)/Battle.net/Battle.net.exe"\0

Reaper also exits 0 without printing anything, which is probably why the failure is completely silent

I've now proposed https://github.com/Plagman/reaper/pull/6 with a fix for that. (If that change is accepted, someone from the Steam Client team will still need to integrate it by replacing the Steam Client's reaper with an updated build.)

I might be wrong, but I don't think python3 is the problem here. It looks more like a path issue. … the path Steam passes looks like it was resolved from inside the container (where the host's /usr shows up as /run/host/usr) … So the exec fails before python gets involved

Yes, that seems like a correct analysis from @sepdotgg's log snippets, and is consistent with the partial information in the original report from @TheRustyShackleford. If this is the root cause, then a better title would be something like "SteamRT3 client can't use third-party compatibility tools in /usr", and CachyOS's custom Proton build is an example of such a tool.

Probably the containerized Steam Client should special-case paths below /run/host/ that were discovered inside the container, so that the prefix is replaced by / before running the command.

This would not happen with Valve's official compatibility tools, because those don't get installed into /usr (Steam doesn't support being installed in /usr or having a Steam Library folder there).

For the Steam Client team to be able to analyze and fix issues, the most important thing is to have a clear picture of the symptoms and whatever diagnostic information is available (such as logs). An interpretation of what is happening can sometimes be useful to have in addition, but it is not a substitute for the original diagnostic info, which would have let the Steam Client team draw their own conclusions.

Probably the containerized Steam Client should special-case paths below /run/host/ that were discovered inside the container, so that the prefix is replaced by / before running the command.

One straightforward workaround is to create a symlink /run/host -> / or /run/host -> ../, as is created by https://github.com/containers/toolbox/blob/main/data/tmpfiles.d/toolbox.conf if toolbox(1) happens to be installed.

This probably means that many Steam Client developers would not see this issue even if they did have a compatibility tool in /usr, because toolbox(1) is a popular development tool.

I should probably add my 2 cents in this issue since I make that package.

Personally I do not particularly care if that, so called native, build of Proton-CachyOS stops working with the transition to the steamrt3c client. The usefulness it had in the past has been superseded by recent SteamRT versions and the newer compiler versions in the Steam and Proton SDKs. Given the deprecation of a lot of 32bit libraries in Arch and thus CachyOS, it is now a pure wow64 build of Proton which lacks in the compatibility aspect too compared to the multilib build of Proton-CachyOS using the Steam Linux Runtime. If the only potential use-case of the required changes in the Steam Client is this build of my custom proton, I am more than happy to deprecate it or hide it from Steam.

From my own testing I can verify that the version of Proton-CachyOS that is built properly inside the Proton SDK and installed under /usr/share/steam/compatibilitytools.d/ runs fine with the SteamRT3 client so nothing is lost really. In fact we expected this and we have already transitioned most users to the Steam Linux Runtime build, leaving the native build only as an option. The native build does occasionally become useful for development purposes but I work around that myself most of the time by using other third-party tools such as umu-launcher.

From my own testing I can verify that the version of Proton-CachyOS that is built properly inside the Proton SDK and installed under /usr/share/steam/compatibilitytools.d/ runs fine with the SteamRT3 client

When you say "built properly inside the Proton SDK", do I assume correctly that as a result of this, it also asks Steam to run it in a SLR 4 container ("require_tool_appid" "4183110"), similar to the way the official Proton 11 compat tool works?

If so, that's an interesting data point. I'm a little surprised that this is true: I would have expected all compatibility tools below /usr (those with a dependency on SLR, and those without) to either succeed in the same way, or fail in the same way.

Perhaps there's some "compensating errors" going on with the containerized steamrt3c client giving the SLR container a path that wouldn't have been valid on the host, but happens to be valid (again) inside the SLR container, because the steamrt3c container and the SLR container have a very similar filesystem layout?

Or perhaps this might help to indicate (to a Valve developer with Steam Client source code access) where to look for the code that would need changes to fix this.

When you say "built properly inside the Proton SDK", do I assume correctly that as a result of this, it also asks Steam to run it in a SLR 4 container ("require_tool_appid" "4183110"), similar to the way the official Proton 11 compat tool works?

Yes, it requests to run inside the SLR 4 container just like any other of the official Proton 11 compat tools.

FWIW, pressure-vessel has always complained with

pressure-vessel-wrap[863721]: W: Not sharing path STEAM_COMPAT_MOUNTS="...:/usr/share/steam/compatibilitytools.d/proton-cachyos-slr:..." with container because "/usr" is reserved by the container framework

and I wanted to move the tool away from that location, and only provide a vdf file there with an absolute path to the tool there, but it also always worked despite that, and didn't cause any issues that where identified to be a result of it.

The example above is from umu-launcher but I am certain I have seen the same thing with Steam before the transition to the SteamRT3 client. With the SteamRT3 client I can't find the error in the terminal output any more.