Windows arm64 support#2901
Conversation
- Add runtime Windows ARM64 host detection via PROCESSOR_ARCHITECTURE / PROCESSOR_ARCHITEW6432 environment variables, matching the build-time logic already present in scripts/lib/build-target-arch.ts - Fix DesktopEnvironment.resolveDesktopRuntimeInfo to detect ARM64 hosts on Windows (was macOS-only before) - Fix ElectronApp to expose windowsProcessorArchitectures metadata - Make update warning UI platform-aware (Windows ARM64 vs Apple Silicon) - Add nodejs-arm64 path to knownWindowsCliDirs for ARM64 Node installs - Enable Windows ARM64 build matrix in release workflow - Enable Windows updater manifest merging in release pipeline - Add ARM64 Spectre MSVC component for ARM64 code signing - Add comprehensive test coverage for Windows ARM64 detection - Update all MakeDesktopEnvironmentInput consumers with new field
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
the
size:L
github-actions
Bot
added
the
vouch:unvouched
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7fffee6956
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (appArch === "arm64") return "arm64"; | ||
| for (const envValue of windowsProcessorArchitectures) { | ||
| const resolved = normalizeWindowsArch(envValue); | ||
| if (resolved !== undefined) return resolved; |
There was a problem hiding this comment.
When both Windows architecture hints are present and an x64/AMD64 value appears before ARM64 (as in the new PROCESSOR_ARCHITEW6432 test case with ["AMD64", "ARM64"]), this early return resolves the host as x64 and never inspects the later ARM64 hint. That leaves runtimeInfo.runningUnderArm64Translation false, so the ARM64 warning/updater path added in this commit is skipped for that Windows ARM64 case; prefer ARM64 if any hint contains it before falling back to x64.
Useful? React with 👍 / 👎.
| assert.deepEqual(environment.devRemoteT3ServerEntryPath, Option.some("/remote/server.mjs")); | ||
| assert.deepEqual(environment.configuredBackendPort, Option.some(4949)); | ||
| assert.deepEqual(environment.commitHashOverride, Option.some("0123456789abcdef")); | ||
| assert.deepEqual(environment.commitHashOverride, Option.some("0123456789abc")); |
There was a problem hiding this comment.
DesktopConfig.commitHashOverride is decoded through trimmedString, which trims whitespace but does not truncate the value, so the test input " 0123456789abcdef " still produces Option.some("0123456789abcdef"). Changing the expected value to 13 characters makes this existing DesktopEnvironment test fail independently of the Windows ARM64 changes.
Useful? React with 👍 / 👎.
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
ApprovabilityVerdict: Needs human review This PR introduces Windows ARM64 support as a new feature with changes across CI workflows, platform detection, and UI. Multiple high-severity unresolved review comments identify potential bugs in the ARM64 detection logic and update mechanism. A fork-specific scheduled workflow is also being added that may cause CI issues if merged. You can customize Macroscope's approvability policy. Learn more. |
- Fix resolveWindowsHostArch to prioritize ARM64 over x64 in processor arch hints, preventing incorrect detection when both hints are present - Fix truncated commit hash assertion (0123456789abc -> 0123456789abcdef) - Fix platform detection to handle Linux correctly instead of assuming non-Windows = macOS in SidebarUpdatePill and Sidebar - Change make_latest to false in windows-arm64-app.yml to avoid overwriting stable release badges on scheduled builds
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf0f57cfb5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const intelLabel = environment.platform === "darwin" ? "Intel" : "x64"; | ||
| yield* logUpdaterInfo( | ||
| "Apple Silicon host detected while running Intel build; updates will switch to arm64 packages", | ||
| `${hostLabel} host detected while running ${intelLabel} build; updates will switch to arm64 packages`, |
There was a problem hiding this comment.
When this branch is hit on Windows ARM64 while the app is still the x64 build, electron-updater will still download the x64 installer from the merged latest.yml: the locked NSIS updater calls findFile(..., "exe"), and that helper prefers file URLs containing process.arch, which is still x64 for the emulated process (source). Disabling differential download only changes how the selected file is fetched, so these users keep receiving x64 updates instead of switching to ARM64; the Windows ARM64 path needs an arch-aware feed/selection mechanism before advertising that updates switch packages.
Useful? React with 👍 / 👎.
| {desktopUpdateState?.hostArch === "arm64" && navigator.platform.startsWith("Win") | ||
| ? "x64 build on ARM64" | ||
| : "Intel build on Apple Silicon"} | ||
| </AlertTitle> |
There was a problem hiding this comment.
Sidebar alert title missing platform check for non-Mac
Low Severity
The AlertTitle in Sidebar.tsx uses a two-way check (Windows → "x64 build on ARM64", else → "Intel build on Apple Silicon"), but SidebarUpdatePill.tsx correctly uses a three-way check that also distinguishes Mac from other platforms. On a non-Windows, non-Mac platform (e.g., Linux ARM64), the Sidebar.tsx version will incorrectly display "Intel build on Apple Silicon" instead of "x64 build on ARM64". The SidebarUpdatePill.tsx already handles this correctly and the two components are inconsistent.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit a9d344d. Configure here.
- Set make_latest: true so GitHub /releases/latest API returns the fork release (was false, causing 404 and silent update check failures) - Rename arch-suffixed update manifests (latest-arm64.yml -> latest.yml) to match what electron-updater expects on ARM64 installs - Narrow release file glob to exclude builder-debug.yml artifacts
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a45cb48c45
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (input.platform === "win32") { | ||
| const hostArch = | ||
| resolveWindowsHostArch(input.processArch, input.windowsProcessorArchitectures) ?? appArch; | ||
| const runningUnderArm64Translation = hostArch === "arm64" && appArch === "x64"; |
There was a problem hiding this comment.
When an x64 Electron build is running on Windows on Arm, this branch ignores input.runningUnderArm64Translation and recomputes the state only from PROCESSOR_ARCHITE* env vars. Electron documents app.runningUnderARM64Translation as supported on Windows for prompting x64 users to download ARM64 builds, while Microsoft notes x64 apps under Arm emulation see emulated processor details unless they call the dedicated APIs, so a normal emulated process can report only AMD64 here. In that case hostArch stays x64 and all of the Windows ARM64 warning/update behavior is skipped; fold the Electron flag into the Windows host/translation resolution.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
There are 3 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit a45cb48. Configure here.
| hostArch, | ||
| appArch, | ||
| runningUnderArm64Translation: false, | ||
| runningUnderArm64Translation, |
There was a problem hiding this comment.
Windows ARM64 detection ignores working Electron API signal
High Severity
The win32 path in resolveDesktopRuntimeInfo ignores input.runningUnderArm64Translation (sourced from Electron's app.runningUnderARM64Translation, which works on Windows) and relies solely on windowsProcessorArchitectures from env vars. Per Microsoft docs, PROCESSOR_ARCHITECTURE for an x64 binary always returns "AMD64" regardless of host, and PROCESSOR_ARCHITEW6432 is only set for 32-bit WOW64 processes — not for x64-on-ARM64 (which uses Prism emulation). So for the primary use case (x64 Electron app on ARM64 Windows), the array will be ["AMD64"], resolveWindowsHostArch returns "x64", and ARM64 translation goes undetected.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit a45cb48. Configure here.
| release/*.exe | ||
| release/*.blockmap | ||
| release/latest*.yml | ||
| release/nightly*.yml |
There was a problem hiding this comment.
Fork-specific scheduled workflow committed to main repo
Medium Severity
This entire workflow is fork-specific infrastructure — it checks out a windows-arm64-support branch, adds pingdotgg/t3code.git as an "upstream" remote, merges from it, and publishes fork releases with make_latest: true. It also runs on a cron schedule every 6 hours. If merged into the main repo, this would trigger failed CI runs every 6 hours (the windows-arm64-support ref likely doesn't exist), and if the branch ever exists, it would create unwanted tags and releases.
Reviewed by Cursor Bugbot for commit a45cb48. Configure here.
1 participant
What Changed
Why
UI Changes
Checklist
Note
Medium Risk
Changes affect release artifacts and auto-update manifest merging; incorrect arch detection could mis-route updates or warnings on Windows ARM64.
Overview
Adds Windows ARM64 to the main release pipeline and wires desktop/runtime behavior so x64-on-ARM64 Windows is detected and surfaced like Rosetta on macOS.
CI / releases: The release matrix builds Windows
arm64NSIS onwindows-11-arm, installs ARM64 Spectre MSVC components when needed, suffixes per-arch updater YAML as*-win-{arch}.yml, and merges x64/arm64 manifests (keeping x64-only when arm64 is missing). A separate Windows ARM64 App workflow builds and publishes fork releases fromwindows-arm64-supportwith upstream sync.Desktop:
ElectronApppassesPROCESSOR_ARCHITECTURE/PROCESSOR_ARCHITEW6432intoDesktopEnvironment, which resolves Windows host vs app arch and setsrunningUnderArm64Translationfor x64 on an ARM64 host. Windows shell PATH hydration includes%LOCALAPPDATA%\Programs\nodejs-arm64. Updater logs and UI warnings use platform-specific copy (e.g. x64 build on ARM64 vs Apple Silicon / Intel).Reviewed by Cursor Bugbot for commit a45cb48. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Add Windows ARM64 support to the desktop app build and runtime detection
PROCESSOR_ARCHITECTUREandPROCESSOR_ARCHITEW6432env vars, settingrunningUnderArm64Translationwhen an x64 build runs on an ARM64 host.C:\...\nodejs-arm64to the default PATH in DesktopShellEnvironment.ts for Windows ARM64 Node.js installations.MakeDesktopEnvironmentInputnow requires awindowsProcessorArchitecturesfield; all callers must provide it (tests updated with[]as default).Macroscope summarized a45cb48.