Add one workspace sign-in to Agent Native Desktop

[3mdistal]

Problem

Agent Native Desktop opens first-party apps in isolated browser sessions. That isolation currently also makes people sign in to each app separately, even though they are using one Desktop workspace. The result is repetitive setup and inconsistent account and sign-out behavior.

This must improve without silently joining standalone browsers, custom apps, local development, or Builder credentials to a Desktop-wide session.

Approach

Use Dispatch as the Desktop workspace identity authority. One browser ceremony establishes the workspace identity; each explicitly trusted Agent Native app then exchanges a short-lived signed handoff for its own normal app session. Desktop keeps those sessions isolated and never exposes credentials to renderer code.

Trust is intentionally narrow: exact canonical first-party HTTPS origins only. Mail is the first production canary, not evidence that the whole app fleet is enabled.

What changed

• Add the Core identity handoff protocol with one-time state and nonce validation, exact callback validation, JIT local-account linking, and ordinary app-local session completion.
• Add the Desktop identity broker with a dedicated Dispatch partition, isolated per-app partitions, concurrency control, Settings controls, and fail-closed origin/cookie boundaries.
• Preserve each app's original /logout and /logout-all server behavior while Desktop observes completion, carries authenticated revocation through cleanup, monotonically upgrades to logout-all, drains all cleanup targets, and reports partial failure truthfully.
• Enumerate immutable canonical packaged apps for workspace cleanup independently of whether an app is disabled, missing, edited, or switched to Dev; custom and localhost origins remain excluded.
• Consolidate Dispatch identity routes under its primary authentication initializer.
• Document the workspace identity model in framework authentication guidance and localized docs.
• Add a temporary branch-scoped macOS canary workflow. The stable Desktop release workflow is unchanged.
• Disable the updater only for the exact -desktop-sso-canary.N version family so acceptance cannot silently replace the candidate with a stable release. Stable and unrelated prerelease behavior is unchanged.

Safety and operations

• .github/workflows/desktop-release.yml and the shared stable update feed are unchanged.
• .github/workflows/desktop-canary.yml runs only for codex/desktop-workspace-sso; it creates no tag, release, updater publication, Windows build, or Linux build.
• The canary build has no update-feed, check, download, install, listener, focus, ready-callback, or timer capability; its menu and Settings controls report that auto-update is unavailable.
• No migration, backfill, or destructive data operation is involved.
• Desktop accepts only exact canonical origins and allow-listed session cookies. Builder authentication remains outside this system.
• Rollout is separate from merge and uses pinned immutable Netlify deploys, locked auto-publishing, a short test window, and immediate rollback.

Current exact-head evidence

Evidence on 0ab3d3bfff85b4f45b0a6da0ac7d319c78faeb2d:

• Updater policy and integration suite: 10 tests passed.
• Desktop identity, preload, and updater focused suite: 27 tests passed.
• Desktop TypeScript and formatting/diff checks passed.
• Exact-head CI run 30044521847 completed successfully, including all 220 Desktop tests and Fast Tests. The prior A2A deadline failure was fixed independently on current main; the branch's two bookkeeping commits cancel exactly, leaving the source tree identical to reviewed head d2a3919.
• Independent exact-head review found no remaining actionable issue and verified stable updater behavior is preserved.
• Signed canary run 30044519146 completed successfully.
• Artifact desktop-sso-canary-0ab3d3bfff85b4f45b0a6da0ac7d319c78faeb2d identifies version 0.1.150-desktop-sso-canary.8 and bundle ID com.agentnative.desktop; all four SHA-256 checksums recomputed exactly.
• The extracted arm64 app passed strict/deep code-sign verification, stapled-notarization validation, Gatekeeper assessment, bundle/version inspection, and architecture inspection. It is signed by Developer ID Application: Builder.io, Inc (W3PMF2T3MW).
• Native acceptance confirmed the exact .8 canary version, disabled updater controls, a 100-second focused dwell, one restart, and no canary-attributed feed request, update offer, download, or install.
• Current-head Mail deploy 6a628128c2584d0009701a9e and Dispatch deploy 6a628128cf5ee90008f8741e are pinned to the exact commit and still queued in Netlify because the team is using all 3/3 concurrent build slots. Neither has been published.

Prior controlled production canary

The prior-head ceremony proved canonical Mail-to-Dispatch routing, callback/state construction, hostile-callback rejection, and safe reverse-order rollback. The exact signed Desktop app reached production Dispatch, but normal Chrome had no authenticated Dispatch identity, so authenticated completion could not run.

Production remains restored to the prior baseline; auto-publishing is on for both Mail and Dispatch. No current-head deploy has been promoted.

Remaining acceptance gate

Do not merge on the basis of the partial canary. A fresh short ceremony still needs:

• a safe authenticated Dispatch test identity in normal Chrome;
• completed exact-head Mail and Dispatch candidates;
• same-account Mail completion and ordinary Mail data;
• restart, cancellation, concurrent opens, sign-out, logout-all, and account switch;
• standalone-browser locality;
• replay/expiry, hostile origin, malformed cookie, and partition/log fail-closed cases;
• disabled/Dev-switched canonical production-session cleanup.

The updater acceptance gate is now satisfied. A separate pre-existing Desktop quit-lifecycle guard required forced cleanup during tester disposal; available evidence does not attribute that behavior to this SSO or updater change.

Review focus

• Are canonical-origin, nonce, cookie, partition, and renderer boundaries narrow enough to prevent cross-app leakage or replay?
• Does workspace sign-out preserve original server revocation semantics and clear every canonical packaged production session without touching custom/local sessions?
• Does the temporary workflow remain isolated from stable Desktop releases and updater feeds?

[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.

[3mdistal]

Land audit — no-go packet

Passed: Exact-head required CI is green; the signed/notarized macOS artifact is bound to 8d33ffffe9e8b0b3acc78e725736a96f97dae7e5; independent whole-diff security review found no remaining actionable findings; the short canonical-origin canary proved Mail → Dispatch routing, exact callback/state construction, hostile-callback rejection, and safe rollback. The PR is approved, mergeable, and has no unresolved review threads.

Missing acceptance evidence: The canary browser had no authenticated Dispatch identity, so it did not prove same-account Mail session completion and correct existing data, restart persistence, workspace sign-out/logout-all, account switch, cancellation/concurrency, standalone-browser locality, custom/local exclusions, or the frozen hostile/replay/cookie/partition matrix. The canary also exposed an unexpected 0.1.161 updater prompt; it was declined, so updater behavior needs an explicit safe canary policy before rerun.

Feature flags: No generic feature flag was shaped. The risk strategy is system-ready with production validation before merge. The exact-head candidates were rolled back; current canonical Mail and Dispatch identity routes are back at the disabled baseline (401), the stable Desktop release is unchanged, and no Core package or branch code is integrated.

Repository governance: satisfied

Independent technical review: evidenced

Acceptance story: not satisfied

Merge permitted: no

Enablement permitted: no

May call shipped: no

Task may close: no

Readiness: blocked

Exact unblock: provision or use a safe authenticated Dispatch test identity, suppress or explicitly control updater replacement of the branch canary, rerun the short locked canonical-origin canary on an exact signed artifact, and pass the complete frozen installed-app acceptance matrix. Alice has also explicitly instructed that this pass must not merge.

[3mdistal]

Work update — exact-head canary ready, production window not opened

Current PR head: 0ab3d3bfff85b4f45b0a6da0ac7d319c78faeb2d.

Verified:

• required CI run 30044521847 is green, including Fast Tests;
• signed/notarized canary run 30044519146 is green;
• artifact desktop-sso-canary-0ab3d3bfff85b4f45b0a6da0ac7d319c78faeb2d reports 0.1.150-desktop-sso-canary.8, com.agentnative.desktop, and exact-head provenance;
• all four artifact checksums recomputed exactly;
• extracted arm64 app passed strict/deep codesign, stapled notarization, Gatekeeper, bundle/version, signer, and architecture verification;
• native updater acceptance passed: exact version, disabled update UI, 100-second dwell, restart, and no canary-attributed offer/request/download/install;
• the source tree is identical to reviewed head d2a3919; the temporary A2A bookkeeping commit and its removal cancel exactly, while current main supplies the canonical A2A test stabilization in the merge result.

Prepared exact-head Netlify candidates:

• Mail: 6a628128c2584d0009701a9e
• Dispatch: 6a628128cf5ee90008f8741e

Both are still new/queued because the Builder.io team is using all 3/3 concurrent Netlify build slots. Neither candidate has been published. Mail and Dispatch production remain untouched and auto-publishing remains on.

Authenticated acceptance is still blocked because normal Chrome is logged out of https://dispatch.agent-native.com. No test credentials were created or transmitted.

The production window must remain closed until both candidates are ready and a safe Dispatch session is available. Then capture the current production deploy IDs, lock auto-publishing, promote Dispatch then Mail, run the frozen authenticated matrix, restore production in reverse order, unlock, and verify rollback. Do not merge before that acceptance result.

Separate observation: native Quit again stalled during disposable canary cleanup. Evidence points to the pre-existing Desktop quit-lifecycle guard, not this SSO/updater change; restart and updater acceptance both passed.