app

Adom Desktop

Public Made by Adom

by adom

Installs the adom-desktop CLI and its Claude skills INTO A CLOUD CONTAINER so an AI assistant there can understand and drive Adom Desktop over the relay. This is the container side, NOT the app itself. The Adom Desktop app is the signed Windows installer under Download below: run THAT on the PC you want the AI to control. Rule of thumb: pkg install here (in your Linux container), Download there (on your Windows PC). Once installed, the AI can drive file transfer, screenshots, notifications, KiCa

adom-desktoptauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues6 Breadcrumbs Pull Requests Activity
Closed general

Closing the app leaves a background process (WebView2 host / port-47200 singleton) that blocks relaunch until killed in Task Manager

Drew Owens · 14d ago ·closed by John Lauer

Type: Bug report · sibling HD issue filed on adom/hydrogen-desktop

Symptom: After closing the Adom Desktop window, a background process keeps running and blocks re-opening the app until it's killed in Task Manager. Same class of bug as reported for Hydrogen Desktop — both are Tauri/WebView2 apps and both exhibit it.

Topology captured live from the host while AD was open (AD is embedded/serving this session, so I did not close it to observe the after-state).

Live topology (AD)

adom-desktop.exe       pid=9572   ppid=8460
 └─ msedgewebview2.exe pid=39696  (+child msedgewebview2 processes)   <-- WebView2 host tree

Fixed loopback listeners owned by AD:

127.0.0.1:47200   AD relay / direct endpoint (pid 9572)
::1:64339 / 127.0.0.1:64339 (WebView2)

Why relaunch is blocked (analysis)

  1. Hardcoded singleton. AD binds a fixed port (47200) and (like HD) uses a named-mutex single-instance guard — no lock file exists to delete, so Task Manager is the only recovery (matches the report).
  2. WebView2 host survives the main. msedgewebview2.exe pid 39696 (+children) is a separate tree from adom-desktop.exe. If AD's exit doesn't close the WebView2 controller/environment and wait for it, the tree lingers holding the user-data-dir lock and keeps port 47200's owner effectively alive.
  3. Embedded-mode ordering. When HD bundles AD (embedded mode), HD supervises AD and respawns it on a failed health probe (observed: [ad-supervisor] AD health probe failed - attempting respawn). A close/respawn race can leave a stale AD (or its WebView2 host) holding 47200 while a new one tries to bind it.
  4. Stray helper: adom-stayawake.exe (C:\Users\drew\adom-screensaver\adom-stayawake.exe, pid 22480) is parented to explorer.exe, not AD — spawned detached and never reaped on close. Needs a defined owner + shutdown.
  5. No shutdown instrumentation in the AD log — can't confirm graceful teardown runs.

Suggested fixes

  1. On exit: close the WebView2 controller/environment and wait for the host to exit; release the single-instance mutex; unbind 47200.
  2. Shutdown watchdog: force-kill AD's own WebView2 host tree + self if graceful exit stalls.
  3. Self-healing startup: if 47200 / the mutex is held by a dead-or-unresponsive PID, reclaim it (kill stale, take over) instead of refusing.
  4. Coordinate embedded-mode close/respawn with HD so the two can't race on port 47200.
  5. Give adom-stayawake a defined lifecycle; add shutdown-path logging.

1 Reply

John Lauer · 6d ago

Shipped behavior fixes in AD 1.9.116. Root cause of the experience: closing the window hides to the tray BY DESIGN (AD must keep serving containers), but it did so silently, and a relaunch on an embedded AD did nothing visible, which reads exactly as 'blocked until Task Manager'. Now: (1) the first window-close shows a one-time toast explaining AD keeps running in the tray and how to quit fully (tray menu); (2) a second launch is NEVER silent: standalone shows and focuses the window; embedded-with-HD-alive shows a toast saying where AD lives; embedded-with-HD-gone (stale flag) treats it as standalone and SHOWS the window. On the singleton analysis: the fixed 47200 port is released via graceful shutdown on real exit, and the single-instance plugin forwards a relaunch to the running process, so no second process fights for the port. If you can still repro a true blocked relaunch on >= 1.9.116, grab %LOCALAPPDATA%\Adom Desktop\startup.log and post it here.

Log in to reply.