Fixing Steam 'opens then closes' on Linux (the steamwebhelper crash loop)

I installed Steam from the official .deb on a freshly updated machine, and instead of a games library I got a window that flashed on screen and immediately disappeared — Steam “opened then closed.” There were also a few alarming-looking messages in dmesg. This is the story of what was actually wrong (it’s almost never what the obvious symptoms suggest) and the one-line-ish fix that resolved it.

Environment

• OS: Ubuntu 26.04 LTS (Resolute), x86_64
• GPU: AMD Radeon RX 7900 XTX — amdgpu driver, Mesa RADV 26.0.3
• Session: Wayland (with XWayland)
• Steam: installed from the official .deb (steam_latest.deb) via dpkg -i
  • steam-launcher 1:1.0.0.85, i386 architecture enabled, all 32-bit libs present

Symptom

After installing Steam, launching it would briefly show a window that then disappeared. The process seemed to start and die. A few related-looking messages also showed up in dmesg.

What it was not

It’s easy to chase the wrong thing here, so these were checked and ruled out first:

• Not a missing dependency / 32-bit library issue. dpkg -l showed Steam installed correctly, dpkg --print-foreign-architectures confirmed i386 was enabled, and ldd on the Steam binary reported no missing libraries.
• Not a GPU driver problem. lspci -k showed amdgpu loaded, and Steam’s own logs detected the RX 7900 XTX with Mesa RADV.
• Not the AppArmor unprivileged-user-namespace restriction. Ubuntu 24.04+ ships kernel.apparmor_restrict_unprivileged_userns = 1, which commonly breaks Chromium-style sandboxes. But Steam ships an AppArmor profile (/etc/apparmor.d/steam) that grants userns, and the running Steam processes were confirmed to be under the steam (unconfined) label — so the sandbox was permitted. (A bare unshare --user from a normal shell does fail, but that’s expected and unrelated: the shell isn’t covered by the Steam profile.)

Root cause

The Steam backend (steam) was running fine and staying up. The process that kept dying was steamwebhelper — the bundled Chromium/CEF browser that renders Steam’s entire UI. Because the window is drawn by steamwebhelper, and it kept crashing and respawning, the result looked like Steam opening then closing.

The evidence that pinned it down:

• The steam backend process was alive, but no steamwebhelper process was present — it died as fast as it launched.
• The webhelper restart counter climbed live: startcount went 29 → 46 → 52 within a couple of minutes (in ~/.local/share/Steam/logs/webhelper-linux.txt).
• The CEF GPU sub-process logged GPU process started: start count: 0 roughly every 10 seconds — a fresh crash each cycle — in ~/.local/share/Steam/logs/webhelper_gpu.txt.
• 100 crash minidumps (the cap) had piled up in /tmp/dumps/completed/, ~870 KB each, all from the webhelper.

This is a CEF-UI crash loop, commonly triggered by a stale or corrupt CEF cache — which often happens right after reinstalling Steam from the .deb on a freshly updated system.

The fix

Fully quit Steam, clear Steam’s CEF/HTML cache, and relaunch so it rebuilds the cache cleanly:

steam -shutdown                  # let Steam close cleanly
pkill -9 steam steamwebhelper    # force-kill anything that lingers
rm -rf ~/.local/share/Steam/config/htmlcache ~/.cache/Steam
steam

After this, steamwebhelper stayed up and the Steam UI loaded normally.

The cache is regenerated automatically on the next launch, so deleting it is safe — it does not touch installed games or your login session.

Useful log locations

If you’re debugging something similar, these are the files worth watching:

File	What it tells you
~/.local/share/Steam/logs/webhelper-linux.txt	webhelper launches + startcount (watch it climb = crash loop)
~/.local/share/Steam/logs/webhelper_gpu.txt	CEF GPU sub-process restarts
~/.local/share/Steam/logs/cef_log.txt	Chromium-level errors/warnings
~/.local/share/Steam/logs/bootstrap_log.txt	client update / bootstrap status
/tmp/dumps/completed/	webhelper crash minidumps

A quick way to spot the crash loop without the GUI:

ps -eo pid,etime,cmd | grep -i steam        # backend up but no steamwebhelper?
grep -o 'startcount=[0-9]*' ~/.local/share/Steam/logs/webhelper-linux.txt | tail -1

If clearing the cache isn’t enough

Escalation steps I had ready but didn’t need this time:

1. Test with the webhelper GPU disabled (isolates a CEF↔Mesa GPU-process bug):

   steam -cef-disable-gpu

   If Steam stays up this way, make the flag permanent in the .desktop launcher.

2. Clean client re-bootstrap, keeping games. Delete everything under ~/.local/share/Steam except steamapps and userdata, plus ~/.steam, then relaunch so Steam re-downloads the client.

Minor unrelated noise (not the cause)

• pactl: not found in the logs — install pipewire-pulse / pulseaudio-utils for audio control.
• Failed to load module "canberra-gtk-module" — cosmetic, safe to ignore.