exe bridges need runtimes {ensure:python} and quarantined runtimes should not stay beside the live one

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

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

The Fusion bridge is now a spawn.kind: exe bridge (Rust shell, 1.9.350 on insiders) that still needs ab's managed Python for its sidecar (server.py beside the exe) until every verb is ported. Two things came up on the first real spawn through ab:

No way to provision a runtime from an exe bridge. runtimes is read-only. ab only provisions Python for kind: python bridges, so on a machine whose only bridge is the Fusion exe there is no Python at all and the sidecar cannot start. Ask: accept runtimes {"ensure": "python"} (or "node") on the loopback direct API, returning the same row runtimes.python does once it is ready, using the same no-UAC portable install the python-kind path uses. The exe already asks runtimes for the exe path first (proven on ConfRoomROG), so this is one field away.
Quarantined runtimes sit beside the live one. ~/.adom/adom-runtimes/python-3.12.13.broken-<stamp>/ still contains a python.exe (with no stdlib). A naive scan picked it and the sidecar died with No module named 'encodings'. The exe now skips .broken and asks runtimes first, but it would be cleaner if quarantined runtimes were moved out of adom-runtimes/ (or their python.exe removed) so no other bridge ever trips on them.

Both are the same shape: an exe bridge with a scripted sidecar during a port. The KiCad bridge will want the same when it goes the same way.

2 Replies

John Lauer · 2mo ago

Both shipped in ab 2.1.14 (insiders, publishing now).

1. runtimes {"ensure": "python"|"node"} — done. Works on the loopback direct API (your exe's actual path — verified live with a direct-API POST) and the CLI. It kicks the same idempotent, race-safe, no-UAC provisioning path a kind:python spawn uses: if an install is already in flight you join it, never a second download. The kick is spawned because a first-time download can take minutes — the response returns immediately with the current snapshot plus ensureKicked, and you poll the same runtimes verb until that runtime's state:"ready" (with pct/phase while installing), then use its exe absolute path. On a box with a suitable system interpreter it resolves instantly to that (source:"system").

2. Quarantined runtimes are out of the scan root — done. Validation-failed trees now quarantine to ~/.adom/adom-runtimes-quarantine/ instead of beside the live runtime, so no scan of adom-runtimes/ can ever pick up a stdlib-less python.exe again. Existing corpses (like the one that bit you on ConfRoomROG) are relocated automatically on the first runtime touch after the upgrade (sweep_quarantined, verified live with a seeded corpse). Your exe's defensive "ask runtimes first, skip .broken" remains good practice, but the trap itself is gone.

KiCad's port gets both for free when it goes the same way.

John Lauer · 2mo ago

Both delivered in 2.1.14 and verified live (ensure kick over the direct API; quarantine relocation with a seeded corpse). Details in my earlier reply. Closing.

John Lauer closed this · 2mo ago