bridge_install replaces a dev-pinned bridge cache (2.1.66): make the pin refuse explicit installs; Codex's patch is on the kicad-bridge page

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 bug report

John Lauer · 2mo ago ·closed by John Lauer

Measured on ab 2.1.66 (arav-rog, 2026-09-07)

bridge_dev_mode {"name":"kicad","on":true} -> devPinned:true, .dev-pin written.
bridge_install {"manifestUrl":".../insiders/files/kicad-bridge/version.json","force":true} -> ok:true, the cache was replaced and the .dev-pin file was gone afterwards (bridge_list showed devPinned:false).

So the pin protects against the sweep, on-launch sync, on-use auto-update and refresh_bridges (as documented), but an explicit install from any AI thread still replaces a developer's pinned cache without a word. On a shared box (arav-rog has three or four threads driving it) that is exactly the case the pin exists for: another thread's routine "install latest" wipes a dev build mid-test.

Ask

bridge_install (with or without force) refuses while .dev-pin exists, with errorCode dev_pinned and the hint to run bridge_dev_mode {on:false} first. The pin is the developer's explicit statement; unpinning is the explicit override, not force:true.
Serialize pin changes with cache replacement so a pin set during an install cannot be lost.

A patch already exists

Codex wrote one for 2.1.38 (commit 792b5c0a) while building the KiCad live routing feature: demo/routing/ab-dev-pin-fix.patch on the kicad-bridge page. It adds src-tauri/src/cache_mutation.rs (a guard shared by install and refresh), updates the bridge_dev_mode help text, and ships a standalone Rust harness with four pin-guard tests. It passed cargo check --locked against 2.1.39 source on AdomLapper and the four tests pass, but it was never built into a Windows ab or installed, so it needs a rebase onto 2.1.66+ and a live test: pin, explicit install, expect refusal; unpin, install, expect success. Please do not apply it blind; the guard's placement moved with the async bootstrap changes.

The KiCad routing release (kicad-bridge 0.9.340) does not depend on this fix; it only documents that a pin alone does not protect a dev cache on a shared box.

1 Reply

John Lauer · 2mo ago

Fixed in ab 2.1.70 (insiders manifest live, fleet updating). bridge_install now refuses while the bridge's .dev-pin exists, force:true included, with errorCode dev_pinned and a hint to run bridge_dev_mode {name, on:false} first; the refusal happens before any cache change. Cache swaps and pin changes share one lock (bridge_cache::CACHE_MUTATION): set_dev_pin refuses while an install is replacing a cache, so a pin set mid-install cannot be lost with the old dir. Proved on AdomLapper 2.1.70: pin kicad, forced install from the insiders kicad manifest returned dev_pinned with the cache untouched, unpin, row devPinned false. I did not apply the Codex patch; the guard sits at the point the canonical bridge name is known in install_from_manifest_url_opts, which is where the 2.1.6x async bootstrap left the swap. CLAUDE.md dev-pin rule updated: the pin is absolute, unpinning is the only override.

John Lauer closed this · 2mo ago