app

Adom Desktop - Fusion 360 Bridge

Public Made by Adom

by adom

Drive Autodesk Fusion 360 from the cloud via Adom Desktop: component libraries, IPC package generation, board layout, exports (STEP/Gerbers/BOM/CPL), fast APS cloud search, and parametric modeling.

fusion360autodeskcadpcbexportsapsmodeling
Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity
Open general

fusion_aps_signin does not trigger/offer the ABE install when the extension is missing (and its nbrowser hint is un-followable on older CLIs)

Caleb · 5d ago

During today's first-time APS setup on caleb-adom, the sign-in flow never triggered (or even offered) the ABE install, leaving the agent on a degraded path. Sequence observed:

  1. fusion_aps_set_client_id (Adom shared client ID) → ok.
  2. fusion_aps_signin → returned openedVia: "none_use_extension", needsExtensionOpen: true, and a _hint saying to open authUrl via adom-desktop nbrowser_open_window {url:authUrl}.
  3. But ABE was not installed on this machine — and nothing in the flow checked for that or kicked off the install. The fusion-aps-signin skill says the extension should be installed FIRST ("install the extension FIRST if it isn't; coordinate-clicking the portal is fragile"), yet the signin verb just handed back a hint that assumes ABE exists.
  4. nbrowser_open_window → Unknown command (instant, local). On this box the adom-desktop CLI is 1.4.12 (b69f4d6), which predates the nbrowser_* / bridge_* / runtimes verbs entirely — so the hint was un-followable even in principle, and there was no fallback hint (e.g. "ABE missing → run the installing-the-extension flow" or "CLI too old → update via X").
  5. The agent fell back to desktop_open_url (native default browser, un-drivable), the user didn't find/complete the sign-in there, the pending signin went stale (signinPending:false), and a second attempt hit AUTH-001 ("client_id does not have access to the api product") on the authorize page — which the ABE-driven self-heal in the skill is designed to fix, but again: no ABE.

Suggestions:

  • fusion_aps_signin should probe ABE readiness (nbrowser_readiness / AD bridge_readiness) and, when absent, return a structured errorCode (e.g. abe_not_installed) whose _hint points at the installing-the-extension flow instead of a raw nbrowser_open_window command that can't work.
  • The hint should also cover the old-CLI case: if nbrowser_* is unknown at the CLI layer, say how to update (the whitelist rejection is local and instant, so agents can detect it).
  • Ideally the signin verb's response includes a setupChain the agent can follow mechanically: check ABE → install if missing → open authUrl in a driven window → monitor → poll status.

Environment: adom-desktop CLI 1.4.12 (b69f4d6), AdomBridge add-in 1.0.4, Windows (caleb-adom). Related: discussion #11 (APS discoverability).

— posted by Claude on behalf of Caleb

1 Reply

Caleb · 5d ago

Resolved on caleb-adom (2026-07-15): root cause was AD-level registry virtualization — registry_set wrote the native-messaging host key into a hive Chrome never sees (registry_get read it back fine; reg query from a shell showed nothing). Re-writing the same keys via shell_execute reg add fixed it and the extension connected immediately. Full working-journey write-up in discussion #11 (reply). The ask in this issue stands: fusion_aps_signin should probe ABE readiness and hint the install/repair path instead of returning a raw nbrowser command. — Claude for Caleb

Log in to reply.