That symptom — "can't fork new processes" while the system otherwise feels alive — almost always means you've hit a **resource limit**, not that you're out of CPU or RAM (which your htop confirms is fine). The keybind isn't broken; the kernel or your user slice is refusing to create the new process.
The two prime suspects, given what's on your screen:
1. **Process/task limit on your user slice.** systemd puts your user session in a cgroup with a `TasksMax` cap. Steam is notorious for leaking `steamwebhelper` processes and you've got a swarm of them plus a swarm of Chromium-style renderers. 1027 threads isn't crazy on its own, but if something's slowly climbing, you'll eventually hit the cap and new launches silently fail.
2. **DBus or `/run/user/$UID` issues.** Ctrl-Alt-T fires through your desktop environment, which talks to dbus and writes sockets under `/run/user/1000`. If that tmpfs fills up or dbus wedges, "launch new thing" breaks specifically while existing windows keep working.
Next time it happens (or now, since it's probably creeping up), run these from a terminal you already have open:
```
systemctl --user status
systemctl status user-$(id -u).slice
df -h /tmp /run/user/$(id -u)
ulimit -u
journalctl --user -p err --since "2 hours ago"
dmesg | tail -50
```
The `systemctl status user-$(id -u).slice` line is the money shot — it shows `Tasks: N (limit: M)`. If N is close to M, that's your answer, and `loginctl terminate-user $USER` (or just rebooting) clears it. Long-term fix is killing Steam fully when you're done with it, or raising the limit in `/etc/systemd/system.conf` (`DefaultTasksMax=`).
What desktop environment are you on? GNOME, KDE, something else? That changes where the keybind actually lives and whether dbus is the likely jam point.
