app

Adom Bridge

Public Made by Adom

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

adom-bridgetauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues40 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 · 1mo 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 · 26d 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.