[BUG] Homebrew operations on Apple Silicon macOS are launched under Rosetta/translated mode, causing every /opt/homebrew install/upgrade to fail

[PowerUserZ]

Please confirm these before moving forward

• I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.
• I have checked the FAQ section for solutions.
• This issue is about a bug (if it is not, please use the correct template).

UniGetUI Version

2026.1.6

Windows version, edition, and architecture

macOS 26.5, Apple Silicon (arm64)

Describe your issue

On Apple Silicon macOS with Homebrew installed in the standard ARM prefix (/opt/homebrew), UniGetUI appears to launch Homebrew operations from a translated/Rosetta process context.

As a result, every Homebrew install/upgrade operation fails with Homebrew's standard Rosetta protection error:

Error: Cannot install under Rosetta 2 in ARM default prefix (/opt/homebrew)!
To rerun under ARM use:
    arch -arm64 brew install ...
To install under x86_64, install Homebrew into /usr/local.

This is not formula-specific. I reproduced it with harfbuzz, and the same behavior also occurred for libpng, simdjson, libngtcp2, and libnghttp2.

The important part is that the exact same Homebrew operations succeed immediately outside UniGetUI when forced to ARM64, which strongly suggests the issue is in how UniGetUI launches brew, not in Homebrew or the individual formulas.

Steps to reproduce the issue

1. Use an Apple Silicon Mac.
2. Install Homebrew in the normal ARM prefix: /opt/homebrew.
3. Install UniGetUI 2026.1.6.
4. Open UniGetUI and update any Homebrew package, for example harfbuzz.
5. Observe that UniGetUI executes:

FileName: "/opt/homebrew/bin/brew"
Arguments: "upgrade harfbuzz"

6. Observe that the operation fails with:

Error: Cannot install under Rosetta 2 in ARM default prefix (/opt/homebrew)!

What I expected to happen

UniGetUI should launch Homebrew operations in native ARM64 mode on Apple Silicon macOS, so that brew upgrade ... works normally with /opt/homebrew.

What actually happens

UniGetUI launches Homebrew in a translated/Rosetta context, so Homebrew detects the wrong execution architecture and aborts.

External verification

The same upgrade that fails inside UniGetUI succeeds from Terminal when explicitly re-run under ARM64:

arch -arm64 /opt/homebrew/bin/brew upgrade harfbuzz

I also verified that a Rosetta-style invocation succeeds if it is re-executed under ARM64 first:

arch -x86_64 /opt/homebrew/bin/brew upgrade --formula --dry-run harfbuzz

This originally failed with the Rosetta error, but succeeds if the process is re-launched under ARM64 before Homebrew continues.

UniGetUI Log

Example from UniGetUI operation history:

Package update operation for Package=harfbuzz with Manager=Homebrew
Executing process with StartInfo:
 - FileName: "/opt/homebrew/bin/brew"
 - Arguments: "upgrade harfbuzz"
==> Upgrading 1 outdated package:
harfbuzz 14.1.0 -> 14.2.0
Error: Cannot install under Rosetta 2 in ARM default prefix (/opt/homebrew)!
To rerun under ARM use:
arch -arm64 brew install ...
To install under x86_64, install Homebrew into /usr/local.

Additional technical notes

• The packaged UniGetUI.Avalonia binary is arm64.
• brew config outside UniGetUI reports Rosetta 2: false.
• The failure only appears when the operation is launched through UniGetUI.
• This suggests a child process, shell, helper, or launcher in the UniGetUI execution chain is ending up translated, even though the app binary itself is ARM-native.

Suggested fix

On Apple Silicon macOS, UniGetUI should ensure that Homebrew commands targeting /opt/homebrew/bin/brew are launched natively under ARM64.

Possible implementation approaches:

1. Detect Apple Silicon + /opt/homebrew/bin/brew, then execute via:

/usr/bin/arch -arm64 /opt/homebrew/bin/brew <args>

2. Alternatively, detect translated execution before spawning Homebrew and re-exec the helper/process under ARM64 first.

3. If UniGetUI intentionally supports both Intel and ARM Homebrew installations, it should select:

   • /opt/homebrew -> ARM64 execution
   • /usr/local -> x86_64 execution

Why this matters

At the moment, Homebrew support on Apple Silicon macOS looks broken from inside UniGetUI because every package update can fail with the same Rosetta error, even though Homebrew itself is healthy and the same commands work fine from Terminal.

Search notes

I searched the UniGetUI issue tracker for related reports and did not find a matching bug:

• is:issue Rosetta
• is:issue Homebrew macOS
• is:issue "Cannot install under Rosetta 2"
• is:issue brew translated

[GabrielDuf]

Thanks for the detailed report, this does look like an issue on our side.

UniGetUI should not be invoking Homebrew under Rosetta on Apple Silicon, especially for /opt/homebrew. We’ll review how the brew process is being launched.

Could you quickly confirm:

How UniGetUI was installed (pkg, dmg, other)?
Is “Open using Rosetta” disabled in Finder → Get Info?
Does this affect all Homebrew actions or only upgrades?

We’ll take a closer look at the execution path on macOS ARM.

[PowerUserZ]

Thanks for the quick reply.

Here are the details from my side:

1. Installation method
   I installed UniGetUI from the GitHub release for Apple Silicon macOS:
   UniGetUI.macos-arm64.dmg
   Version tested: 2026.1.6

2. “Open using Rosetta”
   No, it is not enabled.
   The packaged UniGetUI.Avalonia binary on disk is arm64, and outside UniGetUI brew config reports Rosetta 2: false.

3. Scope of the issue
   In my testing, this affected all Homebrew upgrade/update actions I tried from UniGetUI, not just a single package.
   I reproduced it with:

• harfbuzz
• libpng
• simdjson
• libngtcp2
• libnghttp2

I have not yet separately tested fresh install/remove actions from the UI, so the confirmed repro case is upgrade/update operations.

Additional note:
The exact same Homebrew commands succeed immediately from Terminal when run under ARM64, for example:

arch -arm64 /opt/homebrew/bin/brew upgrade harfbuzz

So from what I can see, Homebrew itself is healthy and the problem appears to be in the process
launch/execution path used by UniGetUI on macOS ARM.

[GabrielDuf]

I made a test build with a tentative fix, if you want to give it a shot: https://github.com/Devolutions/UniGetUI/actions/runs/24787086403

[GabrielDuf]

The issue has been fixed in version 2026.1.7.