Use one workspace sign-in across Agent Native Desktop apps

[3mdistal]

Problem

Agent Native Desktop currently treats every app as a separate sign-in boundary. A person can authenticate in Mail and then still be asked to authenticate again in Clips, Calendar, or another first-party app. That makes the desktop workspace feel like a collection of unrelated websites instead of one product.

Approach

Use Dispatch as the workspace identity authority while preserving a separate, correctly scoped session inside each app. Desktop opens one contained sign-in ceremony, accepts only a short-lived signed exchange, and lets the destination app establish its own local session. Later first-party apps can repeat that exchange silently without copying provider credentials or sharing raw cookies across origins.

The ordinary app sign-in remains the front door: signing in from Mail, for example, establishes workspace identity and returns to Mail. Standalone browser use, self-hosted deployments, custom apps, and provider-consent boundaries remain separate.

What changed

• Added the Core identity-authority exchange and credential-gated Google routes used by eligible apps.
• Added the Desktop broker, navigation handling, session transfer, sign-out cleanup, and isolated acceptance profile.
• Made hosted Dispatch show Google-only sign-in only at the exact canonical production origin and production deploy context, so previews do not present a route they cannot serve.
• Added a branch-only signed and notarized macOS Canary workflow. It does not modify the stable release workflow, updater feed, tags, or releases.
• Documented the cross-app authentication contract in the framework skill and localized docs.

Safety and operations

• Provider credentials stay in Dispatch/Core; Desktop never receives them.
• Session transfer uses an allowlisted, nonce-bound, one-time exchange rather than broad cookie copying.
• The signed Canary uses a separate app name and profile with updating disabled; the stable Desktop profile is outside the test boundary.
• Production credentials remain production-scoped. Netlify Deploy Previews are provenance surfaces only and must not be promoted as production candidates.
• The branch is reconciled with main@8385d4de38dc017c9915216228a31ca3cde4058a. Production-context Dispatch and Mail outputs are prebuilt and hashed so the supervised canonical window performs no build work.
• The supervised production acceptance test has not run. It remains a merge blocker, not a post-merge follow-up.

Verification

Current exact head: af0c143c71e29ff594f5599fc171d14d2f3b2b6e.

• CI run 30836808339 passed all 23 jobs at the exact head, including build, typecheck, lint/format, security guards, Core integration tests, SSR smoke, and all fast-test lanes.
• Local exact-head checks passed 246 Desktop tests, 46 Dispatch tests, seven Netlify build-ignore tests, the Core build, and the credential-boundary guards.
• Desktop SSO Canary run 30836813392 completed signed build, notarization, candidate provenance/trust verification, and artifact upload at the exact head. Artifact: desktop-sso-canary-af0c143c71e29ff594f5599fc171d14d2f3b2b6e; digest: sha256:5bd93649267e56c9c23c5f7de483309ba13663745a129202f98ad728bab77f5c.
• Dispatch preview 6a70cf6e615f3500084baf44 and Mail preview 6a70cf6f055088000861d014 are ready, unpublished, and bound to the exact head. Their production-credential routes remain absent in preview context as intended.
• Exact-head production-context build manifests are 10a9f3c46460444813c7b50bc0d7e0bed70d4b574134ce1f21e03d2bb9d294eb for Dispatch and 6101a82fdc5d4c5523701d85fdaa64851b4bfd9bbe8ea0f6b9974d568fc6c921 for Mail. Output credential-pattern scans were clean.
• Independent technical review found no actionable code issue.
• End-to-end production acceptance remains pending.

Review focus

• Does the one-time exchange stay narrowly scoped enough that one app cannot claim another app's session?
• Are navigation completion and cookie transfer committed only after the destination response actually succeeds?
• Do sign-out and quit cleanup preserve existing per-app logout semantics without touching the stable profile?
• Does the hosted Dispatch gate fail closed for every non-production or ambiguous origin/context?
• Is the branch-only Canary completely isolated from the stable updater and release workflow?

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes and found 1 potential issue 🔴

Review Details

Incremental Code Review Summary

The latest revision addresses all four previously reported issues: automatic sign-in is suppressed after workspace sign-out, ceremony generations invalidate queued and in-flight work, active cookie-copy operations are drained before clearing sessions, the canary now builds branding/native/extension resources, and Settings starts sign-in from an opted-in canonical target rather than Dispatch itself. I verified those fixes in the current source and resolved the four stale review threads.

Risk: High, because this remains authentication/session lifecycle code and release packaging. The updated broker now has substantially safer ordering and regression coverage, and the Dispatch primary-auth public-path consolidation remains sound.

New Finding

• 🔴 HIGH — The Desktop web-request interceptor cancels both ordinary logout and logout-all. This prevents the server-side all-session revocation from running, so a user selecting “sign out everywhere” in a canonical app can remain authenticated in other browsers/devices. Only ordinary local logout should be intercepted, or the revocation must be performed before local cleanup.

🧪 Browser testing: Blocked — the dev server was healthy, but Chrome DevTools MCP remained unreachable across executor retries; the Electron-only flows are not browser-served.

[steve8708]

@3mdistal should we merge this or drop it?

[3mdistal]

@3mdistal should we merge this or drop it?

@steve8708 testing it now. i got behind on other stuff, but finally coming back. it needed a human-driven test, and i hadn't had time to run it 'til now.

[3mdistal]

Canary .21 acceptance failed; production restored (no merge).

Exact Desktop artifact fdc6da02756f148aeff957b1b3358515cd0d6145 passed CI and signed/notarized packaging. The short locked canonical-origin window used production-context hosted candidates Mail 6a6dff6714b3bbe478cdccb9 and Dispatch 6a6dfc950e84fea87e565474.

Independent native results:

• H1 failed: the visible Settings control did not open.
• H2 passed: ordinary Mail sign-in opened the contained Dispatch ceremony with app=mail; Dispatch home was not shown.
• H3 reached the normal Google front door and Alice completed Google privately.
• H4 failed: completion returned to canonical Mail, but Mail remained on the loading shell instead of its existing-account data.
• H5 failed: canonical Dispatch still presented its own sign-in instead of silently resolving the workspace account.
• H6 failed: quit/relaunch reproduced Mail loading and Dispatch sign-in; no updater activity.
• H7 was inconclusive; H8 was blocked by Settings; H9-H10 did not run.

The credential-safe Desktop log contains the sanitized completion diagnostic [desktop-identity] target session transfer failed { appId: 'mail' }; no cookie, credential, token, state, or raw auth URL was logged. The bounded wait therefore still did not observe the allowlisted Mail session cookie.

Rollback completed immediately in reverse order to current main 9258da46f4b0291860913b1ec05743b6330a92e2: Mail 6a6f49a689f67900088bb2ea, Dispatch 6a6f49a6474bd80008d64fff. Both sites are unlocked with auto-publishing restored; Mail callback and Dispatch authorize are back to baseline 401; Mail root is normal 302; Canary/helpers/updaters are absent; stable Desktop profile mtime remains unchanged. PR remains open and intentionally unmerged.