← Commit history

v1.6.7: AD 1.9.63 alignment - ADOM_BIND_HOST bind + runtime-provisioning docs

John Lauer ·148a8fdb5a ·3mo ago ·parent dfa7248
9 files changed +43−19
BRIDGE_VERSION+1−1
@@ -1 +1 @@-1.6.6\ No newline at end of file+1.6.7\ No newline at end of file
CHANGELOG.md+11
@@ -3,6 +3,17 @@ All notable changes to the Adom Desktop Fusion 360 bridge, newest first. Canonical: https://wiki.adom.inc/adom/adom-desktop-fusion-bridge · GitHub backup: `adom-inc/adom-desktop-fusion-bridge` +## 1.6.7 - 2026-06-30++- **AD 1.9.63 alignment (discussion #57).** (1) The bridge HTTP server now honors **`ADOM_BIND_HOST`**+  (`os.environ.get("ADOM_BIND_HOST", "127.0.0.1")`) instead of a hardcoded host, so it never binds a+  public interface and never trips the Windows Firewall "allow access?" prompt AD guarantees users+  won't see. (2) Docs/skills updated to the new **runtime-provisioning** reality: AD provisions Python+  itself (system if on PATH, else a portable no-UAC python-build-standalone copy pinned to 3.12.13,+  spawned by absolute path) - the bridge must **never** bootstrap/download its own Python; state is+  checkable via AD's new `runtimes` verb. No self-bootstrap code existed to remove; only the+  "auto-installs Python" wording in SKILL.md / fusion-onboarding / CLAUDE.md was corrected.+ ## 1.6.6 - 2026-06-30  - **Bridge-SDK self-audit pass.** bridge.json: `homepage` now points to the wiki page (was github - a
CLAUDE.md+7−3
@@ -55,9 +55,13 @@ there. The exact, watched-it-happen release sequence (AFTER publishing to the wi    - **⚠️ TRAP (hit 2026-06-29): `python`/`py` are NOT on the box's shell PATH.** AD spawns the bridge      with its OWN python, so `python install_addin.py` via `shell_execute` returns "Python was not      found" / errors with empty output (same Windows-Store-alias stub that makes a bridge fail to-     respawn). (AD >=1.9.47 now AUTO-INSTALLS Python in the background when Fusion is present but Python-     is missing - so the bridge-SPAWN case is handled by AD; but a `python` you invoke yourself via-     `shell_execute` still won't resolve, so the file-copy deploy below remains the way.) `cmd /c copy` and `robocopy` also fight you on the spaces in `Adom Desktop` / `Autodesk+     respawn). (AD >=1.9.63 PROVISIONS Python itself - a system install if one is on PATH, else a+     portable no-UAC python-build-standalone copy under `~/.adom/adom-runtimes/python-<ver>/`, pinned+     to 3.12.13 - and spawns `server.py` by ABSOLUTE PATH from it. So the bridge-SPAWN case is fully+     handled by AD; NEVER bootstrap/download your own Python. Check runtime state anytime with AD's+     `runtimes` verb (`state ∈ absent|installing|ready|failed`). But a bare `python` you invoke+     yourself via `shell_execute` still won't resolve, so the file-copy deploy below remains the way.)+     `cmd /c copy` and `robocopy` also fight you on the spaces in `Adom Desktop` / `Autodesk      Fusion 360` (robocopy exit 16). **The reliable deploy that needs NO shell + NO python:** copy the      changed add-in file(s) with the BRIDGE's own file verbs - `read_file {path:<cache>/addin/AdomBridge/      commands/<f>.py}` then `write_file {path:<Roaming>/.../AddIns/AdomBridge/commands/<f>.py, content}`
SKILL.md+3−2
@@ -19,8 +19,9 @@ The leading `fusion_` routes to the Fusion plugin; `<action>` is the plugin-side 1. **Check readiness first, don't launch blindly.** Call **`fusion_readiness`** (or AD's    `bridge_readiness`) - it reports `installed` / `running` / `ready` WITHOUT launching anything.    `installed:false` → the user needs Fusion (see [fusion-onboarding](skills/fusion-onboarding/SKILL.md));-   AD **detects** Fusion (never installs it) and **auto-installs Python**. `running:false` →-   `fusion_start` (it blocks until the add-in is ready). `ready:true` → drive.+   AD **detects** Fusion (never installs it) and **provisions Python itself** (a portable no-UAC+   3.12.13 runtime if none is on PATH - never bootstrap your own; check AD's `runtimes` verb for+   state). `running:false` → `fusion_start` (it blocks until the add-in is ready). `ready:true` → drive. 2. **A long op that "times out" at ~60s is usually STILL RUNNING server-side** (the relay caps the    request, not the work). Verify by artifacts (the saved file / screenshots), don't blindly retry. 3. **Never fly blind past a dialog.** Mutating verbs return a dialog array; analyze it and dismiss in
adom-bridge-fusion-manifest.json+5−5
@@ -1,13 +1,13 @@ {   "manifest_version": 1,   "name": "fusion360",-  "version": "1.6.6",-  "url": "https://wiki.adom.inc/download/adom/adom-desktop-fusion-bridge/1.6.6/adom-bridge-fusion-v1.6.6.zip",-  "sha256": "e8535e5aecc13dae9e8d015a43d6e8616a0ba6ec0ac8e5edf66c9077cba91f7c",-  "size": 293313,+  "version": "1.6.7",+  "url": "https://wiki.adom.inc/download/adom/adom-desktop-fusion-bridge/1.6.7/adom-bridge-fusion-v1.6.7.zip",+  "sha256": "c9aa67c269f6da763d08ded74a33eb5e120a5e1894eed2989964793a892613ee",+  "size": 294279,   "verbPrefixes": [     "fusion_"   ],   "healthEndpoint": "/status",-  "released_at": "2026-06-30T13:00:00Z"+  "released_at": "2026-06-30T16:30:00Z" }\ No newline at end of file
bridge.json+1−1
@@ -2,7 +2,7 @@   "manifest_version": 1,   "name": "fusion360",   "displayName": "Autodesk Fusion 360",-  "version": "1.6.6",+  "version": "1.6.7",   "description": "Drive Autodesk Fusion 360 from the cloud: launch Fusion, electronics board layout, design rules, exports (STEP/IGES/STL/3MF/USDZ/OBJ/DXF/DWG/Gerbers/BOM/CPL), fast APS server-indexed cloud search plus browse/recent/file-info/versions, cloud file download/upload and folder creation, and in-app parametric modeling (fusion_run_modeling_script). Never-charge: APS calls are capped to the free tier.",   "homepage": "https://wiki.adom.inc/adom/adom-desktop-fusion-bridge",   "author": "Adom Inc.",
page.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-fusion-bridge",-  "version": "1.6.7",+  "version": "1.6.8",   "type": "app",   "description": "Drive Autodesk Fusion 360 from the cloud via Adom Desktop: launch Fusion, electronics board layout, design rules, exports (STEP/IGES/STL/3MF/USDZ/OBJ/DXF/DWG/Gerbers/BOM/CPL), fast APS server-indexed cloud search with browse/recent/versions, cloud download/upload and folder creation, and in-app parametric modeling. Never-charge: APS calls are capped to the free tier.",   "dependencies": {},
server.py+8−3
@@ -2181,10 +2181,15 @@ def main():     all_commands = list(COMMAND_HANDLERS.keys()) + sorted(ADDIN_COMMANDS)     print(f"[Fusion Bridge] Available commands: {', '.join(all_commands)}") -    server = ThreadingHTTPServer(("127.0.0.1", port), FusionBridgeHandler)+    # AD (>=1.9.63) passes ADOM_BIND_HOST (always 127.0.0.1) to every bridge it+    # spawns. Honor it and NEVER bind 0.0.0.0/'' by default - a public bind pops a+    # Windows Firewall "allow access?" dialog, and AD's guarantee to users is no+    # firewall prompts. Default to loopback if the var is absent (e.g. local dev).+    bind_host = os.environ.get("ADOM_BIND_HOST", "127.0.0.1")+    server = ThreadingHTTPServer((bind_host, port), FusionBridgeHandler)     server.daemon_threads = True-    print(f"[Fusion Bridge] Listening on http://127.0.0.1:{port}")-    print(f"[Fusion Bridge] Health check: http://127.0.0.1:{port}/status (alias /health)")+    print(f"[Fusion Bridge] Listening on http://{bind_host}:{port}")+    print(f"[Fusion Bridge] Health check: http://{bind_host}:{port}/status (alias /health)")     print(f"[Fusion Bridge] Press Ctrl+C to stop.")      try:
skills/fusion-onboarding/SKILL.md+6−3
@@ -20,10 +20,13 @@ Call **`fusion_readiness`** (or AD's **`bridge_readiness`**) FIRST - it reports - `installed:true, running:false` → **no onboarding needed**, just `fusion_start`, then drive. - `ready:true` → drive Fusion directly. -NOTE (AD >=1.9.47): AD **DETECTS** the Fusion host app (via the bridge.json `detect` block - the+NOTE (AD >=1.9.63): AD **DETECTS** the Fusion host app (via the bridge.json `detect` block - the `%LOCALAPPDATA%\Autodesk\webdeploy\production\*\FusionLauncher.exe` path) but **NEVER installs it** --Fusion is the user's host app. AD also **auto-installs Python** in the background if it's missing. So-onboarding is only about Fusion itself + the Autodesk login + deploying the add-in.+Fusion is the user's host app. AD also **provisions Python itself** - a system install if one is on+PATH, else a portable, no-UAC python-build-standalone copy (pinned 3.12.13) under+`~/.adom/adom-runtimes/` - and spawns the bridge from it by absolute path. So **never** download or+bootstrap Python here; the user sees no UAC prompt for a runtime (check state with AD's `runtimes`+verb). Onboarding is only about Fusion itself + the Autodesk login + deploying the add-in.  ## Step 1 — Download the Fusion installer The installer is the small "Fusion Client Downloader" (it streams the full app during install).