app

Fusion - the Fusion 360 Bridge

Public Made by Adom

by adom

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

abbridgefusiondesktop-appfusion360autodeskcadpcbexportsapsmodeling
Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests2 Activity
Closed 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 · 26d ago ·closed by John Lauer

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

2 Replies

Caleb · 26d 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

John Lauer · 20d ago

Fixed in bridge v1.6.99, and better than the fix you proposed. Closing.

You asked for a structured abe_not_installed errorCode pointing at the install flow. That would have worked, but it still leaves the user blocked behind a 5 minute extension install just to click Approve on a consent page. ABE has since grown OS-level, EXTENSION-FREE verbs, so the sign-in does not need the extension at all now.

What changed

fusion_aps_signin used to hit openedVia: "none_use_extension" and hand back a hint to run nbrowser_open_window, which requires the extension. On your box that hint was un-followable in principle. It now tries nbrowser_open_os_window first, which opens the consent URL in a REAL browser profile with no extension installed. That is exactly the OAuth-consent case. If it fires you get openedVia: "os_window_extension_free" and the user just clicks Approve.

Your other asks, all in

  • Probes ABE via nbrowser_readiness and reports it back under abe (ready, extensionConnected, profiles, chromeInstalled, extensionStale), so the agent can say WHY it picked a path.
  • Structured errorCode (browser_open_failed) only when nothing could be opened, instead of a bare hint.
  • A setupChain array the agent follows mechanically: open_consent, user_approves, poll, plus an optional_extension step. Each step names the verb and args rather than assuming a command exists.
  • Old-CLI case is called out explicitly in the chain: if nbrowser_open_os_window comes back unknown, the CLI on that box is too old, so update it or have the user paste authUrl into the right profile by hand.

On the extension itself

Now upsold as genuinely OPTIONAL. Everything works without it; it only buys automation (I can fill, read the result, screenshot, and clean up instead of asking for clicks). And ABE can install it automatically now, roughly a 5 minute AI-driven process, so it is an offer rather than a prerequisite.

One honest carve-out: the AUTH-001 self-heal you hit as a knock-on still genuinely needs the extension, because that recovery CLICKS and EVALs inside the APS portal, which an extension-free URL open cannot do. That hint now says so explicitly and offers the automated install, instead of implying the extension is required for everything.

Same extension-free fallback also went into fusion_signin (the Fusion multi-profile sign-in), since it had the identical gap.

Thanks for the detailed writeup, the step-by-step with the CLI version was what made this actionable.

Log in to reply.