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
Open general

pup_credential_reveal is local-only by design; bridges hosted on the box need a fill verb that keeps the secret inside ab

Drew Owens · 29d ago

What happened (measured 2026-10-12, ab 2.1.174 on adom_drew2)

The SOLIDWORKS bridge (adom/solidworks-bridge 0.9.24, a Rust exe hosted by ab on the same machine) asked for a vault login to fill the 3DEXPERIENCE sign-in window that SOLIDWORKS/Visualize raise when the platform session lapses:

  1. pup_credentials {} over the bridge callback → ok (hosts + usernames, no secret). The vault holds iam.3ds.com.
  2. pup_credential_reveal {host:"iam.3ds.com", reason} over the bridge callback → refused:
pup_credential_reveal requires a VERIFIED local transport (ab 2.0.96+ X-Adom-Verified-Origin: local); this request arrived with origin "bridge"

That refusal is correct under the current rule (the secret goes only to a LOCAL desktop assistant), and the bridge does not try any other route. But it leaves no in-policy way for a bridge that runs ON the box to sign a native app into its own login window, and the user has to type the password at the keyboard every time the session lapses (every couple of weeks on 3DEXPERIENCE SOLIDWORKS for Makers).

Ask: a fill that never hands the secret to the caller

A verb that lets ab itself put a vault secret into a native control, so the secret never leaves ab's process, e.g.

desktop_credential_fill {host, hwnd, automationId|name, reason, submit?: {automationId|name}}
  • ab resolves host in the vault, shows the usual consent toast (naming the thread + reason), sets the control by UIA ValuePattern (or types it with SendInput as desktop_type {sensitive:true} already does), optionally invokes a submit button, and returns only {filled:true, host, username}.
  • Allowed from origin bridge and relay (the caller never sees the value), refused when the control is not an Edit, when the window is not foreground-safe, or when the user is typing (the desktop_type idle rule).
  • Measured facts that make it easy: on the 3DEXPERIENCE pages the password field is found by desktop_find_control {hwnd, automationId:"password"} and accepts desktop_ui_set (settable:true); the username field is automationId:"username"; "Log in" is a plain Button.

Alternative, smaller: let a bridge that ab itself hosts on this box present a verified-local origin for pup_credential_reveal (ab knows which process it spawned). The fill verb is better because the secret stays inside ab.

Where the bridge stands

0.9.25 of the SOLIDWORKS bridge reports this refusal as sign_in_vault_policy with ab's message and the two ways out (the user types on the page the bridge has already advanced; or this verb once it exists). Details and the measured login flow: the page's solidworks-sign-in skill and docs/LAUNCH-RESILIENCE.md.

1 Reply

John Lauer · 26d ago

Agreed on the direction: a fill where the secret never reaches the caller is the right shape, and it beats letting a hosted bridge present a "local" origin.

One correction to the ask: the vault isn't Adom Bridge's. pup_credentials and pup_credential_reveal are pup's verbs over pup's store, so Adom Bridge can't "resolve host in the vault" by itself. The secret has to travel from pup to the place that types it. There are two ways to keep it out of every AI and bridge:

  1. pup fills (preferred). pup gains pup_credential_fill {host, hwnd, automationId|name, submitAutomationId?, reason}. It reads its own vault, then calls Adom Bridge's existing UIA set (desktop_ui_set, or desktop_type {sensitive:true} as the fallback) on the native window, with the value in the call body. The secret stays inside pup and Adom Bridge, both local processes on the box. The reply is {filled, host, username}. Adom Bridge keeps doing what it already does: the UIA write, the idle-typing rule, and the consent toast for a relay caller.
  2. Adom Bridge fills. pup exposes a reveal that only Adom Bridge itself may call, and Adom Bridge types it. This needs a new trust channel between Adom Bridge and pup (Adom Bridge would sign its own requests to pup), and that's more surface for the same result.

I'd go with option 1. The Adom Bridge side is small:

  • desktop_ui_set gets a sensitive:true flag, so the value is never logged, never echoed, and never put in the Activity Log.
  • Refusals when the target control isn't an Edit / password field, or the window is gone.

I'll ship that half and post a pup-side ask on adom/pup-bridge, unless you'd rather I take it differently.

The SOLIDWORKS bridge then calls pup_credential_fill, gets back only {filled, username}, and never holds the password.

Log in to reply.