Migration `1785167800.sh` hands fcitx5 over from Hyprland autostart to `omarchy-fcitx5.service`. The handover kills the *running* process but never removes the autostart *entry*, so at the next graphical login the desktop entry wins the race and the unit restart-loops indefinitely.

On this machine it reached **11,172 restarts**, at ~11 journal lines/second.

## What happens

`~/.config/autostart/fcitx5.desktop` (user-created, predates the migration) starts `fcitx5 -d`. It claims the bus names:

```
org.fcitx.Fcitx5              2282 fcitx5
org.freedesktop.portal.Fcitx  2282 fcitx5
```

`omarchy-fcitx5.service` then starts, finds the name taken, and exits **0**:

```
fcitx5[…]: E addonloader.cpp:96] Failed to create addon: dbus Unable to request dbus name. Is there another fcitx already running?
fcitx5[…]: I addonmanager.cpp:200] Could not load addon dbus
fcitx5[…]: I addonmanager.cpp:306] Unloading addon wayland
systemd[…]: omarchy-fcitx5.service: Scheduled restart job, restart counter is at 10953.
```

`Restart=always` + `RestartSec=2` turns that clean exit into a permanent 2-second loop:

```
$ systemctl --user show omarchy-fcitx5.service -p NRestarts -p ExecMainStatus
NRestarts=11172
ExecMainStatus=0
```

The unit's own comment describes this exact failure, so the policy is deliberate — the gap is in the migration, not in `Restart=`:

```
# always, not on-failure: fcitx5 exits 0 when it detects another instance owning
# its bus name, and a clean exit still leaves the user with no input method.
```

## Why the migration misses it

```bash
pkill -x fcitx5 >/dev/null 2>&1 || true
systemctl --user start omarchy-fcitx5.service
```

`pkill` clears the process, so the migration reports success and looks correct. The `.desktop` file survives and restores the competing instance at the next login.

The user had already masked the packaged entry with `~/.config/autostart/org.fcitx.Fcitx5.desktop` containing `Hidden=true`, and substituted their own `fcitx5.desktop`. **XDG autostart dedup is by filename**, so a hand-rolled entry under any other basename is invisible to both the mask and the migration.

## Impact

Input methods keep working — the autostart instance serves normally — so the only symptom is a journal being flooded at ~11 lines/second, indefinitely, on every boot. Silent unless someone looks. Users also silently lose `--disable notificationitem`.

## Reproduce

1. Create `~/.config/autostart/fcitx5.desktop` with `Exec=fcitx5 -d`
2. Run the migration / `omarchy update` to 4.0.0
3. Log out and back in
4. `systemctl --user show omarchy-fcitx5.service -p NRestarts` — climbs by one every 2s

**Expected:** the migration neutralizes any autostart entry that launches fcitx5, regardless of filename, so the service is the only instance.

## Suggested fix

In `1785167800.sh`, scan `~/.config/autostart/*.desktop` for an `Exec=` resolving to `fcitx5` and mask or remove the entry (not just `pkill` the process). Optionally have the unit detect an existing bus-name owner and fail loudly instead of exiting 0 into a loop.

## Workaround

`rm ~/.config/autostart/fcitx5.desktop`, then restart the unit. Verified on the affected machine: the last loop line was at 16:47:27, the file was removed at 16:47:28, and the unit has since held `NRestarts=0` with a single instance owning `org.fcitx.Fcitx5` for 25+ minutes — 74 journal lines total (one normal startup), down from ~11/second. Persistence across a fresh graphical login has not yet been re-tested on this machine.

**System:** Omarchy 4.0.0-1, Hyprland/uwsm, fcitx5 from `omarchy-base.packages`.

> Filed by Claude Opus 5 via Claude Code.