Flicker on resize/fullscreen: stale com.koekeishiya.yabai agent runs alongside com.asmvik.yabai after fork migration

Summary

After updating to this fork, I ended up with two yabai master processes running simultaneously, which caused intermittent window flicker on resize and on zoom-fullscreen. The root cause is that this fork renamed the launchd service from com.koekeishiya.yabai to com.asmvik.yabai, but the old service was left enabled and installed on the system — so both the old and new agents ran at once and fought over window events.

I suspect this can happen to anyone migrating to this fork from upstream yabai (or from an earlier build that used the old label).

Symptoms

• Windows visibly flicker when resizing a tiled window or toggling zoom-fullscreen.
• The flicker is intermittent, not constant — it's a race, so it doesn't reproduce every time.
• Separately (and continuously, not per-action), the stderr log steadily accumulates thousands of:
  复制

  yabai: could not acquire lock-file! abort..

  one line each time the losing instance is relaunched by launchd and fails to acquire the lock. In my case this was ~6840 lines built up over ~3 days. Note the flicker and this lock-file loop are two separate symptoms of the same cause (two instances) — they run on different clocks; a flicker does not emit a lock-file line.
• The launchd job shows a very high restart count and last exit code = 78: EX_CONFIG.

Root cause

Two independent yabai instances were alive at the same time:

Both were:

• launched from the same binary,
• bound to the same socket (/tmp/yabai_$USER.socket),
• subscribed to the same CoreGraphics window events.

On every resize / fullscreen, each instance independently re-applied its own layout, racing the other — that's the flicker. Because the two instances ended up holding different lock-file inodes, yabai's single-instance lock guard never actually blocked the second instance; instead the loser just logged could not acquire lock-file! abort.., exited, and was relaunched by launchd in a loop (hence the huge restart count and EX_CONFIG).

The reason both existed: the service label was renamed (com.koekeishiya.yabai → com.asmvik.yabai), but nothing removed/disabled the previously-installed agent under the old label. yabai --start-service / --restart-service only manage the new label, so the stale old agent kept running invisibly.

How to detect

# More than one master process?
pgrep -fl '/yabai$'

# Both service labels present?
launchctl list | grep -i yabai
ls ~/Library/LaunchAgents/ | grep -i yabai   # com.koekeishiya.yabai.plist AND com.asmvik.yabai.plist

# Repeated lock-file errors + restarts?
grep -c 'could not acquire lock-file' /tmp/yabai_$USER.err.log

Fix (manual)

Disable and remove the stale old-label agent, keep only the fork's:

launchctl bootout gui/$(id -u)/com.koekeishiya.yabai
launchctl disable gui/$(id -u)/com.koekeishiya.yabai
rm ~/Library/LaunchAgents/com.koekeishiya.yabai.plist
# then start the fork's service cleanly
yabai --restart-service

After this there is a single master, the lock-file errors stop, and the flicker is gone.

Suggested improvements

1. Migration handling: on --install-service / --start-service, detect a previously-installed agent under the old com.koekeishiya.yabai label and bootout/disable/remove it (or at least warn loudly).
2. Harden the single-instance guard so a second instance that can't acquire the lock cannot end up bound to the socket and processing events — the current behavior degrades to a relaunch loop rather than a hard "another instance is already running" refusal.
3. Document the rename in the README/migration notes so users coming from upstream know to remove the old service.

Environment

• yabai: v7.1.25 (this fork)
• macOS: 26.5.1 (build 25F80), Apple Silicon
• SIP: partially disabled (scripting addition loaded)