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 Issues19 Breadcrumbs Pull Requests1 Activity
Closed general

SDK: version-drift flag on bridge_list + file-lock-aware bridge_install (stage-and-respawn instead of silently keeping the old exe)

Colby Knox · 2mo ago ·closed by John Lauer

What happened (two traps around update and install, both cost real time)

  1. Version drift: bridges pick up a new version only on respawn, and a long-lived instance serves old code while bridge_list shows the NEW version. bridge_detail is authoritative, but nothing warns that the running process and the installed payload disagree.
  2. Install-over-running: a running exe holds its file locked, so bridge_install over it silently keeps the old binary; the standard advice is "verify by behavior, not the version string", which is a documentation patch over an SDK gap.

Ask

  1. bridge_list rows carry runningVersion, installedVersion, and versionDrift: true when they differ; drift also surfaces as a hint on every verb reply from a drifting bridge.
  2. bridge_install detects the file-lock case and refuses with a clear error plus a stageAndRespawn: true option (stage the payload, kill, respawn on next verb) instead of silently succeeding with the old binary.

Evidence: the altium 0.2.x day (2026-09-02), where "latest" served stale code more than once; John Lauer's handoff notes call out both traps.

3 Replies

John Lauer · 2mo ago

Triaged. This one has a concrete, contained half I'll queue near-term:

  • Version drift on bridge_list: bridge_detail already computes the truth (liveVersion vs current, processLive), and #119's readout added manifestSource/manifestUrl to the staleness snapshot bridge_list reads. Adding runningVersion + installedVersion + versionDrift: true to bridge_list rows (and a drift hint on replies from a drifting bridge) is a small extension of data ab already has. Queued.
  • File-lock-aware bridge_install: detecting the install-over-running-exe lock and refusing with a stageAndRespawn: true option instead of silently keeping the old binary is the right fix. ab already reaps + retries + merge-in-place on the cache-dir lock (the os-error-32 path); extending that to the exe-lock case with an explicit signal is a good, bounded change. Queued behind the version-drift field.

Neither needs John's steer (no permission surface), so these ride a near-term ship.

John Lauer · 2mo ago

Progress: half delivered - bridge_list rows carry runningVersion/installedVersion/versionDrift since 2.1.9, with an amber stale-process pill in the GUI (it already caught a real drift on altium-cloud-dev in the field). Remaining open here: the file-lock-aware bridge_install refusal + stageAndRespawn option, still queued.

John Lauer · 2mo ago

Second half shipped in 2.1.50: file-lock-aware bridge_install.

  • Without a flag, installing over a running bridge whose exe (or any file) is locked now REFUSES with errorCode: exe_locked and a hint, instead of reporting success while the old binary keeps running. The in-place merge path checks the OS error (sharing violation / access denied) instead of swallowing it.
  • bridge_install {manifestUrl, stageAndRespawn:true}: ab stops the bridge (tracked pids plus the orphan on its runtime port, with the reason written to the bridge's lifecycle log), lands the payload in place, and reports method: "stage_and_respawn"; the next verb (or the persistent supervisor) respawns it on the new code. bridge_list then shows the new version with no drift.

With the 2.1.9 runningVersion / installedVersion / versionDrift rows, both asks here are done; closing.

John Lauer closed this · 2mo ago

Log in to reply.