Adom Bridge

Fixed in 2.1.164 (insiders now), not yet run end to end.

Why the bridge exes survived: the uninstaller already deletes bridges-cache, but a bridge that is still running holds its own exe open, and the delete silently skips a locked file. Adom Bridge's own process is gone by then, but the bridges it started are separate processes.

What the uninstaller does now, on every real uninstall (not on an update):

• Stops every process whose exe lives under the Adom Bridge folder (bridges, a portable node/python), waits a moment, then deletes.
• Removes bridges-cache, instances, toast-icon.png, and the folder itself once empty.
• Removes %LOCALAPPDATA%\inc.adom.bridge (the WebView2 profile and logs).
• Removes %APPDATA%\adom-wiki\telemetry-stamp.json, and that folder only if it is then empty (a user's own adom-wiki shares it).

Still kept unless "Delete application data" is ticked: ~/.adom (settings and the signed-in session). A silent /S uninstall from Hydrogen leaves that box unticked, so a reinstall still comes back signed in.

I checked the process sweep on its own, but I have not run a full uninstall, because uninstalling Adom Bridge on a remote box takes that box offline for me. Could you re-run your clean-VM uninstall with 2.1.164 and post what is left? I'll close this on that result.

One more data point from a full uninstall on arav-rog (Adom Bridge 2.1.167, 2026-10-02). After the uninstall, %LOCALAPPDATA%\Adom Bridge\ held these files:

adom-favicon.ico
relauncher-last.json
e.children.length
{const

The last two look like fragments of JavaScript written out as file names, so something in Adom Bridge is building a file path from code text. Worth finding even apart from the uninstaller, since it can write junk anywhere that path points.

Found and fixed in 2.1.168 (insiders now).

e.children.length and {const were not Adom Bridge building a path from code. arav-rog's log shows shell_execute calls at 12:31 UTC (thread buck-repro) shaped like:

curl -s -X POST http://127.0.0.1:47084/eval-in -d "{\"js\":\"(()=>{const b=...})()\"}"
... .filter(e=>e.children.length<3&& ...

shell_execute runs through the Windows command shell, which does not know \" as an escaped quote. So the > of each => ended up outside its quotes and was treated as "send output to a file" named after the next word: {const, e.children.length. With no cwd, the command's working folder was Adom Bridge's own install folder, which is where they landed and why they survived the uninstall.

2.1.168:

• A shell_execute with no cwd now runs in %TEMP%\adom-bridge-shell, cleaned daily, never the install folder.
• When a command contains =>, or \" together with </>, the reply's _hint warns that the shell may treat them as redirects and points at run_script with scriptB64, which has nothing for the shell to parse. The skill and CLI help say the same.
• The uninstaller also removes adom-favicon.ico and relauncher-last.json, two more files Adom Bridge writes beside its exe.

Checked on arav-rog (2.1.168): shell_execute "echo probe =>abprobe222.txt" wrote abprobe222.txt into the scratch folder, nothing appeared in the install folder, and the reply carried the warning. I deleted the two stray files still sitting in the install folder from this morning.

The next full uninstall should leave the Adom Bridge folder gone entirely. I'll close this once one confirms it.