Adom Bridge
Public Made by Adomby 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
spawn picks a stale server.py over spawn.kind exe after in_place_merge (fusion360 1.10.4 on ConfRoomROG, ab 2.1.71): exe-owned verbs answered by the Python bridge
Seen on ConfRoomROG with ab 2.1.71 right after bridge_install of fusion-bridge 1.10.4 (method in_place_merge, cache BRIDGE_VERSION 1.10.4, bridge.json spawn.kind: "exe", entrypoint: "adom-fusion-bridge.exe"):
bridge_listsays entrypoint.../bridges-cache/fusion360/adom-fusion-bridge.exe, livePids [50332], installedVersion 1.10.4, runningVersion 1.10.4,languages: ["Python"].- PID 50332 is
C:\Users\john\.adom\adom-runtimes\python-3.12.13\python.exe, started 14:30:19, 28 s after the install wrote the cache. There is no adom-fusion-bridge.exe process at all. - Every verb the Rust exe owns itself answers with the Python bridge's text:
fusion_routing_statereturns "Unknown command: routing_state" with the server.py hint ("check cli/src/commands.rs"), and no reply carries the exe'sshell: "rust"marker. Verbs that pass through to the Fusion add-in still work, which hides the swap.
The difference to AdomLapper (same ab 2.1.71, same 1.10.4 install, exe running, log line "v1.10.4 listening ... sidecar absent"): ConfRoomROG's cache folder still contained a server.py left over from a 1.9.x dev pin, because in_place_merge adds and replaces files but never removes files the new package no longer ships. With server.py present ab spawned Python and ignored spawn.kind: exe. Deleting the stale server.py and killing PID 50332 made the respawn come up as the exe.
Asks:
spawn.kind: "exe"with an existing entrypoint must win over aserver.pyin the folder. A Python entry should only be chosen when the manifest says so.bridge_listrunningVersion is taken from the running process's /status, which the Python bridge also answers with the cache's BRIDGE_VERSION, so the row looked healthy (1.10.4 / 1.10.4). ArunningEntry(exe path or python + script) in the row, and a versionDrift when the running image is not the manifest's entrypoint, would have shown this at once.- in_place_merge could remove files that were in the previous package manifest but not in the new one (or the install could report
leftoverFilesso the bridge owner can act).
bridge_kill {name:"fusion360"} refused because three other threads had used the desktop in the last five minutes; process_kill on the PID with a reason worked as the manual path.