### Summary

Omarchy's install paths name packages that only exist for `x86_64`, and nothing in
the tree checks the running architecture, so on aarch64 the **Install** menu offers
entries that can never succeed. Each one fails in a floating terminal that prints
`error: target not found: <pkg>` and closes, usually faster than it can be read.

### System details

- Omarchy `4.0.0.alpha` (from `/usr/share/omarchy/version`)
- Arch Linux ARM, `uname -m` = `aarch64`, kernel `7.2.0-2-aarch64-ARCH` (not Asahi)
- QEMU/UTM guest on an Apple Silicon host (`product_name` = `QEMU Virtual Machine`,
  `/proc/device-tree/compatible` empty)
- pacman repositories configured: `core`, `extra`, `alarm`, `aur`

### Mechanism

Three pieces combine:

1. **`bin/omarchy-pkg-add` is pacman-only.** It runs
   `sudo pacman -S --noconfirm --needed "$@"` and never touches the AUR
   (`bin/omarchy-pkg-aur-add` is the separate `yay` path). Any name that is not in a
   configured sync repository fails outright.
2. **`bin/omarchy-install-app` hides the failure.** It wraps `omarchy-pkg-add` in
   `omarchy-launch-floating-terminal-with-presentation`, so the pacman error appears
   in a transient floating window and disappears. The same is true of every
   `omarchy-launch-floating-terminal-with-presentation omarchy-install-*` menu action.
3. **Nothing anywhere checks the architecture.** In 4.0.0.alpha,
   `grep -rIn 'x86_64\|aarch64\|uname -m\|arm64\|HOSTTYPE\|MACHTYPE' bin default install config etc shell`
   returns no hits. The `omarchy-hw-*` predicate family covers CPU vendor, GPU,
   chassis and peripherals, but has no architecture predicate, so no menu entry can
   currently gate on one.

The `[omarchy]` repository compounds this. `default/pacman/pacman-stable.conf` points
it at `https://pkgs.omarchy.org/stable/$arch`, and that tree is x86_64-only:

```
$ curl -o /dev/null -w '%{http_code}\n' https://pkgs.omarchy.org/stable/x86_64/omarchy.db
200
$ curl -o /dev/null -w '%{http_code}\n' https://pkgs.omarchy.org/stable/aarch64/omarchy.db
404
```

Most of the AUR-derived apps in the Install menu resolve out of `[omarchy]` on x86_64
(`1password`, `cursor-bin`, `dropbox`, `lmstudio-bin`, `once-bin`,
`openai-codex-desktop`, `spotify`, `sublime-text-4`, `symfony-cli`,
`visual-studio-code-bin`, `voxtype-bin`, … — 202 packages in the x86_64 database), so
on aarch64 they have no source at all through the pacman-only path.

### Reachable entries whose package cannot exist on aarch64

Every row below is offered from **Menu → Install** with no hardware or architecture
gate. Their only `disabled` predicate is `omarchy-pkg-present <pkg>`, which is false on
a machine where the package could never have installed — so the entry renders enabled.
`arch=` values are from the authoritative PKGBUILD at
`https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=<pkg>`; "not in any repo" was
checked with `pacman -Si` against `core`/`extra`/`alarm`/`aur`.

| Menu path | Command it runs | Package | Why it fails on aarch64 |
| --- | --- | --- | --- |
| Install → AI → Ollama | `omarchy-install-app Ollama ollama` | `ollama` | AUR `arch=('x86_64')`; not in any aarch64 repo. **Reproduced on this host** — `/var/log/pacman.log` `[2026-08-27T20:41:18+0300] [PACMAN] Running 'pacman -S --noconfirm --needed ollama'`, `error: target not found: ollama`. Ollama does publish `ollama-linux-arm64.tar.zst` upstream, so this is a packaging assumption rather than a support gap. |
| Install → AI → LM Studio | `omarchy-install-app 'LM Studio' lmstudio-bin` | `lmstudio-bin` | AUR `arch=('x86_64')` |
| Install → Editor → Cursor | `omarchy-install-and-launch Cursor cursor-bin cursor` | `cursor-bin` | AUR `arch=('x86_64')` |
| Install → Editor → Zed | `omarchy-install-editor-zed` → `omarchy-pkg-add zed omazed` | `zed`, `omazed` | no aarch64 `zed` in `extra`/`alarm`; AUR `zed` is `arch=('x86_64')`. `omazed` is `arch=('any')` but AUR-only, which the pacman-only path cannot reach. |
| Install → Service → 1Password | `omarchy-install-service-1password` → `omarchy-pkg-add 1password 1password-cli` | `1password` | AUR `arch=('x86_64')` (`1password-cli` does list `aarch64`) |
| Install → Service → Spotify | `omarchy-install-service-spotify` → `omarchy-pkg-add spotify` | `spotify` | AUR `arch=('x86_64')` |
| Install → Service → Dropbox | `omarchy-install-service-dropbox` → `omarchy-pkg-add dropbox …` | `dropbox`, `nautilus-dropbox` | AUR `arch=("x86_64")` for both |
| Install → Development → PHP → Symfony | `omarchy-install-dev-env symfony` → `omarchy-pkg-add symfony-cli` | `symfony-cli` | AUR `arch=('x86_64')` |
| Install → Browser → Edge | `omarchy-install-browser edge` → `omarchy-pkg-aur-add microsoft-edge-stable-bin` | `microsoft-edge-stable-bin` | AUR `arch=('x86_64')` — fails in `yay` rather than pacman, but is equally unreachable |

### Reachable entries whose package *could* work on aarch64

These are a milder case of the same mechanism: the upstream PKGBUILD does list
`aarch64`, but the package lives only in the AUR and in `[omarchy]`, and
`omarchy-pkg-add` is pacman-only while `pkgs.omarchy.org` has no aarch64 tree. So they
fail too, even though nothing about them is architecture-bound.

| Menu path | Package | Upstream `arch=` |
| --- | --- | --- |
| Install → AI → ChatGPT Desktop | `openai-codex-desktop` | `('x86_64' 'aarch64')` |
| Install → Editor → VSCode | `visual-studio-code-bin` | `('x86_64' 'aarch64' 'armv7h')` |
| Install → Editor → Sublime Text | `sublime-text-4` | `('x86_64' 'aarch64')` |
| Install → Service → ONCE | `once-bin` | `('x86_64' 'aarch64')` |
| Install → Service → NordVPN | `nordvpn-bin` | `('x86_64' 'i686' 'armv7h' 'aarch64' 'armeabi')` |

### What is *not* affected

For completeness, I traced every x86-only package name in `bin/`, `install/` and
`default/` and confirmed the following are correctly gated behind an `omarchy-hw-*`
predicate or a hardware-detection guard, so they never run on ARM and are **not** part
of this report: `intel-lpmd`, `thermald`, `intel-media-driver`, `libvpl`, `vpl-gpu-rt`,
`libva-intel-driver`, `intel-ipu7-camera`, `linux-ptl`, `linux-ptl-headers`,
`sof-firmware`, `asusctl`, `supergfxctl` (`when: omarchy-hw-hybrid-gpu`),
`broadcom-wl`, `macbook12-spi-driver-dkms`, `dell-xps-touchpad-haptics`,
`dell-xps13-sidecar-amps`, `qmk-hid`, `tuxedo-drivers-nocompatcheck-dkms`,
`yt6801-dkms`, `linux-firmware-marvell`, the `nvidia.sh` kernel/driver set, and the
`ollama-cuda` / `ollama-rocm` branches of `install.ai.ollama` (guarded by
`omarchy-cmd-present nvidia-smi` / `rocminfo`).

I also deliberately left the gaming entries (`install.gaming.steam`,
`.lutris`, `.heroic`) out of the tables. They are ungated and they do fail
(`steam` is multilib-only, `wine-staging` is `arch=('x86_64' 'i686')`,
`heroic-games-launcher-bin` is `arch=('x86_64')`), but the whole stack is x86-bound by
nature and arguably belongs to a different discussion.

One adjacent case I could not classify cleanly and am flagging as **unverified**:
`install.gaming.xbox-controllers` runs `omarchy-pkg-add linux-headers xpadneo-dkms`.
`xpadneo-dkms` is `arch=(any)`, but `linux-headers` does not exist under that name on
ALARM (`linux-aarch64-headers`) or Asahi (`linux-asahi-headers`). That is a kernel
package-naming assumption rather than an architecture one, and several
hardware-gated scripts share it.

### How this differs from the existing reports

- **#8530** and **PR #8316** address the Voxtype install path specifically, and #8316
  is the right shape for it — a source-build fallback gated on the new
  `omarchy-hw-x86-64-v3` predicate. But that fix is local to
  `bin/omarchy-voxtype-install`; the same class of failure remains in every other
  ungated Install entry above.
- **#7883** and **PR #8149** cover the related AVX2/SSE4.2 baseline problem *within*
  x86_64.
- **PR #8039** covers the aarch64 *install-time* path (`mkinitcpio` `thunderbolt`,
  `[multilib]` in `pacman.conf`, `mise-work`) and notes the `pkgs.omarchy.org` aarch64
  gap as out of scope. This issue is about the post-install, user-facing menu.
- **#87** (closed) and **#803** (closed) are much older and predate the current menu.

I did not find an open report covering the general case.

### Suggested direction

Offered as options, not a prescription:

1. **A preflight in `omarchy-pkg-add`.** Before shelling out to pacman, check that each
   name resolves for the running architecture and, when it does not, fail with a
   message that says so — instead of letting `error: target not found` scroll past in a
   window that closes. This would cover every call site at once, including the ones
   reached from scripts rather than the menu.
2. **`disabled` predicates on the menu entries** whose package cannot exist on the
   running architecture, so the entry is greyed out rather than offered. PR #8316's
   `bin/omarchy-hw-x86-64-v3` already returns false for any non-`x86_64` machine
   (`[[ $machine == "x86_64" ]] || exit 1` before the flag checks), so it could serve as
   that gate directly, or a narrower `omarchy-hw-x86-64` predicate could be split out of
   it.
3. **Publishing an aarch64 tree on `pkgs.omarchy.org`** would independently fix the
   second table, since those packages already build for ARM.

(1) and (2) are complementary: (2) keeps the dead entries out of the user's way, (1)
catches the script-level call sites and gives a readable error when a package is missing
for any other reason.

Happy to open a PR for whichever of these you'd prefer — the `omarchy-hw-x86-64`
predicate plus `disabled` gates is the smallest change, and the `omarchy-pkg-add`
preflight is the one that covers the most ground.