app

Adom Hydrogen

Public Made by Adom

by adom

The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity
Closed general

In-workspace memory watchdog: warn at 80 percent, name the top consumer, protect infrastructure via oom_score_adj

Drew Owens · 3mo ago ·closed by John Lauer

Type: Feature request

Context: On 2026-07-20 a single Claude Code process grew to 15.2 GB, filled the workspace's ~15 GB WSL2 ceiling, and was killed by the kernel OOM-killer (bug report filed separately). Nothing warned the user while usage climbed. The first signal was the session dying.

Ask: a lightweight memory watchdog inside the workspace distro that warns before the kernel has to kill anything.

Sketch:

  • A small daemon (or a timer job in the existing workspace-updater) samples /proc/meminfo and per-process RSS every 10-15 s. Cost is negligible.
  • Warn at ~80 percent: toast via HD ("Workspace memory at 82 percent. Largest process: claude, 11.4 GB") so the user can save work or kill the runaway themselves.
  • Act at ~92 percent (optional, configurable): name the top consumer and offer a one-click kill, rather than letting the kernel choose a victim at 100 percent. The kernel picked correctly this time (the runaway was also the biggest task), but it could just as easily have taken out code-server.
  • Adjust OOM priorities: set oom_score_adj so infrastructure (code-server, the session keeper, adom-desktop serve) is protected and user workloads are preferred victims. Cheap, static, and would have produced the same outcome here by design instead of by luck.
  • Log every sample crossing the warn threshold to a file the crash logger (proposal filed alongside) can pick up post-mortem.

Delivery path: the watchdog belongs in the distro image or hd-workspace-tooling so every HD workspace gets it; HD supplies the toast surface it already has.

2 Replies

John Lauer · 2mo ago

Status (2026-08-03): still wanted, not yet built. Queued for the golden-image/tooling roadmap alongside the v23 bake rather than HD-side work; the toast surface it needs already exists. Keeping open.

John Lauer · 1mo ago

Closing, folded into #76. The one piece from this proposal that ships is the OOM priority: the code-server and relay units get the lowest kill priority so a runaway AI process dies first, and terminal shells reset their own priority so that protection does not cover the processes we want killed first. No 80 percent watchdog or toast loop, by John's call; the kernel's own OOM killer is the safety net, and #76 adds an info toast when it fires.

Log in to reply.