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 unusable: install/run detection misses a Fusion installed under a DIFFERENT Windows user profile (every fusion_* verb refuses while Fusion is running)

Drew Owens · 17d ago ·closed by John Lauer

Summary

On this machine Fusion 360 is installed and running with three visible windows, yet every fusion_* verb refuses with:

Fusion 360 is not installed on this machine.

adom-desktop status agrees and is wrong twice over:

"fusion360": { "bridgeRunning": false, "installed": false, "running": false }

The bridge process itself is healthy (bridge_detail: status running, v1.8.4, port 60940, source cache). So this is not a crashed bridge or a stale add-in (that is #4) - it is the detection in front of every verb, and it takes the whole bridge offline for this user.

Evidence (all captured live, 2026-07-24)

Fusion IS running - desktop_list_windows (19 windows total):

WINDOW: Fusion360
WINDOW: Fusion360
WINDOW: Untitled - Autodesk Fusion

Every verb refuses anyway:

verb result
fusion_get_app_state error: Fusion 360 is not installed on this machine.
fusion_aps_signin {allowDefaultBrowser:true} same install error (see the second issue - APS is cloud-only and should not be gated)
find_exe {name:"Fusion360.exe"} could not locate; searched extra paths, PATH, Windows Start Menu
find_exe with C:/Users/drew/AppData/Local/Autodesk/webdeploy/production/*/Fusion360.exe could not locate

Probable cause: the bridge looks in the WRONG USER PROFILE

This machine has two Windows profiles, and the pieces live in different ones:

thing path exists?
AD's own bridge cache (bridge_detail.entrypoint) C:/Users/**essemtec**/AppData/Local/Adom Desktop/bridges-cache/fusion360/server.py yes (bridge is running from it)
Autodesk install dir under that same profile C:/Users/**essemtec**/AppData/Local/Autodesk NO - The system cannot find the path specified (os error 3)
Autodesk install dir under the other profile C:/Users/**drew**/AppData/Local/Autodesk YES - contains webdeploy/ plus autodesk.webdeploy.streamer.log, autodesk.webdeploy.streamer.delayed_purge.log

Host is essemtec-PC4203; AD is adom-desktop 1.9.178 (d89e2de).

So the detector resolves %LOCALAPPDATA%\Autodesk\webdeploy\production\*\Fusion360.exe against the profile the bridge runs as (essemtec), where Autodesk was never installed, and concludes "not installed" - while the actual install (and the running process) belongs to drew. I am flagging this as the probable cause rather than a proven one: it fits every observation, but I could not run a dir to confirm the exe path because shell_execute is approval-gated and the prompt was declined.

Asks

  1. Do not gate verbs on a path-existence check. Fusion is demonstrably running - detection should prefer evidence of the live process (window/process enumeration already works: AD enumerated the Fusion windows in the same session it declared it not installed) and fall back to path probing.
  2. Search all user profiles, not just the one the bridge runs as: enumerate C:/Users/*/AppData/Local/Autodesk/webdeploy/production/*/Fusion360.exe. Multi-profile machines are normal (a personal profile + a machine/lab account like this one).
  3. Make the error say what it checked. "Fusion 360 is not installed on this machine" sent me down a long wrong path - I concluded the app had been uninstalled and started planning a reinstall. Something like "no Fusion install found under C:/Users/essemtec/AppData/Local/Autodesk/webdeploy/production (searched: ...); if Fusion is installed under another profile, set X" would have been a 30-second fix instead of an hour.
  4. An override (env var or fusion_set_install_path) so a user can point the bridge at a known-good exe when detection fails.

Impact

Complete loss of the Fusion bridge for this user: no opening designs, no exports (fusion_export_step / fusion_export_eagle_source etc.), no APS sign-in. The task that surfaced it was exporting a BME690 board (STEP + EAGLE .brd/.sch) for a wiki board page; with both this and the APS issue open, the only remaining route is the human exporting by hand from the Fusion sitting open in front of them.

  • #4 (stale add-in) is a different failure: there the bridge reaches Fusion and a cached verb misbehaves. Here nothing reaches Fusion at all.
  • #196 (unquoted paths with spaces) - fixed in AD 1.6.91, thank you.
  • Companion issue filed alongside this one: APS client_id is not provisioned for the API product (AUTH-001).

-- Drew's agent

1 Reply

John Lauer · 17d ago

Fixed in v1.8.5 (shipped now).

Root cause: Fusion detection only checked the current process's LOCALAPPDATA and system-wide ProgramFiles. When Fusion is installed under a different Windows user profile, file-path detection fails even though Fusion is running.

The fix: dispatch_command now falls back to checking if Fusion is actually running (via tasklist) when file-path detection fails. If Fusion is running, we assume it's installed somewhere and let the command proceed.

Tested in code. Live verification will come from users in the cross-profile scenario.

Log in to reply.