commands without --ai-thread reports 0 installed bridges instead of refusing (reads as 'no bridges on this box')

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 · 1mo ago ·closed by John Lauer

Seen while re-testing adom/adom-bridge#211 on ConfRoomROG (ab 2.1.153 on the box, CLI 2.1.153 in the container).

adom-bridge --target ConfRoomROG commands without --ai-thread returns a normal-looking reply whose bridges block says count: 0, installed: []. The same call with --ai-thread lists all 8 installed bridges (fusion360 1.10.43, 161 verbs, and the rest).

Every other gated call without an identity answers with an explicit REJECTED and the --ai-thread hint. Here the missing identity turns into "this box has no bridges", which an AI will believe: it is exactly the discovery call an AI makes first, and the answer tells it the bridge it wants is not installed.

Ask: when the caller identity is missing, either answer the same REJECTED as other gated calls, or keep the listing and add the hint, but never report count: 0.

Everything else from #211 checks out now: the live bridges row for fusion360 carries 161 verbs including fusion_show_schematic, fusion_state and fusion_prewarm and not the retired fusion_click_fusion; commands {"bridge":"fusion360"} returns the bridge's own describe with verbCount 161 / manifestVerbCount 161 and no manifestNote.

1 Reply

John Lauer · 1mo ago

Fixed in 2.1.156, fleet-wide.

You were right that this is the worst possible shape for the answer: commands is the first call an AI makes, and a confident count: 0 tells it the bridge it came for is not installed. The cause was one unwrap_or_default() — bridges_summary read the bridge_list reply with .get("bridges").unwrap_or_default(), and the caller_identity_required refusal is a normal-looking payload with no bridges array, so "not a listing" became "an empty listing".

I took your first option and kept the payload informative: the two readers (bridges_summary and bridge_budgets_live) now treat an absent bridges array as NOT-A-LISTING — they surface the underlying errorCode/error/_hint and report count: null. An unknown count must never render as a real one.

Proof, on ConfRoomROG, both boxes and CLI on 2.1.156:

WITHOUT --ai-thread:
  count     : None          (was 0)
  errorCode : caller_identity_required
  error     : REJECTED: 'bridge_list' was refused because it carries no caller identity...
  _hint     : This is not a permission check, it is attribution...

WITH --ai-thread:
  count     : 8
  bridges   : altium 0.2.40, codex 0.1.2, fusion360 1.10.43, grok 1.2.4,
              hd 1.0.0, kicad 1.0.52, native-browser 0.16.33, puppeteer 2.0.679

The general rule is now in CLAUDE.md: when you unwrap a collection out of another verb's reply, ask what the ABSENCE of that key means. unwrap_or_default answers "empty", and for anything an AI reasons over, empty and unknown are opposite answers. A budget or a retry may default safely; an inventory may not.

Thanks for confirming the rest of #211 on the same pass — 161 verbs on the live fusion360 row, no retired fusion_click_fusion, and commands {"bridge":"fusion360"} matching at 161/161.

Fleet on 2.1.156: arav-rog, ConfRoomROG, winvm, AdomLapper.

One thing to watch if you are in a container: the 2.1.153 package shipped a Linux CLI that segfaults on every command — see adom/adom-bridge#215. adom-wiki pkg update adom/adom-bridge gets you to 2.1.156.

John Lauer closed this · 1mo ago