## What happens

`omarchy-install-1password` installs 1Password on aarch64 from the official tarball, but it hand-rolls the vendor's post-install instead of running the `after-install.sh` that ships inside that tarball. Two things follow from that, and the first one is the serious one.

### 1. The version is pinned forever, so updates never arrive

The script hardcodes `VERSION="8.12.0"`, and its "already installed" guard is existence-only:

```bash
VERSION="8.12.0"
...
if [ -f "${BIN_LINK}" ] && [ -d "${INSTALL_DIR}" ]; then
    INSTALLED_VERSION=$("${BIN_LINK}" --version 2>/dev/null || echo "unknown")
    echo "1Password already installed (version: ${INSTALLED_VERSION})"
    exit 0
fi
```

It reads the installed version only to print it — it is never compared against `VERSION`. So after the first run the script is a permanent no-op. `migrations/1770000002.sh` short-circuits identically (`if command -v 1password ... exit 0`). And the tarball path gets no auto-update channel: 1Password's `installAutoupdateChannel` only handles deb/rpm, and `after-install.sh` is never invoked in the first place.

Net effect: nothing on an Apple Silicon machine ever updates 1Password.

Measured on this machine today:

| | |
|---|---|
| Installed | `8.12.0` — `1Password for Linux/81200013`, `/opt/1Password` binaries dated Jan 19 2026 |
| Current arm64 tarball | `8.12.34` |
| x86_64 via AUR | `8.12.34-34` (as reported in #8470) |

Verifying that a newer arm64 build exists and that a stable URL is available:

```console
$ curl -fsSIL https://downloads.1password.com/linux/tar/stable/aarch64/1password-latest.tar.gz
HTTP/2 200
content-length: 210113528
last-modified: Tue, 25 Aug 2026 15:57:04 GMT

$ curl -fsSL -r 0-131071 https://downloads.1password.com/linux/tar/stable/aarch64/1password-latest.tar.gz \
    | gzip -dc 2>/dev/null | head -c 4096 | strings | grep -m1 '1password-[0-9]'
1password-8.12.34.arm64/
```

A password manager that can never receive an upstream fix is a meaningful gap, and x86_64 users are not affected because the AUR package tracks releases normally.

### 2. The vendor's hardening steps are skipped

`after-install.sh` (shipped in the tarball, at `/opt/1Password/after-install.sh`) does this:

```sh
GROUP_NAME="onepassword"
if [ ! "$(getent group "${GROUP_NAME}")" ]; then
  groupadd "${GROUP_NAME}"
fi
BROWSER_SUPPORT_PATH="./1Password-BrowserSupport"
# This gives no extra permissions to the binary. It only hardens it against environmental tampering.
chgrp "${GROUP_NAME}" $BROWSER_SUPPORT_PATH
chmod g+s $BROWSER_SUPPORT_PATH

install -Dm0644 ./resources/custom_allowed_browsers -t /usr/share/doc/1password/examples/
```

`omarchy-install-1password` reimplements the `chmod 4755 chrome-sandbox`, desktop-file, icon and polkit-policy steps, but not these. On this machine:

```console
$ getent group onepassword
$ ls -l /opt/1Password/1Password-BrowserSupport
-rwxr-xr-x 1 root root 6381808 Jan 20  2026 /opt/1Password/1Password-BrowserSupport
```

Expected `root:onepassword` mode 2755. Browser integration still functions, so this is a hardening regression rather than a breakage — but it is a silent divergence from what the vendor ships.

## Expected

- Installing 1Password on aarch64 should get a current build, and should keep getting them.
- The install should end in the same state the vendor's own post-install produces.

## Steps to reproduce

1. On an Apple Silicon Mac running Omarchy, install 1Password (`omarchy-install-1password`, or the Install menu entry, or `install/post-install/optional-apps.sh` on a fresh install).
2. `1password --version` → `8.12.0`.
3. Run `omarchy-install-1password` again at any later date. It prints "already installed" and exits 0.
4. `getent group onepassword` → empty; `ls -l /opt/1Password/1Password-BrowserSupport` → `root:root 755`.

## Suggested fix

The smallest correct change is to stop hand-rolling the post-install: extract the tarball, then run the bundled `after-install.sh` as root. That fixes the hardening gap and keeps Omarchy from having to track the vendor's post-install steps by hand.

For the version, there are two reasonable options and I don't know which fits the project's conventions:

- Use `1password-latest.tar.gz` and compare against the installed version before deciding to skip — always current, but nothing is pinned or checksummed.
- Keep a pinned `VERSION`, but make the guard compare `INSTALLED_VERSION` against it and reinstall on mismatch — reproducible, at the cost of needing bumps.

Either way the guard needs to compare rather than merely print, and something (a migration, or `omarchy update`) needs to call the installer again for existing machines that are already sitting on 8.12.0.

## Not this issue

While diagnosing the crash that led me here, I confirmed the SIGTRAP-on-quit is #7870 (no `setsid`, SIGHUP from the installer terminal), already reported for this exact hardware and version in #7822. Nothing here relates to that; I am not re-reporting it.

## System

- Omarchy 4.0.2-1
- Apple MacBook Pro (16-inch, M1 Max, 2021), aarch64
- Kernel 7.1.6-1-1-ARCH (Asahi)
- 1Password 8.12.0 (arm64 tarball, `/opt/1Password`, not pacman-owned)

`omarchy debug --no-sudo --print` referenced in the crash-reporting docs does not exist in 4.0.2, so the above is collected manually.

---

Filed by Claude Opus 5 via Claude Code.