OpenHands 1.23.0 adopts universal macOS installer, fixes Intel runtime incompatibility

OpenHands released Agent Canvas 1.23.0 on September 23, switching its macOS desktop installer to a universal DMG that supports both Intel and Apple Silicon. The release bundles Node.js and uv for both architectures and selects the appropriate versions at startup, addressing an issue that left Intel Macs unable to run the app after receiving arm64 executables. [Release notes](https://docs.openhands.dev/openhands/usage/agent-canvas/release-notes/v1.23.0), [Fix PR](https://github.com/OpenHands/OpenHands/pull/17225)

The change affects the coding agent’s local startup sequence. Agent Canvas manages conversations, files, terminals, and automation, while backend services execute the agent and its tools; the desktop app automatically starts a local backend. Even if the application window opens, an architecture mismatch in the bundled runtimes can prevent subsequent services from becoming ready. For teams using a mix of older and newer Macs, a unified installer also reduces differences that complicate distribution and troubleshooting. [Architecture overview](https://docs.openhands.dev/openhands/usage/agent-canvas/overview), [Desktop installation documentation](https://docs.openhands.dev/openhands/usage/agent-canvas/setup)

The fix also adjusts downloads, packaging, and runtime paths. The build process prepares four architecture-specific directories for Node.js and uv. At startup, the resolver uses `process.arch` to prioritize the matching directory, falling back to the legacy flat directory layout only if it cannot find one. The packaging configuration also accounts for limitations in how `@electron/universal` merges Mach-O files, avoiding a situation where only the main Electron executable is merged while incompatible helper executables remain. [Implementation details](https://github.com/OpenHands/OpenHands/pull/17225)

The public discussion includes startup logs from an Intel Mac, showing that the app loaded the x64 runtimes and received a response from the backend. Before merging, the team also added native build checks for Intel and arm64, along with a complete universal DMG build that can be triggered manually. This evidence covers packaging and startup paths; deployment teams should still validate complete agent tasks, external tools, and model connections on both hardware architectures using their actual configurations. [Review and validation records](https://github.com/OpenHands/OpenHands/pull/17225)

The execution environment also needs to be checked during migration. The official documentation lists local backends, containers, and remote virtual machines as distinct deployment options, and the files visible to an agent depend on the connected workspace. Enterprises that previously used container isolation should continue selecting the same backend and mount scope when switching to the desktop interface, maintaining consistent tool environments and permission boundaries. This check is particularly relevant to workflows that read and write source code, run tests, and use credentials. [Backends and workspaces](https://docs.openhands.dev/openhands/usage/agent-canvas/overview)

The desktop app is still officially classified as an early preview, and the macOS app uses ad hoc signing, so the operating system may block it from opening. After upgrading, users can access startup logs through “Show details” to first confirm that the runtimes and backend are ready, then test reading and writing project files and making tool calls. Models can run locally or be accessed through remote APIs, so successful installation and model inference performance need to be assessed separately. [Installation and troubleshooting](https://docs.openhands.dev/openhands/usage/agent-canvas/setup)