---
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
# BEST - one server-side call does the whole chain, beats the ~2-min clock:
adom-desktop fusion_signin '{"auto":true,"profile":"chrome:you@work.com"}'
adom-desktop fusion_signin '{"profile":"chrome:you@work.com"}'   # staged/manual: fix + REMEMBER profile
adom-desktop fusion_signin '{}'                                  # staged: probe/remember/ask
```

### `auto:true` - the reliable path (do this)

The manual staged loop below needs THREE separate remote round-trips (click Sign In, capture, reopen)
and each one races Fusion's ~2-minute request expiry - on a slow or flaky relay you lose that race and
the callback shows "Sign-in request expired". `auto:true` collapses the whole chain into ONE
server-side call that runs **on the box**: it clicks Fusion's Sign In, polls the browser History
on-box (up to `waitSec`, default 32) for the fresh authorize URL, then re-opens it in the target
profile - so only ONE remote hop happens and everything else is local and fast, fitting inside the
2-min window. Pass the profile too (`{"auto":true,"profile":"chrome:you@work.com"}`) so it does not
have to stop and ask. Prefer this; use the staged calls below only to debug or when auto reports it
could not click/capture.

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.
