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

Bridge shells adom-desktop.exe (the GUI) as a CLI — every call foregrounds AD on the user's screen

John Lauer · 17d ago ·closed by John Lauer

Caught live on the owner's laptop (2026-07-24, AD startup.log):

Args: ["C:\Users\john\AppData\Local\Adom Desktop\adom-desktop.exe", "desktop_list_windows", "{}"]
CWD:  "...\Adom Desktop\bridges-cache\fusion360"
FOREGROUND: second launch - AD was launched again; showing the existing instance

The bridge is invoking adom-desktop.exe with CLI-style args (desktop_list_windows). On Windows that exe is the GUI, not the CLI. The GUI has no verb subcommands, so the call does nothing useful - but each invocation trips AD's single-instance handler, which until now treated it as a human launch and brought AD's window to the foreground with focus. The bridge polls, so the user's AD kept popping to the front all day ("AD randomly comes to the foreground").

Two asks:

  1. Preferred (per the Bridge SDK): call AD back over the loopback direct API, not by shelling an exe. POST http://127.0.0.1:/command with {"command":"desktop_list_windows","args":{}} - the port comes from ADOM_DIRECT_API_URL in your spawn env (fallback: read ~/.adom/direct-api-port). Full contract: the adom-desktop-direct-api skill.
  2. If you must shell out on Windows, the CLI binary is adom-desktop-cli.exe (bundled next to the GUI, on PATH). Never adom-desktop.exe - that is the GUI.

AD-side hardening ships in 1.9.176: a second launch of the GUI with positional args no longer foregrounds (it logs the misuse + the args to startup.log and the Activity Log instead). So the focus-steal stops even before your fix, but the calls remain no-ops until you switch to the direct API or the CLI exe.

1 Reply

John Lauer · 17d ago

Fixed in v1.8.4 (shipped just now).

The bridge no longer shells the GUI. _ad_call's fallback order is now:

  1. in-process ad_client (unchanged), then
  2. the loopback direct API (ADOM_DIRECT_API_URL, fallback ~/.adom/direct-api-port), POST /command with {command, args} (your preferred fix #1), then
  3. as a last resort, adom-desktop-cli.exe only. _find_adom_desktop_cli will never return adom-desktop.exe again (your fix #2).

So no desktop_* call from the bridge can launch or foreground the GUI. Combined with AD 1.9.176's hardening, the focus-steal is closed from both sides.

Verified: bridge reports running 1.8.4, the CLI finder targets adom-desktop-cli.exe, and the GUI-exe shell path is gone. Closing. Thanks for the precise repro + the fix directions.

Log in to reply.