Adom Hydrogen

Triaged with John today, and a correction to the premise first: the VM does have a cap (WSL2 gives it half the host RAM, 16 GB on a 32 GB box, plus swap), and the kernel did exactly what it should, it killed the two offenders. Nothing "went down": the VM thrashed for about ten minutes and came back on its own, which is what you saw when you waited. What was wrong was on our side: the banner told you the Windows WSL service was not responding and hinted at sleep and a Windows restart, none of which had been measured. The stats probe inside the distro exceeded its 3 s cap three times while the VM was thrashing, and that tripped the wedge flag.

What ships, one change with #52:

1. wsl.exe never observes the workspace again, it only starts and stops the distro. Health comes over HTTP (code-server's health URL, the adom-vscode extension port, the relay), and the message names exactly what did not answer and for how long, never a cause.
2. One surface: the banner inside the VS Code pane with Reconnect. The toast on top goes.
3. CPU, GPU, RAM and the kernel's OOM-kill counter come from Win32 and one HTTP request, no wsl.exe. The meter ticks every 2 s and pauses while the window is hidden.
4. code-server and the relay get the lowest OOM kill priority so a runaway build or render dies first; terminal shells reset their own priority so AI processes stay killable.
5. When the OOM counter rises, an info toast names the killed process and its size, so you know it happened without being interrupted.

No earlyoom, no per-thread caps, no memory watchdog, by John's call: Linux is the safety net, and the fix is to stop misreporting it. #14 and #15 are closed into this.

Shipped in Hydrogen 1.0.387 (needs adom-vscode 1.1.59 in the workspace, which ships with it). Closing.

First, the correction to the premise, confirmed: the VM is capped (WSL2 gives it half the host RAM, 16 GB on a 32 GB box, plus swap) and the kernel killed the offenders exactly as it should. Nothing "went down" that needed us; the VM thrashed and recovered on its own. What was wrong was our messaging, and that is what this fixes.

What shipped:

1. The meter never spawns wsl.exe. CPU, RAM and the kernel OOM count come from the extension's GET /stats over HTTP. Verified on arav-rog: stats_source "distro", real numbers, over HTTP.
2. One surface. The "Windows' WSL service is not responding, restart Windows" toast is gone. A stalled editor backend shows the VS Code pane's Reconnect banner, and its text now names what did not answer instead of guessing at sleep.
3. Out-of-memory protection. code-server and the relay units carry OOMScoreAdjust=-900 so a runaway build or render is killed first; interactive terminal shells reset their own score to 0 (via /etc/profile.d) so the AI processes they spawn stay killable, while the relay's non-interactive login shell keeps its protection.
4. The notice you asked for: when the kernel frees memory by ending a process, an info toast names it (process and size when the kernel log is readable). Info level, never a banner.
5. The meter ticks every 2s and pauses while the window is hidden.

#14 (the oom_score_adj idea) and #15 (the flight recorder) are closed into this: the priority piece from #14 shipped here, and the flight recorder stays out by decision.

The unit changes apply on the next launch after this update, when ah rewrites the code-server and relay units.

Thanks for the correction on the premise; the capped VM plus a kernel doing its job is a better model than the one I filed with, and the messaging changes are the right fix.

One observation from inside the workspace, offered as data rather than a reopen: the container half of item 3 is not in effect on my box yet.

adom-vscode extension           1.1.76          (past the 1.1.59 you named)
systemctl show code-server -p OOMScoreAdjust   -> OOMScoreAdjust=0
MainPID 161 /proc/161/oom_score_adj            -> 0
/etc/systemd/system/code-server.service.d/     -> one drop-in, Environment= only
/etc/profile.d/                                -> 01-locale-fix.sh, hd-env.sh; no oom_score_adj reset

So code-server here is still as killable as anything else, and an interactive shell is already 0 with nothing resetting it. My guess is that the drop-in and the profile.d file ride in the container image rather than the extension, and this workspace was re-imaged on 09-10 to v27-full, three days before 1.0.387 shipped. If that is right, what triggers the pickup: a new image, or does something in the workspace install them on update?

Not reopening, since the Windows half is verified and this may be my box waiting for an image. Happy to re-check here once you say what should deliver it.