--- name: fusion-multiprofile-signin description: > Fix Fusion 360 signing into the WRONG Autodesk account because it fires its OAuth at the OS-DEFAULT browser. Fusion opens sign-in in whatever browser is default (often a personal Chrome profile), but a user's Autodesk seat usually lives in a DIFFERENT profile (their work Google/SSO). The bridge's fusion_signin verb reads the full authorize URL Fusion wrote into that wrong browser's history and re-opens it in the RIGHT profile, where it completes back to the running Fusion. Trigger words - fusion wrong browser, fusion wrong account, fusion signs into wrong profile, fusion opens personal chrome, autodesk wrong profile, multiple chrome profiles autodesk, fusion_signin, fusion sign in wrong google account, fusion default browser oauth, authenticate fusion multiple profiles. --- # Signing Fusion into the right browser profile (fixing Fusion's dumb OAuth) ## The problem (Fusion's fault, we work around it) Fusion's desktop sign-in fires an OAuth URL at the **OS-default browser**. If your Autodesk account lives in a *different* Chrome/Edge profile - personal Chrome is default but your seat is `you@work.com` in your work profile - Fusion signs you into the wrong account or stalls on the wrong Google session. Autodesk should let you pick the profile; they don't. So we do. Verified live (John, 2026-07-21): Fusion opened his personal Chrome (`jlauer12@gmail.com`) when his Autodesk login is `john@adom.inc` in his work profile. ## The fix: `fusion_signin` ```bash adom-desktop fusion_signin '{"profile":"chrome:you@work.com"}' # fix + REMEMBER your profile adom-desktop fusion_signin '{}' # auto: probe/remember/ask ``` What it does: 1. **Reads the full authorize URL out of the wrong browser's History.** Fusion writes a complete `developer.api.autodesk.com/.../authorize?client_id=...&code_challenge=...&state=...&request_id=idsdk-...` into whatever browser it opened. The address bar rewrites within a second (the Autodesk SPA cleans it), but Chrome's/Edge's **History DB keeps the full URL** - so the bridge copies the locked History file and reads the newest Fusion (`idsdk`/`idmgr`) authorize entry. Racing the address bar over the relay does NOT work; the History read is the reliable capture. 2. **Re-opens that exact URL in the RIGHT profile, backgrounded** (ABE / `nbrowser_open_window`), so it never interrupts what the user is doing. 3. It completes back to the **running Fusion** on its own. The redirect is `accounts.autodesk.com/idmgr/callback` + an `autodesk://` protocol handoff matched by `request_id`, **not** a browser-specific localhost port - so the profile no longer has to be the OS default. Any profile that finishes the login hands the token to Fusion. ## Picking the right profile - **Best:** the user tells you once (`{profile:"chrome:you@work.com"}`); the bridge **remembers** it (`~/.adom/fusion-signin/profile.json`) for every future sign-in. - **Auto:** the verb probes each live profile with `nbrowser_login_state` against accounts.autodesk.com and prefers the one holding a real Autodesk session; failing that, a work/corporate identity over a consumer mailbox - and says it is guessing. - **Unsure:** it returns `stage:"ask_profile"` - ASK which account their Autodesk login is, do not assume. Name profiles by identity (`Chrome - you (you@work.com)`), never "your browser". ## The staged loop - `stage:"click_signin"` - Fusion has not opened the browser yet. Click Fusion's **Sign In** (it is a webview with no UIA node, so an image-space `desktop_click` on the button; screenshot the Fusion window first for a shotId), wait ~4s, call `fusion_signin` again. - `stage:"opened"` - the URL is now in the right profile (`signinWhere`). Tell the user where, why (`signinProfileReason`), and offer: they finish it, you foreground it, or (with their OK) you drive "Continue with Google/Apple/Microsoft". **Never type their password/2FA** - escalate a real secret with `fusion_notify_owner`. Poll `fusion_readiness` until `ready:true`. - `stage:"ask_profile"` - ask which profile, then re-call with it. ## The ~2-minute clock and the last-mile handoff (learned live 2026-07-21) Two things bite after the profile fix works: 1. **Fusion's sign-in request EXPIRES in ~2 minutes.** If capture-to-completion takes longer (e.g. the user logs in by hand and dawdles), the callback page shows **"Sign-in request expired"** and Fusion never gets the handoff. `fusion_signin` now REFUSES a captured URL older than ~150s and returns `stage:"stale"` telling you to get a FRESH request: **fusion_stop -> fusion_start** (resets Fusion to a clean "Welcome to Fusion"), click Sign In, then call fusion_signin again promptly. Completion is near-instant when the target profile is ALREADY signed into Autodesk (it auto-consents), so pre-sign-into the profile once and future sign-ins fly. 2. **The `autodesk://` protocol handoff is the real last mile.** After login the callback page (`signin.autodesk.com/idmgr/callback#code=...`) says **"Click Open Identity Manager in the browser dialog"** with a **Retry** button. Fusion completes only when Chrome's native *"Open Autodesk Identity Manager?"* dialog is accepted (tick "Always allow", click "Open"). If it does not auto-fire: click **Retry** on the callback tab, then accept the Chrome Open dialog (a native UIA dialog - `desktop_find_control`/`desktop_ui_click` "Open", or a foreground click if UIA Invoke no-ops). This step is the same for ALL Fusion sign-ins; it is not caused by the profile move. ## Gotchas - Read History AFTER Fusion has opened the browser, and take the NEWEST authorize entry - a stale one from a previous attempt carries a dead `request_id` and Fusion (waiting on a new one) never gets it. - If the wrong account completes in the default browser before you move it, sign Fusion out and re-run. - Chrome keeps History locked; always COPY the file before opening it (the verb does this). - This is also the sign-in stage `fusion_demo` uses, so a first-time demo never lands in the wrong Autodesk account.