Compatibility Report

Steps to produce logs:

1. Fully close steam.
2. Delete all files in ${XDG_DATA_HOME:-$HOME/.local/share}/Steam/logs/.
3. Launch steam.
4. Select compatibility tool for game .
   4a) In my case i did either Proton Experimental, Proton 11.0 (Beta), or Proton 10.0-4 using a different version for each iteration of these steps.
5. Launch game with selected compatibility tool.
6. Let game either launch or attempt to launch.
   6a) If the game got stuck at Downloading Content (0%): Let it sit for a couple seconds then press cancel.
   6b) If the game launched: Get past the main menu to exit the game normally.
7. Properly close steam fully.
8. In ${XDG_DATA_HOME:-$HOME/.local/share}/Steam/logs/ select all files and compress into a .tar.gz file.
9. Rename the .tar.gz file to match used Proton version.
10. Upload the compressed logs here while noting if it's Not Working: or Working:.
11. Return to step 2 and repeat until all desired versions of Proton have been tested once.

Compressed logs from ${XDG_DATA_HOME:-$HOME/.local/share}/Steam/logs/:

Not Working: Proton Experimental.tar.gz

Not Working: Proton 11.0 (Beta).tar.gz

Working: Proton 10.0-4.tar.gz

Hello @jimmon89,

Your logs indicate that you are using Proton GE, and not Valve's Proton 11 (Beta) (AppID 4628710). This is likely a problem with Proton GE.

very strange, after removing all traces of all Proton-GE compatibility tools from my system, and launching a game with the latest Proton-CachyOS 11.0 which exhibited the same symptoms as Valve-Proton-11.0 and Experimental, it randomly downloaded SLR 4.0
which steam refused to download in any form prior to deleting Proton-GE
like even the "install" button on the SLR 4.0 page in the steam client was grayed out
any insights as to why this could have happened?

--EDIT--
like, my issue is technically "fixed", at least on my end, but i don't feel like this should be closed until we can find the reason it happened in the first place.
Even if only for someone to troubleshoot the same issue at a later date to know how to not cause it again.

Knowing the underlying cause, the issue can

Best case scenerio:
it is fixed long term on valves end

Middle range scenerio:
it could help proton fork devs to not cause a similar issue in the future

Worst case scenerio:
Inform end-users how to not cause the problem on their end when installing various proton forks

My guess is that Proton GE wants to be using SLR 4.0 to follow along Valve's transition over to SLR 4.0 with Proton 11, but has some sort of configuration problem actually indicating it as a dependency. We certainly don't mind leaving the issue open though.

thank you, i appreciate the ability to keep this issue open until myself or another interested part that may feel so inclined can find the root cause
i'll start by making a post on the Proton-GE issue tracker and referencing this particular issue

I have some updates to add on to this as I just started running into something similar. Maybe it's related and can help identify and fix the root cause.

Recently, Steam has begun to ignore my globally set default compatibility tool of Proton CachyOS. I'm assuming this coincided with the latest Proton Experimental that added FSR 4 for RDNA 3. For some reason, this same override does not work on RDNA 4. Doesn't make sense to me, but that's fine, I use CachyOS's SLR version anyway and can just use my own 4.1.0 DLLs.

Anyway, knowing that Steam doesn't actually upgrade RDNA 4, I realized immediately that my global override wasn't being respected when I went to run Monster Hunter Wilds and no longer saw FSR 4.1.0 in my graphics settings. A per-game override fixed this issue, and I could use Proton CachyOS again. In working with Claude Code, I overrode the priority from 75 to 400 in the config.vdf file while Steam was closed, then restarted Steam.

On restarting, Steam had downloads queued for all my native Linux games, alongside of SLR 4.0. After downloading SLR 4.0, no games would launch - although they were then trying to respect my Proton CachyOS priority - and I receive a similar error. "An error occurred while launching this game: Compatibility tool failed". Turns out, the SLR 4.0 download actually emptied the directories. There were no files, just empty directories; an empty depot. Going to SLR 4.0 in the Library shows it as "Installed", but the UI says it's locked and only available on SteamOS. I'm including a ZIP of all the logs that should be relevant to this issue. This includes errors like Assertion Failed: Tool 4183110 "Steam Linux Runtime 4.0" unsupported version 0 and Failed installing AppID 4183110 (Invalid platform)

If I reset my config.vdf priorities to have Proton-CachyOS at 75 again, it queues all those downloads again and actually downloads SLR 4.0. But, the original issue where my global compatibility tool is not being respected persists. I can live with this and override each game individually for now, but my hope is that this issue is resolved when overriding the priority level in the config.vdf, and that the global option being set in the GUI will stop being overridden by Experimental.

proton-and-steam-logs.tar.gz

@kisak-valve @TTimo I'm not sure if you guys get notifications from regular post interactions, but just in case you don't, I was hoping to bring this to your attention. Thanks for everything you do!

Adding a data point with some evidence that this is a server-side license/ownership problem on the affected account, not a client or third-party-compat-tool issue.

Setup: Pop!_OS 22.04 (Ubuntu-based), Steam Flatpak client, reproduced on both stable and publicbeta client branches.

Symptoms

Any launch routed through Proton Experimental fails ("Invalid platform" in the UI), because Steam Linux Runtime 4.0 (appid 4183110) cannot be installed:

[2026-07-25 14:54:58] Requesting license for AppID 4183110 ...

— no license is ever granted; the request hangs with no response. Batch app access token requests are denied repeatedly:

[2026-07-25 21:56:28] Requested 21 app access tokens, 0 received, 21 denied

(A single-token request for 4183110 succeeds — metadata access works, it's specifically the license that's missing.) Game launches then fail with:

[2026-07-25 15:28:55] Assertion Failed: BStartUpdateDepotsJob: 553850 missing required app 4183110

Same assertion for appids 975370, 3818850, 228980, 413150. The "Invalid platform" error is misleading: cached appinfo for 4183110 is complete (oslist=linux, depot 4183111, public buildid 23629212) — the installable depot list is empty only because the account holds no license.

Experiment showing it's purely ownership

I downloaded the exact public depot content (https://repo.steampowered.com/steamrt4/images/4.0.20260608.242786/SteamLinuxRuntime_4.tar.xz), extracted it to steamapps/common/SteamLinuxRuntime_4, and hand-wrote appmanifest_4183110.acf. The client accepted it ("Loaded 3 apps") and Proton Experimental games went straight to CreatingProcess and launched. But on the next scheduler pass:

[2026-07-25 21:51:39] AppID 4183110 config changed : removed depots 4183111

and the client deleted the entire tree — the account owns no depots for the app, so the updater treats every file as orphaned. So the runtime itself works fine locally; the only thing broken is the server-side license grant.

Re: the third-party compat tool theory

I tested it: moved all GE-Proton tools out of compatibilitytools.d/ and did a clean client restart — installing 4183110 still fails the same way. So removal of third-party tools is not a reliable fix, at least not once an account is in this state.

Steam Support outcome: I filed a ticket asking for the account's license state for 4183110 to be checked; I got a generic "unsupported distro" template and "we are unable to grant the software".

Happy to provide full logs or account details to Valve via the ticket if useful.

I recently opened a separate issue regarding this exact behavior, which was closed as a duplicate of this thread under the assumption that it was caused by "third-party manipulation of Steam's config files."

I am adding my data here because it independently confirms the server-side license/ownership explanation provided above and directly disproves the third-party tool theory.

Setup: Nobara Linux (Fedora-based), native Steam client, AMD Ryzen 7 4800HS / RADV RENOIR, build 1785187029.

Symptoms: Steam Linux Runtime 4.0 (4183110) shows as "installed" in Library → Tools (no Install button available) while appmanifest_4183110.acf has SizeOnDisk: 0, BytesDownloaded: 0, empty InstalledDepots. On disk, steamapps/common/SteamLinuxRuntime_4/ exists but its subfolders are 0 bytes and there's no toolmanifest.vdf — the install never actually completes. Any Proton build depending on 4183110 (Proton Experimental, Proton 11.0, Proton-GE Latest) fails to launch — silent exit or "Compatibility tool failed" — while Proton 9.0-4 / 10.0-4 (which depend on Runtime 3.0 "sniper", 1628350, unaffected) launch the same games fine. compat_log.txt:

Failed to load manifest for tool 4183110!
Tool 4183110 "Steam Linux Runtime 4.0" unsupported version 0.
Tool <proton_appid> "<Proton build>" has a dependency on tool 4183110: dependent tool cmdline wrap failed.

steamcmd confirms it's a license/entitlement issue, not corruption: +login anonymous → ERROR! Failed to install app '4183110' (No subscription). With an authenticated account it succeeds and writes a correct .acf (SizeOnDisk 671082683, BytesDownloaded == BytesToDownload, depot 4183111 populated), and affected Proton builds work correctly for the rest of that session.

This matches the "removed depots" explanation above exactly: after some period of normal use (not isolated to a reboot), the .acf reverts on its own back to SizeOnDisk: 0 / empty InstalledDepots, while the ~650MB of actual files stay untouched on disk (confirmed with du -sh before/after). "Verify integrity of tool files" reports "All files successfully validated" while the UI simultaneously shows "Size of installation: 0 B" — it's validating against a manifest that expects zero depots, so it never flags the mismatch. This is consistent with the updater treating the runtime as orphaned and clearing the depot record, same as the config changed : removed depots 4183111 behavior described above, just observed from the manifest side instead of the log line itself.

Regarding the third-party-tool theory: To directly address the reason my original issue was closed, I hit this before ever touching GE-Proton or any manual config — the first failure was on a completely untouched install, plain "Compatibility tool failed" with no prior manipulation. The manual .acf/steamcmd fixes described above only happened afterward, while diagnosing. Combined with the report above of reproducing this after fully removing GE-Proton from compatibilitytools.d/, this doesn't look like it's caused by third-party compat tools or user config changes — it looks like a server-side license grant issue for 4183110 on affected accounts.

Happy to attach full logs if useful — I have compat_log.txt / content_log.txt from both the initial failure and the post-steamcmd revert.

Adding another data point that corroborates @Antrare's and @4mrco's findings above.

Setup: Bazzite (Fedora Kinoite-based), native Steam client, AMD Ryzen 7 7800X3D / RX 9070 XT.

Same signature as reported: appmanifest_4183110.acf stuck at SizeOnDisk 0 / BytesDownloaded 0 / empty InstalledDepots despite StateFlags claiming installed. Any Proton build depending on 4183110 (Proton 11.0, Proton Experimental, Proton-CachyOS) fails with Tool 4183110 "Steam Linux Runtime 4.0" unsupported version 0 / dependent tool cmdline wrap failed, while Proton 10.0 (Runtime 3.0 "sniper", unaffected) launches the same titles fine.

Like @4mrco, an authenticated steamcmd login briefly succeeds and reports real depot info (InstalledDepots populated, correct manifest ID/size for the current buildid) — but the account reverts to the broken state again within the next few minutes, well before a reboot or any other local change.

On the theory that this could be caused by "third-party manipulation of Steam's config files" (mentioned earlier in this thread as the cause of a related report): I checked config.vdf's CompatToolMapping on this host and there is no entry for AppID 4183110 itself — only the global default ("0") and one unrelated per-title override, neither of which reference 4183110. localconfig.vdf for this Steam user doesn't have a CompatToolMapping section at all. So at least on this account, there's no local config pointing a compat tool at 4183110 that could explain a self-referential loop — the failure really does look confined to the server-side entitlement check for this AppID.

This has now persisted on my account for multiple weeks without self-resolving, across many retry attempts, reinstalls, and reboots. Happy to share content_log.txt/compat_log.txt snippets if useful.