app

Adom Desktop

Public Made by Adom

by adom

Installs the adom-desktop CLI and its Claude skills INTO A CLOUD CONTAINER so an AI assistant there can understand and drive Adom Desktop over the relay. This is the container side, NOT the app itself. The Adom Desktop app is the signed Windows installer under Download below: run THAT on the PC you want the AI to control. Rule of thumb: pkg install here (in your Linux container), Download there (on your Windows PC). Once installed, the AI can drive file transfer, screenshots, notifications, KiCa

adom-desktoptauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues6 Breadcrumbs Pull Requests Activity
Open general

Fusion Bridge: detection caching, timeout, add-in loading, and file transfer issues

AravK · 18d ago

Issues encountered during Fusion 360 bridge session (2026-07-02)

These issues were hit while building a Fusion 3D library from the 138 Adom basic parts and attempting to drive Fusion via the bridge.

Bridge Detection

  • The Fusion bridge caches its detect_fusion() result once at startup in a global fusion_info dict. Since the bridge server started before Fusion was installed, it permanently reported installed: false even after Fusion was installed and running.
  • adom-desktop status (live check) showed installed: true while fusion_start (cached check) said "not installed" — contradictory signals with no indication that one was stale.
  • The only fix was manually killing the bridge's PID so Adom Desktop would respawn it with fresh detection — there's no bridge_restart or bridge_rescan command.

Timeouts

  • fusion_start hit Adom Desktop's 60-second dispatcher timeout on every attempt. A fresh Fusion install takes 2–4 minutes to load (component downloads, updates, cloud sync).
  • The per-verb timeout table allocates 300s for fusion_start, but the actual AD dispatcher clamped it to 60s — passing {"timeout": 300} in args had no visible effect.
  • Each timeout returned a generic "failed" error that didn't distinguish "still launching" from "actually broken."

AdomBridge Add-in

  • The add-in was installed to the correct path (AppData\Roaming\Autodesk\Autodesk Fusion\API\AddIns\AdomBridge) with the correct manifest (runOnStartup: true). Fusion never loaded it.
  • First attempt used a junction link (not followed by Fusion's scanner). Second attempt used a direct file copy. Neither worked — the add-in never appeared in Fusion's Scripts & Add-Ins dialog.
  • Zero error feedback from Fusion — no log, no error message, no entry in the add-in list. The only signal was its absence.
  • Port 8774 (add-in HTTP server) never came online, so all add-in-dependent commands (fusion_get_app_state, fusion_open_lbr, etc.) were permanently blocked.
  • Root cause still unknown — could be a Fusion version incompatibility, a signing/registration requirement in newer builds, or a path issue.

File Transfer

  • send_files only accepts a relative destinationFolder — can't target an arbitrary absolute path like C:\Users\arav\Desktop\FusionBasicParts directly.
  • Workaround was: send a .tar.gz to Downloads, then use shell_execute with PowerShell tar -xzf to extract to the target — functional but roundabout.

Environment

  • Fusion version: Fresh install, trial (29 days remaining)
  • Adom Desktop bridge version: 1.6.6
  • OS: Windows 10/11 (LAPTOP-TO9DNJUR)
  • Adom Desktop: Connected via WebSocket relay

1 Reply

John Lauer · 6d ago

Closing the loop on each item; most of this shipped in the releases since 2026-07-02.

Detection caching (the "installed Fusion mid-session, bridge stuck at installed:false" bug): fixed in AD 1.9.78. Host-app detection is now resolved by AD's generic bridge_readiness::host_app_of gate with a carry-forward cache (installed:true trusted, re-probed on miss) instead of a once-at-startup global. The contradictory "status says installed, fusion_start says not" split is gone: the command fast-fail gate and the readiness probe share one code path. Also, "AD detects INSTALLED only" is now the rule; whether Fusion is RUNNING is the bridge's own authority.

No bridge_restart / bridge_rescan: bridge_kill {"name":"fusion360"} has existed since 1.8.186/187 (reaps tracked PIDs AND port orphans that survived an AD restart); AD auto-respawns the bridge on the next verb, which IS the restart with fresh detection. refresh_bridges re-pulls the bridge code from its wiki page.

Timeouts (fusion_start hitting the 60s dispatcher cap): fixed in 1.9.9 and generalized in 1.9.79. Long verbs get per-verb budgets (a bridge declares them in its bridge.json timeouts block); a timeout is now non-terminal: {errorCode:"timed_out", stillRunning:true, statusVerb:"fusion_get_app_state"} so you poll instead of re-issuing. Every response carries timeoutSeconds.

Add-in loading + file transfer specifics: those live in the Fusion bridge's own code, which is cloud-owned now — please refile anything still broken on adom/adom-desktop-fusion-bridge (its thread actively ships). If a repro still fails on AD >= 1.9.115, post the verb + response JSON here and I'll take it.

Log in to reply.