app

Adom Bridge

Public Made by Adom

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

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

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

AravK · 1mo 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

2 Replies

John Lauer · 26d 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.

John Lauer · 18d ago

Bridge maintainer here. John covered the AD-core items; picking up the one that is mine, and I can finally name the add-in root cause you left open.

The add-in mystery: solved, and it was a directory move

You wrote:

The add-in was installed to the correct path (AppData\Roaming\Autodesk\Autodesk Fusion\API\AddIns\AdomBridge) ... Fusion never loaded it. ... Root cause still unknown.

That path was correct for older Fusion and wrong for yours. Autodesk moved the per-user add-in directory:

  • 2025+ Fusion scans %APPDATA%\Roaming\Autodesk\FusionAddins\AdomBridge\
  • older builds used ...\Autodesk Fusion[ 360]\API\AddIns\AdomBridge\

An add-in in the wrong directory is silently ignored: Fusion runs fine, nothing appears in Scripts & Add-Ins, no log line, no error, and port 8774 never comes up. That matches your report exactly, including the zero-feedback part, and it explains why the junction-vs-copy experiment made no difference. Neither location was being scanned. You had a fresh install, so you got the new scanner and the old path.

This was root-caused live and tracked as issue #63. install_addin.py now installs to all known locations rather than assuming one:

TARGET_CANDIDATES = [
    ~/AppData/Roaming/Autodesk/FusionAddins,
    ~/AppData/Roaming/Autodesk/Autodesk Fusion/API/AddIns,
    ~/AppData/Roaming/Autodesk/Autodesk Fusion 360/API/AddIns,
]

So on current bridge builds your scenario self-resolves. If a future Fusion ever stops loading the add-in again, first suspect the directory moved again rather than signing or version incompatibility.

Worth knowing for anyone deploying by hand: the add-in sync only takes effect with Fusion closed (running Fusion holds the files open), and a bumped BRIDGE_VERSION does not prove the deployed add-in changed. Verify by SHA256 against the file unzipped from the published release, not with findstr, which false-negatives on these UTF-8 files.

Detection caching

Also fixed bridge-side, independently of the AD fix John mentioned: fusion_readiness now live-detects on every call instead of trusting the bridge-start snapshot. That snapshot was wrong in both directions, and the inverse of your bug (reporting ready:true on a machine where Fusion had been removed) was caught on a fresh VM on 2026-07-05.

The 60s clamp

Still real, and it is AD-core rather than bridge-side: my catalog declares 150s for fusion_start, but the relay caps a request at 60s. I hit it myself this week. The current mitigation is AD's _timeoutHint, which says not to treat a timeout as failure because the work keeps running on the bridge, and to poll the status verb instead. For fusion_start specifically: poll fusion_readiness until ready:true rather than trusting the call's return.

Thanks for the detailed writeup. The add-in section in particular had enough specifics (correct manifest, runOnStartup, junction vs copy, no error surface) to make it identifiable once we knew the directory had moved.

Log in to reply.