What

Two related fixes for users who install the wrong macOS architecture (reproduced manually on 2026-04-08, hit by two real users in one day):

1. Warn on Apple-Silicon-running-x64 at app startup with a blocking dialog and a one-click link to the latest arm64 dmg in the user's current update feed.
2. Include process.arch in the runtime extraction stamp so the cached nexu-runner.app and controller-sidecar are re-cloned when the user reinstalls a different arch of the same Nexu version.

Why

Both fixes were prompted by today's debugging session where two separate Apple Silicon users installed the x64 dmg by mistake:

• macOS launches the wrong-arch build silently under Rosetta 2 with no warning.
• The visible symptoms are 3-5x slower JS, 100% renderer CPU, and "Agent 启动中" never resolving — none of which look anything like an arch mismatch.
• Recovery is also broken: even after reinstalling the correct arm64 dmg, ~/.nexu/runtime/.nexu-runner-version still matches the old (x64) install, so the cached nexu-runner.app + controller-sidecar are reused, the running arm64 Electron tries to load the cached x64 native modules (e.g. @snazzah/davey), and openclaw fails on the very first require() with Cannot find native binding. The gateway never binds 18789, the controller can never connect, and the UI is stuck on "Agent 启动中" forever.

Both users wasted hours debugging before we worked out it was an arch mismatch.

How

1. Rosetta detection + warning dialog (apps/desktop/main/index.ts)

• isRunningUnderRosetta() reads sysctl.proc_translated (Apple's official Rosetta detection) with a 1s timeout. Returns false on any non-darwin platform, on darwin arm64, or on any failure.
• warnIfRunningUnderRosetta() is called as the first thing in app.whenReady(), before any heavy startup work, so users with the wrong dmg are not stuck waiting on a slow cold start. Skipped in dev and skippable via NEXU_SKIP_ARCH_WARNING=1.
• The dialog is localised (zh-CN / en) based on app.getLocale() and uses Electron's native dialog.showMessageBox() (no extra dependencies). Two buttons:
  • Download arm64 build: opens the resolved dmg URL in the system browser and exits the app.
  • Continue anyway: dismisses and proceeds with startup.
• resolveLatestArm64DownloadUrl() constructs the download link from the same update feed the auto-updater uses, so the link always points at the exact build auto-update would otherwise install:
  • If NEXU_UPDATE_FEED_URL is set (the canonical feed for this build), swap any trailing /x64 → /arm64.
  • Otherwise build from https://desktop-releases.nexu.io/{channel}/arm64, where channel comes from NEXU_DESKTOP_UPDATE_CHANNEL (defaults to stable).
  • Fetch latest-mac.yml from that base, parse the first url: …dmg entry (matching the dmg, not the auto-update zip), and return the absolute URL.
  • On any fetch failure (offline, parse error, 404), fall back to the latest-mac.yml URL itself — modern browsers display it as text and it still reliably points the user at the right channel.

2. Arch in runtime extraction stamp (apps/desktop/main/platforms/mac/launchd-paths.ts, apps/desktop/main/services/launchd-bootstrap.ts)

• buildRuntimeExtractionStamp() previously serialised only { appVersion, bundleVersion }. Both x64 and arm64 builds of the same nightly share those fields, so the cached runner stamp matched and the runner + controller-sidecar were never re-cloned across arch swaps.
• Adding arch: process.arch to the JSON forces a re-clone whenever the running Electron's arch differs from the cached one.
• Two duplicate copies of buildRuntimeExtractionStamp exist (one in platforms/mac/launchd-paths.ts, the live path used by index.ts; one in services/launchd-bootstrap.ts, dead code from a refactor). Both are updated to keep them consistent in case the dead copy gets reactivated.

Affected areas

• Desktop app (Electron shell)

Checklist

• pnpm typecheck — not run locally (worktree without node_modules); changes are type-stable: only adds a new helper function and a field to a JSON-stringified object.
• pnpm lint — not run locally for the same reason.
• pnpm test — N/A, no tests cover these specific paths today.
• pnpm generate-types — N/A.
• No credentials or tokens in code or logs.
• No any types introduced.

Notes for reviewers

• Manual verification: I will demo the dialog locally before merging. The cleanest way to verify on a real install:

  1. Build the x64 dmg of any nightly with this PR included.
  2. Install it on an Apple Silicon Mac.
  3. First launch should immediately show the warning dialog.
  4. Clicking Download arm64 should open the matching arm64 dmg URL from the same nightly channel and exit the app.

• Why not also include arch in the openclaw sidecar stamp? The openclaw sidecar uses ${size}:${mtimeMs} of the source archive as its stamp (in manifests.ts). Each arch ships its own archive with different size/mtime, so the stamp comparison naturally catches arch swaps without needing an explicit arch: field. The bug was specifically in the runner/controller-sidecar paths, which use appVersion + bundleVersion.

• Why use dialog.showMessageBox() over a React modal? The warning fires before any window or React tree exists, so a renderer-side modal would not be visible until the renderer process is spawned — by which point we have already done expensive setup work the dialog is supposed to short-circuit. The native dialog shows immediately, blocks main process startup, and requires zero extra dependencies.

• Why not "don't show again"? Intentionally omitted. Users who install the wrong arch will keep seeing this every launch until they fix it, which is the desired pressure. If we add a "do not show again" toggle, users will reflexively click it and silently keep paying the Rosetta tax.

Closes the action item from today's launch-prep debugging session.