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 Packages Releases Dependencies Issues11 Breadcrumbs Pull Requests1 Activity
Closed general

Workspace OOM (claude at 15.2 GB) kills the session and HD silently reloads the workbench, telling the user nothing

Drew Owens · 19d ago ·closed by John Lauer

Type: Bug report

Symptom: A Claude Code process inside the WSL2 workspace grew until it exhausted the distro's RAM. The kernel OOM-killer terminated it, and HD's only visible reaction was a silent VS Code workbench reload. The user saw RAM pinned at 100 percent and a session vanish, with no explanation anywhere in the UI.

Evidence (2026-07-20, container dmesg + HD log):

12:59:32  python3 invoked oom-killer ...
          Out of memory: Killed process 18617 (claude)
          total-vm:21247056kB, anon-rss:15212208kB        <- 15.2 GB resident
12:59:43  [frame-nav] ALL: http://localhost:7380/?folder=/home/adom/project   <- workbench reload

One claude process reached 15.2 GB resident (21 GB virtual). The workspace ceiling is ~15 GB (WSL2 default, half of the 31 GB host), so this single process filled it. The OOM-killer picked the largest task, killed it, and code-server reloaded 11 seconds later. Single event this boot.

The problem: HD watched all of this happen and told the user nothing.

  • The workbench reload at 12:59:43 is the only trace in HD's log, and it is indistinguishable from any other reload.
  • The user's Claude session died without a message. (Compare the sleep/resume report, #60: sessions vanish, no explanation.)
  • HD already polls workspace health; memory is not part of that picture.

Asks:

  1. Detect the OOM. The distro's kernel log states the cause and the killed process by name. HD (or the workspace updater) should read it after any unexpected code-server/workbench reload and attach the cause to the event.
  2. Tell the user. A toast or banner: "The workspace ran out of memory. The process claude (15.2 GB) was terminated. The window reloaded to recover." Silent recovery reads as a random glitch and generates support questions HD could answer itself.
  3. Add memory to workspace health. /workspace/health reports distro + code-server reachability today; include distro memory (used/total, top consumer) so a session nearing the ceiling is visible before it dies.

Related: #60 (sessions lost on sleep/resume, also silent), and the crash-logging proposal filed alongside this one.

1 Reply

John Lauer · 9d ago

Closing after review with John (2026-08-01).

Splitting this report into its two halves:

  1. The session death itself: a claude process grew to 15.2 GB, the kernel OOM-killer took it down. That is Linux doing its job on a runaway process. Nothing at the HD layer can "fix" the kill, and the conversation was not actually lost. Claude Code persists sessions to disk; after the workbench comes back the tab re-instantiates and the thread continues when nudged. That part is just how Claude works and we are not going to fight it.

  2. The part with real product value: the user was told NOTHING (RAM pinned at 100 percent, a tab vanishes, a silent workbench reload). That ask lives on in #14 (in-workspace memory watchdog: warn at 80 percent, name the top consumer) and #15 (crash flight recorder). Those proposals are the right fix surface, so tracking continues there rather than here.

Log in to reply.