TF2 runs under Steam Linux Runtime 3.0 by default. When you try to force a different compatibility option, you shouldn't see SLR 1.0 as an available option - at the moment you do, but that's a known bug.
Is this reproducible when you don't force a specific compatibility tool? In console_log.txt you should be able to see that it defaults to SLR 3.0 (sniper), like in this entry from your log:
[2026-08-21 19:24:17] Game process updated : AppID 440 "/home/logan/.steam/debian-installation/ubuntu12_32/steam-launch-wrapper -- /home/logan/.steam/debian-installation/ubuntu12_32/reaper SteamLaunch AppId=440 -- '/home/logan/.steam/debian-installation/steamapps/common/SteamLinuxRuntime_sniper'/_v2-entry-point --verb=waitforexitandrun -- '/home/logan/.steam/debian-installation/steamapps/common/Team Fortress 2/tf.sh' -steam -gl -novid -windowed -noborder -w 1920 -h 1200 -freq 165 -refresh 165", ProcID 19638, IP 0.0.0.0:0
Memory is leaked by Steam when closing native Linux games
This seems more likely to be a general problem with the Steam Client or its communication with games than something that is related to any specific version of the Steam Linux Runtime.
I didn't realize it already used 3.0, but yes the bug still stands when not forcing compatibility. I said it pretty poorly but I wasn't using any compatibility tool to begin with, I just assumed TF2 used SLR 1.0 because it was the only non-proton option in the compatibility menu other than legacy runtime, that's mb.
I'm gonna start throwing out random ideas, but it could be possible that this is just a TF2 issue since to my knowledge I don't have any other native linux games that take a substantial (>1~2gb) amount of RAM, so I don't have many other avenues of testing other than with TF2, but I believed it was likely an SLR issue because memory is retained when shutting off TF2, so I don't think TF2 is at fault.
my bad if I'm wrong though, and I'll take my leave if it turns out to just be a TF2 issue.
I just assumed TF2 used SLR 1.0 because it was the only non-proton option in the compatibility menu other than legacy runtime
Yeah, if #13484 wasn't happening, then that reasoning would be valid. The way it's meant to work is that you should only see SLR 1.0 and Legacy Steam Runtime for legacy 'scout' titles, and you should only see SLR 3.0 for SLR 3.0 titles like TF2. But this is currently known-broken: it was working for a while, then regressed.
I believed it was likely an SLR issue because memory is retained when shutting off TF2
All SLR-related processes should also exit after you exit from TF2.
run top/htop and record memory usage
What exactly do you mean by this? The memory use of the steam process, or the overall amount of used/free/cached/etc. memory, or what?
(Bear in mind that Linux will cache files from disk in RAM rather aggressively if it has no better use for that RAM - but anything cached like that is not really "used", because it can be discarded very quickly if the RAM is needed for something else.)
overall used memory, I'm not technically advanced enough to see what exactly Steam is taking, just the percentage numbers, but I do know how htop measures RAM usage. Cached does go up, but that's expected (like you said), but used slightly increases each time between turning on & off tf2.
I've experienced it most egregiously happen while playing for short periods over and over combining things in the inventory, but that could be correlation not causation, and ram usage only returns to normal levels once steam is fully shut down / restarted, cached stays high..er
Your system information
steam-logs.tar.gz
]
Please describe your issue in as much detail as possible:
Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist
Steam keeps a huge amount of memory when reopening games, requires quitting steam and restarting steam to fix, Found while playing TF2
Steam should not be doing this. Ideally, Steam should return to normal memory usage after exitting the game.
Steps for reproducing this issue:
It is entirely possible this is an issue with Linux Runtime 1.0, since no other more recent linux runtime appears when attempting to force a different compatibility option, in this case please allow using Linux runtime 3.0 or 4.0 for TF2 :).